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

[Stefano Lattarini]

Hi Miles, thanks for chiming in.

On 01/19/2012 02:49 AM, Miles Bader wrote:
> 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).
>
Well put; this was what I meant, but I failed to communicate it correctly.
Thanks for filling the gap.

>  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:"
> rule.
> 
> 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 Makefile.am 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,
>
In this particular case, the OP is already assuming GNU make, so
using its specific features in our example is OK I think.

(BTW, note that also $(notdir ...) and '%' pattern-rules are GNU make
specific BTW, or at least not portable to all make implementations).

> but the same thing could be accomplished
> for portable make using a make-time-generated sub-makefile ("echo ...
>> Makefile.tmp; $(MAKE) -f Makefile.tmp").
> 
> -Miles
> 
Still, things are not as easy as it would appear from your sample project.
For example, with this rule:

  $(CC) -c $(CFLAGS) -DIM_STUUPD=1 $<

you are losing some important features offered by automake -- most
notably, the automatic dependency tracking and the configurable verbosity
specification (silent-rules).  Which might be OK in some circumstances,
but unacceptable in others.

Anyway, I think a modified version of your example would make a nice addition
to the automake test suite and manual.  I'll write a patch in the next days.

Thanks!

Stefano