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: Thu, 5 Jul 2001 14:04:26 +0200
User-agent: Mutt/1.2.5i

On Wed, Jul 04, 2001 at 09:26:02PM +0200, Lars J. Aas wrote:
: 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.
: [...]
: For memory footprint, some other solution may be necessary.

Changing focus to the individual objects instead of the _OBJECTS variable
should actually change the memory footprint, since you would simply iterate
over the list of objects instead of exhaust all the conditional permutations.
You would of course still have exponential growth on a per-object basis,
but each object should depend on a much smaller number of conditionals
(typically just one) than what the total object list does.

Does this make sense?

The sample transformation was btw wrong - it would probably be more like
this:

if COND_WINDOWS
GUISOURCE = windows.c windows.h
else
GUISOURCE = gtk.c gtk.h
fi

becoming

@address@hidden = windows.lo
@address@hidden =
@address@hidden =
@address@hidden = gtk.lo

hello_OBJECTS = \
  $(automake_obj1) \
  $(automake_obj2) \
  algorithm.lo

  Lars J



reply via email to

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