pcp
[Top] [All Lists]

Re: Issues running QA

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: Issues running QA
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Wed, 16 Dec 2015 18:50:07 -0500
Cc: myllynen@xxxxxxxxxx, pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5671D70D.20906@xxxxxxxxxxxxxxxx> (Ken McDonell's message of "Thu, 17 Dec 2015 08:26:37 +1100")
References: <5671184C.1@xxxxxxxxxx> <5671D70D.20906@xxxxxxxxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

kenj wrote:

> [...]
> You're already in unchartered water here ... I've never tested the
> --prefix=... option for a build and would not be surprised if this has
> problems.
>
> I don't think this should be necessary, nor should it be attempted
> ... the PCP QA suite is designed with a philosophy that it is trying
> to exercise the code in a context that is as close as possible to that
> which an end-user would experience.  [...]

For the record, --prefix is not incompatible with end-user experience.
We added --prefix to the configury specifically because there was a
use-case for installing and running pcp out of a non-core-os
subdirectory.  And it worked fine, including /etc/rc.d files that
redirected to the $prefix/bin programs.  I believe we ran pcpqa that
way too.

There were only a few configuration prereqs like putting $prefix/bin
into the $PATH (ahead of any conflicting system copy).  For
pcp-libs-devel purposes, an end-user $CFLAGS would have to include
-I$prefix/include, etc. - something we could automate with
http://oss.sgi.com/bugzilla/show_bug.cgi?id=1095 .

Embracing --prefix more could also pave the way for letting pcpqa run
on normal workstations, with much less disruption to the system, thus
making it more pleasant to be run frequently.


- FChE

<Prev in Thread] Current Thread [Next in Thread>