Hi Ken,
----- Original Message -----
> On Mon, 2012-11-26 at 18:33 -0500, Nathan Scott wrote:
> > BTW, I've reverted this change for now - we think it may be the
> > cause of some confusing test results here. There's also some
> > evidence that running tests from in a workarea (ie below qa/)
> > is using pcp.conf from the build rather than the root. Which
> > seems odd & unexpected to me, but I havent found the source of
> > that yet.
>
> I don't see how the Makepkgs change can be breaking things for QA.
>
"confusing test results" != "breaking QA". I don't really fully
understand what happened (didn't happen to me & it was difficult
to debug remotely).
> I do think we have a big problem associated with moving QA into the
> PCP
> tree, namely that we descend into qa and qa/src _both_ in the build
> and
> when running QA from a workarea (the latter being a non-negotiable
> requirement IMHO for on-going QA maintenance and development).
*nod* to the last bit, unconvinced there's a big problem related to
QA-in-tree though. Also overlooks the good aspects of keeping fixes
with their associated QA test updates, and the way that all builds
now must have a successful QA build too.
Let me distract you ;) by saying there is more of a problem around
not needing any mechanism for conditional code building in qa/src/.
e.g. qa/src/unpack.c uses pmEventRecord, which is post-3.5.0 only.
This should be a problem no matter where qa lives - yet noone reports
it, making me wonder just how important all the back-compat goop we
keep in the QA tests really is? Once there, that goop has a non-zero
maintenance cost, yet after a relatively short time, it seems to be
unnecessary baggage.
A possible approach would be to invent a mechanism for using PCP_VER
in the source makefile too (?) and having a policy of culling compat
macros after N new releases have been made.
> In one case (the build) you _want_ to use include files and pcp.conf
> from ../src/include ... in the other case (running QA) you _want_ to
> use
> the installed versions of the include files and pcp.conf (from a
> packages build).
This is the same issue that several PMDAs have (with the GNUmakefile
and GNUmakefile.install split) ...
> Seems like we need to back QA out the PCP tree _or_ find some clever
> way of making the makefiles schizophrenic.
That is how the QA source makefiles operate (schizo - using the usual
split between GNUmakefile and GNUmakefile.install that we do elsewhere
and a GNUlocaldefs for all the common/shared make goop).
cheers.
ps: lets also not forget there was a problem that the change I had to
backout was fixing ... not clear to me what that was, still, esp how
it related to the deb packaging that already had the configure flag.
--
Nathan
|