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