On Thu, 2007-02-01 at 16:27 +0100, daniel fischer wrote: > skaller <[EMAIL PROTECTED]> (on Thu, 01 Feb 2007 12:02:02 +1100): > > > On Wed, 2007-01-31 at 23:53 +0100, Jens Peter Secher wrote: > > > On 1/30/07, Nicolas Cannasse <[EMAIL PROTECTED]> wrote: > > > > > pkg-config is a Debian thing. It provides the right include path and > compile > > > flags. > > > > No, yes. pkg-config is a *Red Hat* thing and it is frowned on by Debian. > > [As it should be, it's a heap of crap]. > > Yes, No. pkg-config is (mostly) a *Havoc Pennington* thing,
Indeed, > I oppose the idea that it's a heap of crap ;). > I find it one of the most useful tools around C development. That may be, but just shows the poor state of tools around > Obviously, assuring the correct version of dependencies is solved > with the various package managers on linuxes. I've been wanting to > propose something for assuring dependencies for neko-based haxelibs > that link against external libraries, but haven't gotten around to > trying/verifying it (yet). I know nothing about this. However there is a description of what my tool does here: http://www.felix.cybercloud.net/wiki/index.php/Flx_pkgconfig More comments below .. > Such a tool could well be thought as an extension to haxelib. > It would enable haxelibs to resolve their dependencies in > platform-specific ways (and avoid binary redistribution of > things that are mostly already installed on linuxen, like GTK). > What do you think, is that a good idea? I think you could write such a tool in Neko, NekoML, or whatever. My design is roughly based on these ideas: * NO defaults: the directories to be searched must be specified explicitly with --path=/dir/... switches * The algorithm searches from a specified set of starting packages, given by arguments without options * The algorithm uses recursive descent on a nominated field (defaulting to 'Requires') .. if, and only if, recursive search is specified. * The algorithm scans fields within a package, and collects all the contents of specified fields * if the field is BEFORE the 'depends' field it is emitted first, before dependencies, and if it is AFTER the depends field it is emitted last, after the dependencies * there is a switch to reverse the scan order * duplicate fields can be elided in an order preserving way with the --keepleftmost --keeprightmost switches * you can choose if missing specifications cause an error return, and you can do various lists to check on the integrity and availability of packages * MS style @response files are supported The overall design is entirely independent of any knowledge of C, shared libraries, or any other thing. It is simply a recursive descent with pretty printing selected fields in descent order, with control over duplication This is (just) enough to manage shared libraries and library path resources for C correctly. In particular the standard fields provides_dlib: -lpkga provides_slib: -lpkga indicate shared and static libraries, and should be scanned differently. On Elf systems static libraries are scanned with --rec option to obtain transitive closure. On Windows and non-elf systems, you do this also for DLLs. On Linux and Solaris and other Elf systems you do NOT use recursion but only name libraries used *directly* by a component (Elf loads the latest suitable version of dependent libraries automatically). This program is NOT really enough .. but is already much better than pkg-config simply because what it does is just basic mathematics independent of any language. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net -- Neko : One VM to run them all (http://nekovm.org)
