Re: possible fix for PR/315

[Richard Boulton]

On Mon, 2002-04-22 at 21:35, Alexandre Duret-Lutz wrote:
> Richard, is the code I'm destroying below very important?  I've
> got the impression it was just a "bonus-optimization", but I
> can't say I understand all the issues with conditional
> combinatorial explosions and al.

I'm not totally certain.

I believe it is important: consider the following Makefile.am:

====BEGIN====
if FOO1
A1=1
endif

if FOO2
A2=2
endif

...

if FOON
AN=N
endif


B=$(A1) $(A2) ... $(AN)

c_SOURCES=$(B)
d_SOURCES=$(B)

====END====


With your patch, c_OBJECTS and d_OBJECTS will not share any variable
definitions.  This means that they will each cause N am__objects_*
variables to be defined.

Now, in the case of a testsuite containing lots (>100) of small C
programs, all testing the same set of source files, this could easily
become unmanageable very quickly.

Note that this complexity scenarios probably isn't just theoretical: I
only coded the patches when I encountered problems with speed of
automake.


I note that the information required to do the proper fix for this is
available at (about - I have a slightly locally modified automake.in)
line 1887:

        # This holds the `aggregate context' of the file we are
        # currently examining.  If the file is compiled with
        # per-object flags, then it will be the name of the object.
        # Otherwise it will be `AM'.  This is used by the target hook
        # language function.
        my $aggregate = 'AM';

The function containing this is reasonably close in calling sequence to
&subobjname: I can't quite work out the relationship in a brief glance -
it's all very contorted - but if it was possible to pass the contents of
$aggregate to &subobjname; I believe a better solution could be
effected.

Hope that helps.

-- 
Richard