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
