> a quick test of a makefile executing pkg-config 1000 times takes about 6 > seconds.. > say there are 5 invocations of pkg-config per invocation of make... thats 200 > make > processes.
Wow - that would be a massive overhead ... for just reading config (ie, doing nothing useful, only bootstrapping)! ;-) I thought in the worst case scenario you'd run 1 pkg-config invocation per makefile -- that would be pretty bad already since you're doubling the number of processes executed when typing 'make' in an already built tree; but if you plan on adding 5 per makefile invocation, then you're almost multiplying by 6 the overhead of the building system. In practice it will be less than that, but a x2 or x3 sounds perfectly plausible. I consider that unacceptable considering we don't gain anything in functionality, and the improvement in 'standardization' is extremely doubtful. > if we want a decent -config system, we're going to reimplement pkg-config... > on my system i have over 300 pkg-config enabled libraries... and i'm glad I > don't have > 300 foo-config scripts in my $PATH. They are different things ... GNUstep has got a single config script for everything. We don't install a config file for each library. If you are obsessed with using pkg-config for GNUstep, then it would make sense to install a pkg-config config file for each library that we install ... so you would have a pkg-config configuration for libgnustep-base, libgnustep-gui, etc. Then people using pkg-config instead of gnustep-make to build their software could at least use them in the way they are intended to be used. Still, I can't see any advantage in using pkg-config instead of gnustep-make, so I don't really understand why anyone would want to do that. You'd be on your own in the nightmare of how to compile or link your framework on all different machines and platforms. > I think this would be a step in the right direction but everybody has already > been down > that road and since then switched to pkg-config. I don't see the parallel. We are following a completely different road than everyone else - we have a centralized, standardized building system, a centralized, standardized core ObjC API, a centralized, standardized GUI API, and everything else is built ordinately on top of that by the same organized building system. ;-) Other people don't have that. Each library is built in a different way and installed in the different way with different options; each library is using a different subset of libc and other system libraries, which vary a lot between different systems; it's a mess with millions of non-standard flags and locations and conf options and system dependent flags to determine and use. :-( So, some of them figured out they'd put each library's flags into some common format to put some order in the mess. Fine. But we don't have that problem. We have organized and standardized everything. Our system is certainly "unusual", but well-organized and laid out. It's a pleasure to write your quick GNUmakefile listing what goes into your library, knowing that you don't have to do anything and it will just work on GNU/Linux/*BSD/Windows/Apple. The usual libc/compatibility/flags nightmare does not exist in our organized world. So saying that we're going through the road of everyone else is inaccurate to say the least. We're not planning to have a config file per library. We just have a plain-text file where we put a key=value list of basic system-wide GNUstep configuration. So, yes, our solutions might be different. GNUstep is different. The only objection to GNUstep.conf I heard up to now is that "it's not the way the gnome stores config". I don't see the point. Apache stores config in httpd.conf, including paths to resources or web pages. So what's the big deal. It's what is appropriate for them to do. Thanks _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
