Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
On Fri, May 19, 2006 at 09:35:57AM +0200, Turbo Fredriksson wrote:
> But regarding the build system, I REALLY object to any major changes! Fixes yes,
> but not REPLACEMENT!!
Well, it's a little late for that. ;-)
> The first build system really sucked. It took AGES to build, and that
I have no idea what the first build system was. I also don't really
> on a 'not-so-slow' machine (2x750MHz Ultra SPARC III, 2Gb mem and FC disks).
My current system takes less than 10 minutes on my machine, a single-CPU
Athlon64 with plain IDE disks and 1GB RAM.
On the autobuilder, build times for the current version of Bacula ranged
from 8 minutes on amd64 to 14 hours on m68k.
In contrast, here are some other build times, on amd64 and m68k:
vim: 20m - 25h
amanda: 2m - 2.75h (no GUI code)
xorg: 14m - 31h
linux-2.6: 6.5h - ?? (no successful build in logs for m68k)
So I'd say bacula is quite reasonably middle of the pack, at less than
half the build time of vim even. There are probably additional
optimizations possible with the current build system as well.
We don't have amd64 logs from the old build system of Bacula, but on
m68k, it took 11.85 hours. In other words, hacking up the build system
so much saved only 15%, and I haven't even tried to make optimizations
on the current one yet.
> A better, more dynamic way of building was needed. The simplest way of doing
> this was just build it ONCE and then only compile and link that stuff that
> was 'flavored'.
I don't think that was simplest. That involved all sorts of fragile
library lines. It involved setting the DEBUG environment variable to
link in specific libraries. It required hacks to configure, hacks to m4
macros, and broke whenever Bacula, any database, GUI toolkits, or
Kerberos revved. The package in sid couldn't build on sarge, and
vice-versa. Not only that, but when new binaries were introduced
upstream, it had to be hacked. It didn't clean up after itself well,
and was so convoluted that I was never sure that it actually did the
In short, it was a maintenance nightmare.
This is a backup program. If it is not readily apparent that we are
building it correctly, we have a bug.
I don't care if it takes 4 times longer to build this way. We stand a
much better chance of getting it to build correctly, and of not
introducing subtle bugs on each new upstream revision or change on
Here's another interesting metric:
-rw-r--r-- 1 jgoerzen jgoerzen 55954 May 11 08:15 bacula_1.36.3-2.diff.gz
-rw-r--r-- 1 jgoerzen jgoerzen 40554 May 16 21:32 bacula_1.38.9-9.diff.gz
The current diff.gz is 28% smaller than the previous diff.gz, and that's
in spite of a large increase in the size of debian/changelog, more
comments in the debian code, AND the introduction of a fourth
What's more, the way I build it is the way that is recommended by the
Developer's Reference, and the way that is used by vim.
I say that a 28% reduction in the size of the diff.gz, and a tremendous
gain in maintainability and correctness, more than makes up for a 15%
increase in build time. I'd say it more than makes up for a 400%
increase in build time, if that was the tradeoff.
> Yes, the 'hardcoded' library stuff isn't the most perfect, but paying attention
I'd rather not risk someone, even myself, failing to pay attention to
something if I can have it work correctly -- as upstream intended -- to