Re: dpkg compile/development times
On Sat, 8 Nov 1997, Ian Jackson wrote:
> I got to the point with some of my recent dpkg-hackery where I wanted
> to compile the result. However, I found that it was difficult for a
> couple of reasons.
I share the same sentiment as Ian. Deity also uses automake, libtool and
gettext and it is very fragile, slow and has many problems.
> Firstly, the way the build process has been changed to use automake,
> libtool &c has made it much more fragile, and dependent on recent
> versions of many of these tools - which are only available in
> unstable. I understand that Klee hopes to fix this.
> In particular, libtool is extremely slow, and requires all the files
> to be compiled twice.
I found if you run configure with '--disable-nls --disable-static' your
compile times will drop. This will cause libtool to only generate the .lo
files and ignore static libraries. You might also find that a good portion
of time is being chewed by autodepends, I haven't found any way to speed
them up, cpp is just slow :<
> Some timings: I compiled the lib directory after editing dpkg-db.h,
> and that took nearly 10 minutes. Editing a single short file in the
> lib directory and then using Emacs M-x compile produces:
> - 4 seconds while Emacs and make start up.
> - 13 seconds while dependencies are calculated and libtool is
> called and thinks about what to do
> - 7 seconds to compile the file
> - 6 seconds to compile the file again
> - 17 seconds while libtool in link mode decides what to do
> - 4 seconds while gcc generates a shared library
> - 5 seconds while ar generates an unshared library
Wow, I never knew how much time libtool was chewing up. Here it seems to
be instant, the largest proportion of time is definately spent by gcc.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .