[Top][All Lists]

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

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

From: Paolo Bonzini
Subject: Re: [Automake-NG] typo whitelisting, and Automake-NG vs. GNU make runtime
Date: Thu, 23 Aug 2012 11:07:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

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 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 and merge it with
>> 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/': that file is included *verbatim* in the generated
> (well, almost: '##' comments still have to be stripped of course).
>> 5) do semantic checks
> Some of them (e.g., those involving only 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 '', 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

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


reply via email to

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