Re: gnustep-make experiment

[Nicola Pero]

> 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