Re: Environment variables, debian/rules and dpkg-buildpackage

[Manoj Srivastava <srivasta@debian.org>]

On Mon, May 04 2009, Peter Eisentraut wrote:

> On Monday 04 May 2009 23:53:15 Manoj Srivastava wrote:
>> On Mon, May 04 2009, Peter Eisentraut wrote:
>> > Please be sure to use
>> >
>> > FOO = bar
>> >
>> > instead of ":=", unless you have determined that you really wanted ":=". 
>> > In most cases it won't make a difference, but in some it does, and then
>> > it would behave contrary to how make usually treats variables.
>>
>>         Why, in your opinion, would we want _not_ to use :=? What does
>>  delayed evaluation buy us?
>
> That is up for debate, to some degree, I guess.  I just want to make
> sure that a conscious decision is made either way.  (In my experience,
> many uses of := are made without knowledge about what it does.)

        That is surprising (and somewhat disheartening),  it is not a
 complex concept. Now double-colon rules, that's something else.

> I think delayed evaluation is sort of the default way in which make
> treats variables, and so to avoid surprises and confusion, we should
> go with that one unless there is a specific reason otherwise.

        Err, no. If you use =, there is one behaviour, if you use :=,
 there is another. I would not call either one "default", apart from the
 fact that non-gnu makes do not have :=.

> In practical terms, using delayed evaluation makes the outcome mostly
> independent of the order of the assignments.  Which might become quite
> relevant when you design an include-a-bit-here, override-a-bit-there
> scheme that is supposed to be robust against all the nonsense that
> 10000 source packages might do with it afterwards.

        We do *NOT* want settings from the distribution, from the site,
 the package, and the user happen in a manner mostly independent of the
 order -- making it harder for the user to see wtf is going on.

        Indeed, this is one case where we *must* have as little
 ambiguity as possible, where we are trying to provide _default_ values
 in a hierarchical fashion. Simply expanded variables generally make
 complicated makefile programming more predictable because they work
 like variables in most programming languages. They allow you to
 redefine a variable using its own value (or its value processed in some
 way by one of the expansion functions) and to use the expansion
 functions much more efficiently.

> Also note that someone who wants to be careful not to overwrite values 
> supplied elsewhere might use ?=, which creates a delayed expansion type 
> variable.

        Have you been reading at all? Has it not been stated repeatedly
 that we _want_ a specific order of overrides for the variable values?
 We _want_ the site set values to override the distribution defaults --
 and then we want the package to override that, and the command line
 trumps all. There is no "careful not to override" meme here -- we want
 emphatically to overwrite what the outer layer has set.

        All the dilly dallying with delayed evaluation just confuses the
 issue, and makes make work harder, for no other reason than a vague
 "don't use := cause I don't remember what it does" fear.

> In any case, we should be careful to define and document it one way or the 
> other.  Otherwise stuff like
>
> CPPFLAGS += -DFOO=$(BAR)
>
> has unclear behavior, depending on how or whether CPPFLAGS was
> previously set up.  (And note that it will change if initially you
> don't define CPPFLAGS at all and in a later version make a :=
> definition for it -- delayed variables being the default.)

        There is nothing unclear about it. You are appending to the value
 of the preprocessor flags in that line -- at the time of use (that is,
 when the flags are "used" or evaluated). 

        However, whenever you use a :=, the variable is cleared, and set
 to the value on the right hand side. So the := setting does what it is
 supposed to: ignore anything we knew about the variable before that
 point in the Makefile.  If you do not know what := does, I suppose that
 can be confusing, and/or terrifying.

        You know, I get it that you have trouble understanding what =
 and := do in make. But this knee jerk "don't use :=" is not
 helping. There is nothing mystical about :=

        manoj
-- 
The penalty for laughing in a courtroom is six months in jail; if it
were not for this penalty, the jury would never hear the evidence. --
H. L. Mencken
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C