[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: allowing users to add source files without rerunning the autotools?

From: Miles Bader
Subject: Re: allowing users to add source files without rerunning the autotools?
Date: Thu, 19 Jan 2012 10:49:01 +0900

2012/1/19 Stefano Lattarini <address@hidden>:
>> I assume you're referring to the section describing why automake doesn't
>> support wildcards, which I have seen. I was hoping this meant that, "to
>> the extent that you list source files, they need to be listed explicitly".
> No, it means "you have to list all your source files, period." :-(  Sorry.

It's not true though....

> Here is an excerpt from the manual that should make this clean (from the
> paragraph 8.3.1 "Conditional compilation of sources"):
>  Automake must know all the source files that could possibly go into a
>  program, even if not all the files are built in every circumstance.
>> But your statement supports the alternative, and more likely, interpretation,
>> which is that automake has to know about all source files in order to work
>> correctly.
> Basically, this is the correct interpretation.

It's not really.

Automake needs to know about everything that _it interacts with
directly_ (for obvious reasons).   Automake does a lot of stuff --
building, cleaning, packaging, etc -- so in most cases that means it's
very desirable to just tell it about as much as possible, but if you
have other stuff, you can add your own rules to deal with them, as
long as there's an automake-known intermediary, e.g. a library: the
name of the library is known to automake but the sources used to build
it are not.  It works fine, but of course you don't get any of the
automake conveniences for those things (probably the most important
being dependency generation, but I guess fortran doesn't have that
even for automake-handled stuff!).

For cleaning non-automake-handled stuff, you can add a "clean-local:"
rule (and "maintainer-clean-local:" etc) that does cleaning however
you want.  The automake-generated clean rule will depend on it, but
you control what it does.  For packaging, you can use the "dist-hook:"

I do this in my own project to embed a Lua distribution:  my program
is 95% "automake handled" but depends on "liblua.a", and I provide
olde-style make rules in to build liblua.a, and use
clean-local etc to clean up after this, and dist-hook to stick the
library sources into my tarballs.  It works like a champ, and indeed
is quite convenient:  automake takes care of 99% of the disgusting
details, and I only have to add a little make-style grot to handle
this one case.

I've attached a sample project (the tarball generated using its own
"make dist") that has _no_ automake-known source files (..._SOURCES is
empty), and the real source ("stuupd-main.c") is discovered at
build-time using $(wild stuupd-*.c); obviously in a real program
..._SOURCES would probably have much more stuff in it.  $(wild) is of
course a GNU make feature, but the same thing could be accomplished
for portable make using a make-time-generated sub-makefile ("echo ...
> Makefile.tmp; $(MAKE) -f Makefile.tmp").


Cat is power.  Cat is peace.

Attachment: stuupd-1.tar.gz
Description: GNU Zip compressed data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]