[Build-common-hackers] change to autotools-vars.mk

Colin Walters walters@debian.org
15 Jun 2003 12:18:57 -0400


On Sun, 2003-06-15 at 09:25, Jeff Bailey wrote:

> Oy.  That means we have some things that need to be set above, and
> things that need to be set below?

Very few things should need to be set above.  Hopefully we can get that
down to none.

> Why are these defined at all in makefile.mk?  They can just as easily be
> left blank, which seems like it would solve this problem.  clean is
> currently defined, but that's the same in autotools.mk.

They're defined there because they're used there.  Besides, I like
having the variable settings there, even if they're defined to nothing,
because it kind of serves as a poor form of documentation.

You solved the problem by not setting DEB_MAKE_INSTALL_TARGET in
makefile.mk.  I don't really like that solution, because it kind of
breaks the modularity of the class.  makefile.mk shouldn't have to
change just because we want to do something else in autotools.mk.

In general, we want a class to be able to easily override variables in a
parent class, without changing the parent class.  Users might write
their own classes, and they won't be able to (or want to) modify the
distributed cdbs classes.  The only way I could originally think of to
do that was by using :=.

However, a different solution just occurred to me.  Inside autotools.mk,
we do this:

DEB_MAKE_INSTALL_TARGET ?= install DESTDIR=blah
include makefile.mk

common-install::
    ....

That way the variable is set *before* makefile.mk is included.  But if
we adopt this approach, we should be very explicit that this is how
things are intended to be.  Actually a problem with the above just
occurred to me; what if you want to reference a variable defined in the
parent class?

Personally, I am inclined to just do a mass substitution and change all
the ?= to :=, so it's enforced that variables have to be set after the
inclusion, and not before.  What do you think?