bug-automake
[Top][All Lists]
Advanced

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

Re: Superlinear slow-down for each new AM_CONDITIONAL if...endif?


From: Alexandre Duret-Lutz
Subject: Re: Superlinear slow-down for each new AM_CONDITIONAL if...endif?
Date: Wed, 15 Oct 2003 00:16:24 +0200
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)

>>> "Simon" == Simon Josefsson <address@hidden> writes:

 Simon> I use AM_CONDITIONAL and have 15 'if...endif' in a Makefile.am.  After
 Simon> adding the last 2 of the 'if..endif' I notice an extreme slow-down
 Simon> when running 'automake'.  What used to take seconds now takes 2
 Simon> minutes, on a fast machine.  Removing one of the 'if...endif' speed it
 Simon> up to say 20-30 seconds, removing another make it fast again (<5s).
 Simon> Fairly normal Debian machine, with auto*/libtool from testing.

 Simon> 'strace' indicate the delay is CPU bound, but using 2 CPU minutes on a
 Simon> P4 2.8GHz seem a bit excessive.

I seem to recall people reporting overnight runs :)

 Simon> Any ideas?

Yes.  First, thank you for taking the time to make such a
precise report.

This combinatorial explosion is a known problem of Automake
1.7.x and prior.  The NEWS file of the upcoming 1.8 contains the
following entry:

| * Bug fixes
| 
|   - Defining programs conditionally using Automake conditionals no
|     longer leads to a combinatorial explosion.  The following
|     construct used to be troublesome when used with dozens of
|     conditions.
| 
|       bin_PROGRAMS = a
|       if COND1
|         bin_PROGRAMS += a1
|       endif
|       if COND2
|         bin_PROGRAMS += a2
|       endif
|       if COND3
|         bin_PROGRAMS += a3
|       endif
|       ...
| 
|     Likewise for _SOURCES, _LDADD, and _LIBADD variables.

One way to work around this problem in 1.7.x is to use
the other documented way to make conditional compilation
(AC_SUBST + EXTRA_).  But that's admittedly ugly.

I you feel adventurous, I'd recommend you install CVS Automake.
This should allow you to use this construct and, ahem, maybe
give you the opportunity to send us more nice bug reports...
-- 
Alexandre Duret-Lutz





reply via email to

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