On Mon, 2008-06-16 at 12:17 +0100, Jamie Lokier wrote: > Bernd Petrovitsch wrote: > > > _check_ for many installed libraries. Get them wrong, and you have > > > the same problems of untested combinations. > > > > As long as I can specify that libfoo support must be compiled in (and > > thus libfoo must be present) and the tools throw an error if it doesn't > > find it, I have no problem. > > Otherwise all package builders have a serious problem. > > They do have problems, when you want to repeatably build and deploy, > if the build environment isn't very similar each time. Sometimes you have a different build environments - if only that you want to rebuild e.g. your .src.rpm on several versions of CentOS and Fedora. > Typically the way you specify that libfoo support must be compiled in > is --with-libfoo=/path/to/libfoo. > > That way lies bitrot between your build script which calls ./configure Cannot be really avoided IMHO. > (since you won't by typing it manually with 20+ options like that each > time you rebuild), and the changing version of an upstream package you > configure. So be it. At least one sees errors/bugs immediately. > To prevent it trying to compile in libs you don't want, you also need > --without-libfoo. Using Kerberos as an example, which I remember when > building CVS ages ago: If you don't _prevent_ it using libraries you > don't want, you get different binariesn depending on whether a > Kerberos library was installed on the build system at build time. You > might then send a built program to another system, and find it won't > run at all, or has unwanted behaviour. > > Do you really see package building scripts with 20 --with-libfoo= and > --without-libfoo= options in them for every library? Sometimes. But For (in an ideal world 100%) repeatable builds - for a .rpm. .deb, some cross-compiled embedded device - one usually ends up with that explicit list (and IMHO it's the smaller PITA than to cope with strange bug reports because something was broken in the build weeks ago). Mainly because the dependency information is also present elsewehre (e.g. in the package). Or you really want control over the installed software. > more often, not: instead, they more often have build-time installed > prerequisites. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
