Re: [Automake-NG] typo whitelisting, and Automake-NG vs. GNU make runtime

[Paolo Bonzini]

Il 23/08/2012 10:36, Stefano Lattarini ha scritto:
> On 08/22/2012 12:32 PM, Paolo Bonzini wrote:
> How would you diagnose a typo in here at Automake runtime?
> 
>    bin_PROGRAMS = $(call user-func,args)
>    bin_PROGRAMS += $(if $(ON-CYGWIN),baz)
> 
>    ifdef ON-CYGWIN
>      # Oops, this was meant to be baz_LDFLAGS!
>      bar_LDFLAGS = -lextra
>    endif
> 
> It's true that this currently (and sadly) wouldn't work anyway, but that
> is due to the limitations inherited by mainline Automake, not to some
> fundamental impossibility; so I'd like to be able to make it work in the
> future (the same way we made TEST_EXTENSIONS completely processed at make
> runtime).  So we need to be prepared to the fact that a lot of information
> will no longer be available at automake runtime.

I think a user that wants to do this should be prepared to lose the
warnings.  I.e. the more dynamic your Makefile.am is, the less checking
can be done at Automake time.  But I don't see a particularly pressing
reason to move the checks to make, where they will be expensive for all
users instead of just the developers.

But it seems that your goals are a bit different from what I had
understood so far.

>> The tasks of Automake are multiple:
>>
>> 1) gather information from configure.ac and merge it with Makefile.am
>> files (options, subst-ed variables, etc.)
>>
> And this ability should be preserved in Automake-NG.
> 
>> 2) resolve conditionals
>>
> Ideally, once Automake-NG is powerful enough, Automake-time conditional
> would disappear -- you should be able to use GNU make builtins like
> '$(if ...)', 'ifeq' and 'ifdef' instead.  That will be quite difficult
> to do (something for Automake-NG 2.0 probably), but is worth keeping in
> mind that we are working towards that goal, and acting accordingly from
> right now.

This, or if/endif could just be rewritten to GNU make syntax.

>> 4) apply transformations to the snippets
>>
> This too will disappear eventually, to be replaced with proper use of $(eval)
> and user-defined functions.  To get the gist of it, take a look at the
> implementation of the parallel-tests harness in Automake-NG, in the file
> 'lib/am/parallel-tests.mk': that file is included *verbatim* in the generated
> Makefile.in (well, almost: '##' comments still have to be stripped of course).
> 
>> 5) do semantic checks
>>
> Some of them (e.g., those involving only configure.ac) will be kept at
> automake runtime; a lot will be moved at make runtime; some (I hope very
> few) will just have to be dropped.  An unavoidable price to pay IMO.

This is where I disagree, because moving things to make runtime makes
the execution more expensive for everyone except developers.

>> For each of this, the amount of code that can be moved to GNU make runtime
>> is different.  For (1) it is obviously "zero",
>>
> Yep.
> 
>> and for (3) I suppose it is close to zero as well.
>>
> Disagree.  I actually want it to be 100% eventually :-)

You're right, you can actually derive everything from .VARIABLES.
Still, a limited amount of parsing can help with better diagnostics.

>> (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.
>>
> I agree this is the best starting point, and the simplest part to tackle
> (and most of my changes have in fact worked in that direction).  But I
> assure you this part of the Automake code base is actually one of the
> simplest ans clearest ones!

Yes, the Perl bits are clean but the .am syntax is daunting.

>> 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.
>>
> This I should have explained above already.
> 
>> You want errors to be diagnosed as soon as possible, and as precisely
>> as possible.
>>
> Yes -- as long as that is possible and doesn't impede further developments.
> 
>> Regarding quality, Perl can do the task better than Make,
>>
> But I envision a day when Automake-NG will be no more than a few hundred
> lines of perl, mostly dedicated at tracing stuff in 'configure.ac', and
> setting up few variable definitions accordingly.  No more incomplete, messy,
> half-unspecified parsing and tweaking of a subset of make syntax there!
> Let GNU make parse GNU make input -- it's the only sane way ahead.

So basically you want a version of Quagmire that supports configure.ac.

Are you sure it isn't simpler to start from scratch?  Serious question...

Paolo