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 care. > 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 right thing. 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 Debian. 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 backend (sqlite3). 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 start with. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]