automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

automake/44: conditional redefinitions (Was: Re: Automake 1.6.3 issue)


From: Alexandre Duret-Lutz
Subject: automake/44: conditional redefinitions (Was: Re: Automake 1.6.3 issue)
Date: 11 Oct 2002 23:04:05 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Reviving an old thread about the following construct.

  foo = mumble
  if COND
    foo = blurgle
  endif

 Tom> I've long thought that we should, eventually, support the
 Tom> latter use.  It seems to have a clearly defined meaning.
 Tom> And it is even useful in some situations.  For instance,
 Tom> suppose in a very large project you want to `include' some
 Tom> boilerplate.  Then you might conditionally override some
 Tom> value or another in a particular Makefile.am.

I think we have three choices:

  1. Like with "standard" Makefile assignments, the second 
     definition of `foo' overrides the first one.  So `foo' 
     is undefined when COND is false.

  2. The second definition of `foo' _partially_ overrides the 
     first one.  Yielding a definition equivalent to
       if COND
         foo = blurgle
       else
         foo = mumble 
       endif

  3. This construct is ill-formed and should be diagnosed.

#3 is what Automake 1.7 assumes; it seems you want #2; and
#1 doesn't make any sense (just consider
  if COND
    a = A
  else
    a = B
  endif
).


Let's consider another snippet.

      if COND1
        foo = mumble
      else
        foo = mumble
      endif
      if COND2
        foo = blurgle
      endif

At a first glance, this looks equivalent to the previous
construct.  However Automake 1.7 isn't aware of this and
produces the following Makefile fragment, without the 
slightest warning:

   @address@hidden = blurgle
   @address@hidden = mumble
   @address@hidden = mumble

(The order of definitions in the output doesn't match the order
of definitions in the input, because Automake doesn't keep track
of this sort of things.)

IMO this is a bug.  Either we should diagnose an error (#3), or we
should produce something sensible (#2).

If we take road #2, then the third `foo' definition should partially
override previous definitions of `foo', in the COND2 condition; as
if the user had written

      if COND2
        foo = blurgle
      else
        if COND1
          foo = mumble
        else
          foo = mumble
        endif
      endif

This seems to suggest a way to implement #2 easily.  When 
defining a variable in condition `COND', append `!COND' to all
previous definitions' conditions.

This also works for things like

  foo = mumble
  foo = blurgle

which would be interpreted as

  foo = blurgle
  if FALSE
    foo = mumble
  endif



Something that I don't know how to handle is the tracking of
location for variables whose conditions have been changed as a
side effect of a redefinition.  It will be confusing if Automake
diagnoses something about a variable `defined in condition
COND1_TRUE COND2_FALSE' and then point the user to the place
where the variable was simply defined in COND1_TRUE (should we
explain that COND2_FALSE was added because the variable was
later redefined in COND2_TRUE? how?)

Another question is when should this construct be allowed?  I
agree #2 is useful when the definitions and redefinitions are in
different files.  IMO #3 would be helpful when the
(re)definitions are in the same file.  I can't think of any
reason why a variable would be redefined in the same file,
except user's inattention.

Opinions?
-- 
Alexandre Duret-Lutz





reply via email to

[Prev in Thread] Current Thread [Next in Thread]