[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnustep-make experiment

From: Matt Rice
Subject: Re: gnustep-make experiment
Date: Sat, 10 Feb 2007 10:23:51 -0800
User-agent: GNUMail (Version 1.2.0)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]