Re: Automake 1.4h

[Tom Tromey]

>>>>> "Lars" == Lars J Aas <address@hidden> writes:

Tom> How could we fix it?  I mean, conceptually.

First off, let me just say that I was considering a larger problem.  I
was thinking about how to solve the exponential explosion problem for
any random variable whose contents we cared about.

But I think you're right in that it is most important for _SOURCES,
and fixing it there would certainly help.

Lars> One thing is to change how the *_OBJECTS variables are set up.
Lars> For each object that depends on some conditional, autogenerate a
Lars> unique variable name, and set up assignment to it above the
Lars> *_OBJECTS variable with only those conditionals that are
Lars> relevant.

Suppose we are looking at `windows.c'.  Doesn't computing the
conditions under which windows.c is built require us to look at every
value hello_SOURCES can take?  Thus hitting the exponential?

However, I think we might be able to do it by looking at variables and
not objects or conditions.  In fact I think that is what your first
example (the one you said was wrong) did:

Lars> if COND_WINDOWS
Lars> GUISOURCE = windows.c windows.h
Lars> else
Lars> GUISOURCE = gtk.c gtk.h
Lars> fi
Lars> bin_PROGRAMS = hello
Lars> hello_SOURCES = \
Lars>   $(GUISOURCE) \
Lars>   algorithm.c \
Lars>   algorithm.h

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

Here automake_obj1 is the "renamed" GUISOURCE.

Now suppose GUISOURCE is defined in a more complex way:

    if BAR
    extra = extra.c
    endif

    if COND_WINDOWS
    GUISOURCE = $(extra) windows.c windows.h
    else
    GUISOURCE = gtk.c gtk.h $(extra)
    endif

Then we generate:

    @address@hidden = extra.o
    @address@hidden =
    @address@hidden = $(automake_obj2) windows.lo
    @address@hidden = gtk.lo $(automake_obj2)

The idea here is that we only have to transform each variable
containing sources a single time (per program or library -- we have to
name objects different if there are per-exe flags in effect).  So the
behavior will never be exponential.


Right now I don't see any problem with this approach.  We do need to
traverse all the objects for a given program, because we need to know
the type of each one to determine the correct linker.  But we can
still compute that with the above.

Unfortunately, looking at handle_single_transform_list and
handle_source_transform, I think this is going to be a fairly major
piece of surgery.  These functions aren't very well factored, at least
not in terms of the modification at hand.

Comments?

Tom