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. 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 (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. 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 more often, not: instead, they more often have build-time installed prerequisites. -- Jamie -- 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
