On Sun, Apr 03, 2005 at 08:26:56AM +0200, Ralf Wildenhues wrote: > Hi Marc, > > * Marc Singer wrote on Sat, Apr 02, 2005 at 12:02:01AM CEST: > > I think there is more to this override story. Perhaps this is why > > I've not found the makefile command line override very helful. > > > > It looks like when we have a make invocation within make, the > > overrides do not propagate. > > Yes. This one can be helped though, too. > > > #Makefile.1 > > PREFIX=/usr/local > > all: > > make -f Makefile.2 > > You need to use $(MAKE) here. Not just for command line override, this > is also important for parallel make (I think), or for systems with a > very broken make, but GNU make installed as `gmake'. > (Yes, ATM we do have such a broken `make' invocation in one of our > Makefile's in CVS HEAD. We are working on it.)
Now we're entering forbiddend territory. Requiring patches to a project in order to debug it is not desirable. Think about it this way. A simple change to the tools allows package developers to overcome limitations in the upstream package. Requiring the source to be modified to meet the requirements of the component tools just makes the problem worse. > > > #Makefile.2 > > PREFIX=/usr/local > > > > > make PREFIX=/usr -f Makefile.1 > > > > During Makefile.1, the PREFIX is /usr. In Makefile.2, it is > > /usr/local. > > Yes. Additionally to above, if you do not use automake, you need > @SET_MAKE@ > in Makefile.in, plus > AC_PROG_MAKE_SET > in configure.ac. Read more in > info Autoconf Output > for details. Likewise. I know that packages are broken. The problem is that the underlying tools don't enforce compliant style. Moreover, they have the bothersome tendency to be incompatible with older versions--this is most a criticism of automake, but autoconf suffers too. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
