Re: extending automake

[Brian Dessent]

Bob Rossi wrote:

> verbose). Why are you not sure this is a good idea?

I sort of feel like there are "workspaces", the configure area and the
make area.  This parallels the idea that there are configure-substituted
variables and make-substituted variables, the latter can be
changed/overridden when invoking make, the former can only be changed by
running "./config.status --recheck" or re-running configure.  Whenever
you see a "FOO = @FOO@" in Makefile.in, that's transferring a value from
configure-space to make-space.

Anyway, I tend to see configure-space as being about m4 macros and shell
variables, and the make-space as being about targets, prerequisites, and
recipies.  Since we're talking about the latter it just seemed a little
odd to want to use m4 macros to achieve a goal.

It of course would be possible to put the makefile fragments in a macro
in a .m4 file, and then just leave a slug in Makefile.am to be
substituted, but I'm not sure it seems right to my eyes to see e.g.

# typical Makefile.am stuff
foo_SOURCES = ....
bar_LDFLAGS = ...

@SOMETHING@

baz_CPPFLAGS = ....

This also has the disadvantage that it hides the expansion of
@SOMETHING@ from automake's eyes, since the @foo@ expansion happens by
config.status when the Makefile is created at the end of running
configure, whereas automake runs much earlier at bootstrap/autoreconf
time.  In this case it might not matter since what you'd be passing
through would likely not contain anything interesting to automake.  But
it could, for example both BUILT_SOURCES and EXTRA_DIST are automake
variables whose assignments it would probably have to see, so you
wouldn't be able to use any of them which could cramp your style a lot.

Besides, my impression was that there wouldn't really be any need for
any repitition in the first place, you'd just write one copy and then
list all your .xml files in PYXMLFILES and that's that.  But now I see
that's not the case:

> Yes, I do know that, and that's how I got this far. Basically, I write
> these rules in several Makefile.am's, since I have multiple directory
> setup. I would love to not duplicate the make code, and hide it all
> behind a single function call that can be expanded.

You could put the fragments in a common file and then include that file
in each Makefile.am that requires the functionality.  This gets around
the above problem of the fragments not being visible at automake time
since AFAIK automake can "see through" make-level includes (correct me
if I'm wrong anyone), which means you would be free to make use of
automake variables/features instead of having to tippy-toe around them
carefully.

Brian