Stepan Kasal <[EMAIL PROTECTED]> writes:
>> All that cruft could be removed if automake interpreted "+=" of a
>> previously unseen variable as an assignment.
>
> ``a lot of code''?
>
> All you need is:
> 1) remember the list of all variables used
> (To be exact, you don't need the list of variables actually used,
> any superset will do.)
> 2) output empty assignments to an automake fragment
> 3) `include' that fragment at the beginning of your Makefile.am
"A lot" can be subjective. It's code that doesn't have to be there if
automake supported += with undefined variables.
MPC doesn't make it easy to remember whether a variable is emitted.
It sucks up *.mpc files and builds lists (source files, header files,
etc.), which it uses to expand *.mpd template that has a minimal set
of control flow and output formatting macros.
Normally MPC also generates a separate file per project. Since this
would result in 50+ files in some ACE/TAO directories, we merge them
into a single Makefile.am instead of using "include". Fortunately,
this gives us an opportunity to transform "=" to "+=", but it's done
by parsing the per-project proto-Makefile.am's.
> This doesn't need much code, and you have a Makefile.am which looks
> the same as it would if Automake interpreted += of an unseen
> variable as an assignment.
>
> But I think that your current code produces nicer Makefile.am's. If
> a variable is used only on one line, it's more natural if it's an
> assignment. That matters if there is a danger that a human will try
> to read them.
>
> So the price is for nicer output, not to overcome Automake
> limitations.
True. Currently MPC doesn't generate 100% perfect Makefile.am files,
so I have made extra effort to make the output as close as I can to
what a human would write, since I end up tweaking the output.
--jtc
--
J.T. Conklin
