On Sun, Aug 01, 2004 at 03:47:36PM -0400, Chris Lee wrote: > Even removing the ability to provide the foo_METASOURCES = AUTO would be > fine with me if I could at least do 'foo_METASOURCES = foo.moc bar.moc' > but at the moment I still don't quite grok how to do that.
I generally do this sort of thing (three times now) by writing a perl script that generates makefile chunks, which I have include directives for. This script handles any appropriate scanning or higher-level input files and rule generation. With a little imagination and *proper* development work (not the ham-handed effort that many people, especially projects like KDE, tend to put into their build systems) it can be done neatly, maintainably, and with a minimum of fuss. I don't believe it's possible without adding an extra pass. Nor does it seem particularly useful to do so. The trick is to not do it stupidly, like the current KDE build system does. There's no reason why the higher-level description should pretend to be a Makefile.am. Don't "customize" the automake input format - make up your own in a way that's appropriate to the problem (possibly you can do it with no input file at all, and just hardcode the behaviour into the generating script), and generate classic makefile chunks, then feed these back to automake with include directives. As a matter of form I try to generate makefile chunks that just contain variable definitions (and sometimes dependencies), and put the rules and automake variables into the Makefile.am proper - even if I end up with "foo_SOURCES = $(foo_sources)". If I have rules that are common to several makefiles, I use something like "include $(top_srcdir)/build-misc/docbook.mk". -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
signature.asc
Description: Digital signature