Re: Extending automake

[Andrew Suffield]

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