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.
(P166 32M)
Jason
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: