On Wed, Jul 04, 2001 at 01:20:36PM -0600, Tom Tromey wrote:
: >>>>> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
: Lars> I don't think the exponential nature of how AM_CONDITIONALs are
: Lars> handled is fixed yet, which *I* would consider a showstopper.
: Lars> Haven't checked latest CVS though, so excuse me if it's already
: Lars> fixed.
:
: I don't think it has been fixed.
: How could we fix it? I mean, conceptually.
One thing is to change how the *_OBJECTS variables are set up. For
each object that depends on some conditional, autogenerate a unique
variable name, and set up assignment to it above the *_OBJECTS variable
with only those conditionals that are relevant. Then just refer
to the variable in the _OBJECTS list. Consider this transformation:
if COND_WINDOWS
GUISOURCE = windows.c windows.h
else
GUISOURCE = gtk.c gtk.h
fi
bin_PROGRAMS = hello
hello_SOURCES = \
$(GUISOURCE) \
algorithm.c \
algorithm.h
should be transformed into something like this:
@COND_WINDOW_TRUE@GUISOURCE = windows.c windows.h
@COND_WINDOW_FALSE@GUISOURCE = gtk.c gtk.h
@COND_WINDOWS_TRUE@automake_obj1 = windows.lo
@COND_WINDOWS_FALSE@automake_obj1 = gtk.lo
hello_OBJECTS = \
$(automake_obj1) \
algorithm.lo
Such solutions should probably take care of the exponential growth in
file size (unless I've missed something). For memory footprint, some
other solution may be necessary. I don't know much about the Automake
internals.
Lars J
