automake
[Top][All Lists]
Advanced

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

Re: _SHORTNAME in conditional


From: Thomas Martitz
Subject: Re: _SHORTNAME in conditional
Date: Wed, 6 Jan 2016 13:29:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0


Hi,

I've written an RFC patch that solves my root problem so that I wouldn't have to use _SHORTNAME at all. Please have a look at that and comment on it!

I'll still follow-up with my findings regarding _SHORTNAME below.

Am 06.01.2016 um 13:15 schrieb Gavin Smith:
On 6 January 2016 at 06:01, Thomas Martitz <address@hidden> wrote:
Am 05.01.2016 um 23:41 schrieb Gavin Smith:
On 5 January 2016 at 21:05, Thomas Martitz <address@hidden> wrote:
Automake source code is a myth to me, I wasn't able to find the code that
implements this limitation (only the place where the warning is printed
(variable_value() => $self->check_defined_unconditionally in Variable.pm)

There's the following code in the top-level 'automake' script -

                  if ($var)
                  {
                      # FIXME: should use the same Condition as
                      # the _SOURCES variable.  But this is really
                      # silly overkill -- nobody should have
                      # conditional shortnames.
                      $dname = $var->variable_value;
                  }

does that help?


I saw that, but I couldn't make sense of it. What does that mean? I get
that the developer deemed it overkill but I can't follow that reason.

Whoever wrote that, if they are still around, can speak for
themselves, but I'll try to explain what I remember from my foray into
the Automake source code a couple of years ago.

The Automake conditional construct means that variables don't have to
have a single value:

if COND
VAR=val1
else
VAR=val2
endif

Here VAR has two values.

Each Automake conditional tests only a single condition. They can also
be nested:

if COND1
if COND2
VAR=val
endif
endif

Adding more conditions reduces the number of occasions that the
contained definition is applicable. The definition here is valid if
"COND1" AND "COND2".

A sequence of nested conditionals can be represented by a list of
conditionals: COND1 AND !COND2 AND COND3.

What about no conditionals at all? This is represented by TRUE. TRUE
is appropriate because when you add more conditions to it, it
disappears: TRUE AND CONDITION is equivalent to CONDITION.

This should answer the question of why when you ask for a definition
under the TRUE condition of a conditionally defined variable, it gives
an error: a definition for the TRUE condition would be an
unconditional definition. (I found this point confusing, myself.)

Note also that the word "Condition" as used in the Automake source
code has a narrower meaning than its common sense: it refers to a
conjunction of conditions only (AND), and not OR for the union of two
conditions.

When asking for a variables value, you have to specify the condition.
 From Variable.pm:

Therefore obtaining the value of a variable under a given
condition involves two lookups.  One to look up the variable,
and one to look up the conditional definition:

   my $var = var $name;
   if ($var)
     {
       my $def = $var->def ($cond);
       if ($def)
         {
           return $def->value;
         }
       ...
     }
   ...

What remains, I believe, is how to get the right condition to look up
the value of the *_SHORTNAME value. I assume that mustn't be easy,
otherwise they would have done it.

(In my humble opinion, Automake conditionals muddle the Automake
source code terribly. DisjConjunctions.pm and Conjunctions.pm together
constitute a weird reimplementation of the Boolean algebra that is
present in every programming language. I thought when I was looking at
the code before that it would at least twice as easy to understand the
code if this feature wasn't present.)


Thanks for you insight. In the meantime, I think I found why _SHORTNAME in particular is unsupported (however I still haven't found the code that implements this particular decision).

Anyway, I believe the reason is that automake already fully resolves the object names (and consequently _SHORTNAME) at Automake-time.
I.e. Makefile.in contains:
foo_OBJECTS = bar_foo-foo.o
Other variables are substituted at configure time (using @VAR_TRUE@).

That's it. Automake conditionals are ultimately resolved at configure time, but that's too late for the implementation of _SHORTNAME.

Now, you could do something like in Makefile.in
@address@hidden(am_foo_SHORTNAME) = bar_foo
@address@hidden(am_foo_SHORTNAME) =
foo_OBJECTS = $(am_foo_SHORTNAME)foo.o

and resolve that at configure time, but that's simply not implemented currently. I guess that's why there is a TODO in the automake script (see at the beginning of this mail).

Best regards



reply via email to

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