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

[Paolo Bonzini]

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 =~ 
/^(?:EXTRA_)?(?:nobase_)?(?:dist_|nodist_)?(.*)_[[:alnum:]]+$/;
              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 configure.ac and merge it with Makefile.am
files (options, subst-ed variables, etc.)

2) resolve conditionals

3) gather primaries, and select the appropriate snippets into the "rules"
section of Makefile.in (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
Automake-NG.

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 bootstrap.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.

Thoughts?

Paolo