automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automake 1.4h


From: Lars J. Aas
Subject: Re: Automake 1.4h
Date: Wed, 4 Jul 2001 21:26:02 +0200
User-agent: Mutt/1.2.5i

On Wed, Jul 04, 2001 at 01:20:36PM -0600, Tom Tromey wrote:
: >>>>> "Lars" == Lars J Aas <address@hidden> 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:

@address@hidden = windows.c windows.h
@address@hidden = gtk.c gtk.h

@address@hidden = windows.lo
@address@hidden = 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]