[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slow makefiles are getting even slower
From: |
Zdenek Kabelac |
Subject: |
Re: slow makefiles are getting even slower |
Date: |
Thu, 15 Aug 2002 11:59:10 +0200 |
User-agent: |
Mutt/1.4i |
On Wed, Aug 14, 2002 at 05:56:26PM -0600, Tom Tromey wrote:
> >>>>> "Zdenek" == Zdenek Kabelac <address@hidden> writes:
>
> Zdenek> Am I the only one who is noticing constant slowdown of
> Zdenek> makefile.am processing
>
> Do you mean running automake or running make?
Well as I've said - checkout the speed of 'automake' generartion
for avifile project - libtoolize,aclocal, autoheader, autoconf
are slow as well - but automake beats them all as it's as slow
as all of them together.
I don't think I'm doing some bad - also I'm trying to keep it
compatible across many version of auto* tools so it's not
using the latest extensions of automake.
> Zdenek> it's really getting crazy - 9MB just for Makefiles...
>
> That is a bit absurd, though of course it depends on the layout and
> complexity of your project.
the size of after
with (left column - uptodate Debian Unstable):
autoconf (GNU Autoconf) 2.53
automake (GNU automake) 1.6.3
libtoolize (GNU libtool) 1.4.2a
right column - old Debian Potato: (which is also noticable faster)
Autoconf version 2.13
automake (GNU automake) 1.4
libtoolize (GNU libtool) 1.3.3
make maintainer-clean - ~ 9835KB 8401KB
autogen.sh - ~11865KB 9237KB
configure - ~16356KB 10689KB
so - ok it's not 9 byt almost 6.5MB but it's still unreal - the project
has 10MB of sources and auto* staff will take just over 65% just
for Makefiles to be able to compile project - there is really something
wrong within whole auto* architecture.
> I'd say that we care, but we just haven't prioritized it very highly.
Well I guess you all have PIV 2.5GHz boxes - but I could assure
you that auto* tools are becoming unusable on 400MHz Celerons even with 256MB
of memory - it takes ages to regenerate configure and Makefiles.
> My perception is that the complaints we see are about not having a
> smooth upgrade path, followed by feature requests. I haven't tried to
> actually measure that perception against reality. Also there are
Well you really should try it - it's really becoming a monster - and
when you take into account how much slower the gcc is becoming (especialy
for compilation of C++ projects) I'm starting to think that
Linux has been infiltrated with M$ people - as I have access to
many various intallations I could compare the project compilation
speed on various setups - and while 400MHz with old Potato and gcc-2.95.2
is just fine - the current auto* and gcc3.2 is just something unreal
and after all they both have to produce the same exectable...
> always complaints about the complexity of the system, which are
> justified but hard to derive patches from.
I've proposed several times few things which would certainly
drasticaly improve the speed - though they are for different
parts of auto* tools project - there were some reactions - but
so far non of them were realized and there is not visible any
progress here (and as I've said before the whole auto* stuff is getting
constanly slower and more space consuming - not mentining the
problems with backward compatibility).
--
.''`. Zdenek Kabelac address@hidden, users.sf.net, fi.muni.cz}
: :' : Debian GNU/Linux maintainer - www.debian.{org,cz}
`. `' Modern processors are the most advanced heating systems around.
`- www.tomshardware.com