Re: gnustep-make experiment

[Matt Rice]

On 2007-02-10 09:27:32 -0800 Nicola Pero 
<address@hidden> wrote:

> > 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.

Yes.... there would only be one, unless we wanted to get rid of 
GNUstep.conf entirely
then there would be about 5... you had reservations that GNUstep.conf 
and gnustep.pc
contained duplicate information... since theres no way to get what i'm 
trying to achieve from
GNUstep.conf, the only way around that would be to move everything in 
there to gnustep.pc.

thats where the 5 per makefile invocations come from.

If we retain GNUstep.conf and add gnustep.pc we only need 1...

> I consider that unacceptable considering we don't gain anything in 
> functionality, and
> the improvement in 'standardization' is extremely doubtful.

Of course we don't gain anything,
getting rid of GNUSTEP_MAKEFILES isn't anything...
ability to get information about GNUstep from the shell isn't anything

> > 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.

This was an attempt to state that if everyone created their own 
-config system
which if GNUstep.sh/environment variables goes away i strongly believe 
we
need. I would have 300 -config systems on my machine.

> 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.

that is not what i'm trying to do.... I'm attempting to *USE* 
pkg-config
WITH gnustep-make not instead of. pkg-config does not replace
configure/make even on gnome/gtk it provides a way to query information
about the installed packages for use WITH make.

> > 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. ;-)

at the possibility of repeating myself It is not always possible to 
use gnustep-make.
configure scripts and plugins for existing projects with existing 
build systems..

without environment variables, or a -config system there is no way to 
build a
GNUstep enabled gnuplot without converting its entire build system to
GNUstep-make this wouldn't fly.

> 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.

I don't care about a config file per library... libraries which are 
built with GNUstep-make
aren't hiding any information. gnustep-make has information only it 
can find.

> 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.

The only objection i've heard from gnustep.pc is "Its not the way 
GNUstep stores information".
The objection i have with GNUstep.conf is it isolates gnustep from the 
rest of the world.
It sure is easy to use from shell scripts....  but how are you 
supposed to find it when
it could be anywhere, somewhere only gnustep can find.

We cannot have a build system where information is only available to 
GNUstep-make.
I don't really care if GNUstep-make does its own thing... GNUmakefiles 
are really nice and
I agree, but it must play nice with the rest of the world.