automake
[Top][All Lists]
Advanced

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

Re: automake 1.8 performance problems


From: Alexandre Duret-Lutz
Subject: Re: automake 1.8 performance problems
Date: 01 Apr 2004 11:40:25 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.3.50

>>> "Harlan" == Harlan Stenn <address@hidden> writes:

 Harlan> OK, I think I have something.
 Harlan> If AC_CONFIG_AUX_DIR is populated, automake runs in 9-15 minutes of
 Harlan> wall-clock time.

 Harlan> If it is not populated (except for ltmain.sh) then it
 Harlan> takes 45 minutes to run.

 Harlan> The items that end up in AC_CONFIG_AUX_DIR are:

 Harlan> compile*       config.sub*  install-sh*  missing*
 Harlan> config.guess*  depcomp*     ltmain.sh    ylwrap*

 Harlan> Does this help at all?

There is a slowdown to expect when the auxdir is populated.
This is because the Makefile that cause depcomp (for instance)
to be installed is usually not the same as the Makefile that
will distribute it (the latter is the auxdir/Makefile or the
top-level Makefile).  When automake detects such a situation, it
simply schedule a second pass to process again all the Makefiles
(now the aux files are installed they will be automatically
distributed by the right Makefile).  The --verbose option
will print "processing Makefiles another time to fix them up"
when this happens.

This behavior would explain why automake sometimes takes twice
more time; not as much as what you observe.  I should also adds
that Automake has a sanity check that ensure this "reprocessing"
does not occur more than once.

It seems to me it might be possible to suppress this
reprocessing my letting Automake select a good processing order
for the Makefiles: process the Makefile that will ship the
auxdir files after all the other Makefiles.
-- 
Alexandre Duret-Lutz





reply via email to

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