[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Automake-NG] typo whitelisting, and Automake-NG vs. GNU make runtim
Re: [Automake-NG] typo whitelisting, and Automake-NG vs. GNU make runtime
Thu, 23 Aug 2012 11:07:07 +0200
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
> 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",
>> 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
> 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...