On Wed, 2012-11-28 at 14:27 -0500, Frank Ch. Eigler wrote:
> Ken McDonell <kenj@xxxxxxxxxxxxxxxx> writes:
>
> > I don't see how the Makepkgs change can be breaking things for QA.
> > [...]
>
> I believe the problem arose from the Makepkgs run building an RPM with
> a different --libexecdir than the src tree left over after Makepkgs'
> own invocation of ../configure. ...
Correct. And it is not just RPM builds ... any packaging run that
passes arguments to configure is likely to produce this outcome.
> ...
> I think this is a special case of not fully supporting --prefix yet in our
> development workflow. If we get a
>
> % configure --prefix=/developer/tree ; make ; make install
>
> installation working as the main way to do development, and then have the
> qa testsuite, configured with the same prefix, should be able to run against
> the --prefix tree. Then testing the installed system version is just a
> special case, of --prefix=/usr --FOODIR=/bar etc, as per Makepkgs.
>
> The benefit is that there'd be no need to run pcpqa directly against
> the build accidentally left behind in the source tree.
But I never have (in the history of PCP) needed to do anything special
in the QA tree to run QA ... I'm not planning on any additional
configure, make, make install steps for me (although I agree it is a
perfectly acceptable way to proceed for others).
The following patch snippet is from a modified qa/src/GNUmakefile:
+ifeq ($(QA_IN_TREE),'')
include $(TOPDIR)/src/include/builddefs
+else
+include /usr/include/pcp/builddefs
+endif
applying the same change to the parent qa/GNUmakefile and then invoking
make as
$ QA_IN_TREE=yes make
in the handful of places we run make from the QA scripts (not the build)
will fix the problem for everyone I believe.
If we can get consensus on this I'll make the changes.
|