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

[Bill Sacks]

Hi Stefano,

Thank you very much for your fast and very helpful reply. This looks like a 
clever solution. However, I should have been more clear: In my prototype, 
Srcfiles is a static file, but in our actual build system, Srcfiles will be 
generated by a rule in the makefile. (In particular: we use a script to find 
all user-created source files in a number of pre-defined locations.) Please 
correct me if I'm wrong, but my understanding is that your proposed solution 
can't be extended to that case. 

Actually, the fundamental problem that I'm trying to address here is just that: 
Can we use an autotools-based build and still allow for user-created source 
files that are unknown until build time, and if so, what is the most robust way 
to do that?

>> And are there fundamental problems with automake not knowing all of the 
>> source
>> files?
>> 
> Yes; definitely yes.  See the automake manual for more details (I'd give you
> a more precise link, but today it seems that gnu.org has "gone dark to raise
> awareness agains SOPA and PIPA bills").

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". 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.

Thanks again,
Bill

On Jan 18, 2012, at 11:03 AM, Stefano Lattarini wrote:

> Hi Bill.
> 
> On 01/18/2012 06:42 PM, Bill Sacks wrote:
>> 
>> [SNIP]
>> 
>> This would be the typical way to set up Makefile.am:
>> 
>> noinst_LIBRARIES = libjupcommon.a
>> libjupcommon_a_SOURCES = jupcommon.h print.c jupcommon2.h print2.c
>> 
>> Instead I did the following:
>> 
>> noinst_LIBRARIES = libjupcommon.a
>> libjupcommon_a_SOURCES_standard = print.c
>> libjupcommon_a_SOURCES := $(libjupcommon_a_SOURCES_standard) $(shell cat 
>> Srcfiles)
>> am_libjupcommon_a_OBJECTS := $(addsuffix .o, $(basename 
>> $(libjupcommon_a_SOURCES)))
>> 
> This is probably doomed to failure, since Automake needs to process the
> contents of libjupcommon_a_SOURCES at automake runtime.  In particular,
> any GNU-make specific syntax used in the value of libjupcommon_a_SOURCES
> won't be recognized by automake.
> 
>> where Srcfiles contains:
>> 
>> print2.c
>> 
> I assume this 'Srcfiles' file is static, and not generated by rules in your
> Makefile, right?  In this case, you could generate, from the 'Srcfiles'
> file itself, a Makefile.am fragment, that will add the extra files in there
> to $(libjupcommon_a_SOURCES):
> 
>  libjupcommon-sources.am: Srcfiles
>       echo "libjupcommon_a_SOURCES += `cat Srcfiles`" >$@
> 
> Then you can include it in your Makefile.am to extend the "default" value
> of $(libjupcommon_a_SOURCES):
> 
>  libjupcommon_a_SOURCES = print.c
>  include $(srcdir)/libjupcommon-sources.am
> 
> This should work; but has the downside that you'll also a script to
> bootstrap your initial Makefile.in, by creating an initial version of
> 'libjupcommon-sources.am'.
> 
>> However, the manual specification of am_libjupcommon_a_OBJECTS feels like
>> something I shouldn't be doing -- I'm worried that will make the build system
>> less robust. But some sort of manual creation of the OBJECTS list seemed
>> necessary since automake didn't know all of the source files.
>> 
> This was to be expected unfortunately, given the rationale above about
> Automake not grasping GNU make constructs.
> 
>> (I also left out the header files so that the OBJECTS list would be created
>> correctly, but I'm less worried about that.)
>> 
>> Is there a more robust way to achieve the same thing?
>> 
> You might give a try to my advice.  I can't assure it will work, but IMHO
> it's worth a shot.  And if something is unclear or confusing, just ask.
> 
>> And are there fundamental problems with automake not knowing all of the 
>> source
>> files?
>> 
> Yes; definitely yes.  See the automake manual for more details (I'd give you
> a more precise link, but today it seems that gnu.org has "gone dark to raise
> awareness agains SOPA and PIPA bills").
> 
> HTH,
>  Stefano