[Top][All Lists]

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

typo whitelisting, and Automake-NG vs. GNU make runtime

From: Paolo Bonzini
Subject: typo whitelisting, and Automake-NG vs. GNU make runtime
Date: Wed, 22 Aug 2012 12:32:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

So I took a closer look at the whitelisting problem that was reported
in GNU Smalltalk.

The piece of code that was removed in Automake-NG is:

  foreach my $primary ('SOURCES', 'LIBADD', 'LDADD', 'LDFLAGS', 'DEPENDENCIES')
      foreach my $var (variables $primary)
          my $varname = $var->name;
          # A configure variable is always legitimate.
          next if exists $configure_vars{$varname};

          for my $cond ($var->conditions->conds)
              $varname =~ 
              msg_var ('syntax', $var, "variable '$varname' is defined but no"
                       . " program or\nlibrary has '$1' as canonical name"
                       . " (possible typo)")
                unless $var->rdef ($cond)->seen;

Note the

          # A configure variable is always legitimate.
          next if exists $configure_vars{$varname};

part in particular.  Going back to the commit that introduced it, in
54ad2a6, the comment was even more expressive:

          # Note that a configure variable is always legitimate.
          # It is natural to name such variables after the
          # primary, so we explicitly allow it.

Now this suggests that indeed the new behavior of Automake-NG _would_ be
"naughty and annoying" (quoting from Stefano).  Indeed there are cases
where the new behavior would catch bugs, but are they enough overall?

Generalizing the above, the point is that there _is_ a loss of information
going from Automake runtime to GNU Make runtime.  Therefore, I don't see
the point in moving the check from Automake runtime to GNU make runtime.

The tasks of Automake are multiple:

1) gather information from and merge it with
files (options, subst-ed variables, etc.)

2) resolve conditionals

3) gather primaries, and select the appropriate snippets into the "rules"
section of (roughly speaking)

4) apply transformations to the snippets

5) do semantic checks

For each of this, the amount of code that can be moved to GNU make runtime
is different.  For (1) it is obviously "zero", and for (3) I suppose it is
close to zero as well.  (2) could probably be simplified somehow, with
hardly any effect on the cost of actually building with GNU make.

(4) can be simplified a lot, with some extra cost imposed on GNU make,
but it should really be bearable.  In fact, simplifying this complex, and
little known, part of Automake is the main benefit I see in requiring

For (5), it _may_ be possible (using things like .VARIABLES) to move the
checks to GNU make.  But I don't really see the point.  You want errors
to be diagnosed as soon as possible, and as precisely as possible.

Regarding quality, Perl can do the task better than Make, just like it can
do it better than M4.  And Automake can also do it better than the generated
Makefiles, because it has more information coming from tasks (1) and (2) in
the list above.

Regarding early diagnosis, I want "sh" to find all problems in
my build system, *before* I embark into the expensive "./configure && make".
One of the reasons why the C compiler tries to warn about implicitly-defined
functions, even though C89 does not require that, is that it diagnoses typos
well before the final link.



reply via email to

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