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

[Bill Sacks]

Miles: Thanks for these additional thoughts.

I have been trying out a couple of methods for achieving what I want, but am 
running into problems. I'm probably going to put this migration to the 
autotools on hold for now, unless anyone has insight into a good way to set 
this up.

I first tried a prototype where user-added source code is built in its own 
library, to keep it isolated from the standard stuff. However, I ran into 
problems getting the dependencies to be worked out correctly, because it's 
likely that some user-added source will depend on existing code, and at the 
same time, some existing code will depend on user-added source.

So then I tried a prototype where user-added source is added in the same 
library as the existing code (this is most similar to our current system). I 
got this working with a simple example (the jupiter example from Ch. 5 of John 
Calcote's autotools book), by doing the following:

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)))

where Srcfiles contains:

print2.c

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. (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? And are there fundamental 
problems with automake not knowing all of the source files?

Thanks,
Bill

On Jan 14, 2012, at 4:09 AM, Miles Bader wrote:

> Bill Sacks <address@hidden> writes:
>> The dependency issue that Jeff raised is not a problem for us, since
>> we have a script to determine Fortran 90 dependencies.
>> 
>> I'm not sure that it will work to have a separate library of the
>> user-added code, since we don't know ahead of time what dependencies
>> there will be between existing code and the user-added code.
>> 
>> Your other suggestions are helpful. We'll give this some more thought.
> 
> I think the main thing to remember is that most traditional make
> facilities are still available, should automake's higher-level
> constructs not suffice, and the two can usually co-exist reasonably
> well.
> 
> So whatever you did before for user-contributed stuff may well work
> perfectly fine in Makefile.am (maybe with a few tweaks).
> 
> -miles
> 
> -- 
> Cabbage, n. A familiar kitchen-garden vegetable about as large and wise as a
> man's head.