>> pkg-config doesn't do that. its an almost impossible task unless you > >Are you talking about some new tool that I had not previously heard >about or are you talking about a script like the >'/usr/local/bin/gnome-config' I see on my system?
its a replacement for *all* such scripts. its a C program that works with a great deal more intelligence than those scripts. its independent of GNOME and everything else, for that matter. >Unfortunately gtk standardized this type of script through >proliferation. The proliferation occured because no other option was >offered. It's mere popularity does not make it the right solution. absolutely. thats why i am so enthusiastic about pkg-config. unlike those silly scripts, pkg-config centralizes the information and at least in theory it offers a point at which the kind of rationalization and ordering problems discussed here can be solved. >The scripts options do not even align with Autoconf since Autoconf >distinguishes options with finer granularity than the *-config scripts >do: > > *-config Autoconf > ========== ================= > --libs LDFLAGS + LIBS > --cflags CPPFLAGS + CFLAGS > >The munging of LDFLAGS and LIBS to create the output from the --libs >option creates a bloody mess when you try to blend these options >together. Linker directory search order and library link order are >totally lost if a simple concatenation of options is used. Understood. As I mentioned before, this is an impossible task to automate in the general case. >The only proper solution is one based on a rules database in which the >dependency requirements for each package can be expressed so that the >dependencies can be reliabily satisified by the build environment. No, thats insufficient. Link order is not solely a function of dependency requirements. Its a complex interaction of user intent, system configuration and library contents. Since the user intent is the wild card, only some method by which the user can clearly express her intent will work. If I want to link libhoard in at an early stage, and libdmalloc later on, because i want free/malloc/realloc from hoard to be used by the earlier objects, but the ones from dmalloc to be used by the later ones ... there is no way that a dependency database can infer this. >Libtools .la files do not provide this database. Pkg-config scripts do >not provide this database. They do not, but they are closer to it, and form a much better starting point than the godawful mess that libtool has turned into. "libtool --gdb" for crying out loud! --p _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
