Nathan,
On Wed, 2012-11-28 at 01:09 -0500, Nathan Scott wrote:
> > 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.
I don't think we have a major disagreement here.
> 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 ...
I believe the problem is that I failed to build/design unpack.c
properly ... if I'd done a better job here, you would not have had the
anguish you had.
> - yet noone reports
> it, ...
I did not report it because I just worked around it with an out of tree
script that remade the binary if I was unsure if the library/headers and
QA binary were not consistent ... 8^(>
> 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.
I would support this approach, although I am not sure how we'd enforce
the annotation in the first place. Is this the sort of thing you had in
mind?
#include <stdio.h>
#include <stdlib.h>
#include "./localconfig.h"
int
main()
{
#if PCP_VER < 3611
printf("nothing to do\n");
#elif PCP_VER >= 3611
printf("first attempt in 3.6.11\n");
#else
printf("really working in 3.6.12 and later\n");
#endif
// stuff
exit(0);
}
> > 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) ...
I don't agree ... this is not a GNUmakefile vs GNUmakefile.install
issue.
The build does
make
which ends up descending into qa and qa/src
When running QA I want to
cd qa
./check something
which runs make in the qa and qa/src directories ... we need "make" to
be including different builddefs in the two cases because divergence in
the arguments passed to configure between the individual package build
recipes and Makepkgs means that the installed builddefs may not be the
same as the one in the workarea ... which is what my patch was trying to
address.
[more on the topic in my response to Frank's later mail]
|