Hi Miles, thanks for chiming in. On 01/19/2012 02:49 AM, Miles Bader wrote: > 2012/1/19 Stefano Lattarini <stefano.lattar...@gmail.com>: >>> 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