[Top][All Lists]

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

Re: gnustep-make experiment

From: Richard Frith-Macdonald
Subject: Re: gnustep-make experiment
Date: Sat, 10 Feb 2007 19:48:55 +0000

I haven't followed this in particular detail, and I haven't looked at the actual work you have done, so I might well be missing some points or misunderstanding ... sorry, just haven't had time.

First I'll say how I think pkg-config could be useful for GNUstep.
Then I'll address points in your email from the perspective of your apparent desire to use pkg-config to replace the existing GNUstep.conf stuff.

I think it would be nice for external (ie not basically ObjC/GNUstep code) packages to be easily able to link with GNUstep libraries and frameworks without using gnustep-make. That is, to be able to easily get command line arguments for all dependencies of a library rather than just the library location. This is a low priority niche requirement as few packages will want to link with ObjC/GNUstep code unless they are ObjC/GNUstep packages themselves, in which case the many advantages of gnustep-make mean that a reasonable developer would just just gnustep-make anyway.

If we are going to provide this facility then, as it's only for a tiny minority of users, we can reasonably require them to install/use another package such as pkg-config (I don't think we could justify imposing such a requirement otherwise).

The obvious thing to do then is modify gnustep-make such that, when it builds a library, framework, or bundle, it also generates a pkg- config metadata file so that we can install that metadata file with the library/bundle/framework and people can use pkg-config to link it in to their project. This in no way implies that gnustep-make or makefiles which use gnustep-make should ever make use of this metadata (it's probably unnecessary for them and undesirable to make gnustep makefiles depend on another external program), but having the metadata files there for external projects would be really good. If this means that gnustep-make stores some redundant data, I don't think that's any problem, we aren't talking about a lot of space here.

On 10 Feb 2007, at 18:23, Matt Rice wrote:

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

Well, Nicola already pointed out how to get rid of GNUSTEP_MAKEFILES ... so pkg-config doesn't add anything there, and we already can get information about GNUstep from the shell, so pkg- config doesn't offer anything there either.

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.

But you haven't provided any evidence to suggest that people need to create their own config systems for GNUstep, let alone anything to suggest that they need 300 config systems for GNUstep.

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.

It's still not clear what you want to use it to do and why ...

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

That may be true, but again I've seen no evidence to support it. I would imagine it's pretty much always possible to hook into it somehow. More likely some people just don't want to.

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.

Well, GNUstep.conf provides you with environment variables if you want them. As Nicola pointed out early on in this thread, it was deliberately designed so that it could be executed/sourced both by a shell and included in a makefile, so that lets you set up the variables.

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.

It, and any shell script using GNUstep.conf, and any makefile including GNUstep.conf, and indirectly anything else which can be called from a shell script or makefile or have information passed to it from a shellscript or makefile.

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

I think the big objection which has been presented more than once in this thread is that it's a dependency on external software which you might have to install on systems. To justify the obvious disadvantage of such a dependency you would need some clear benefit, and I haven't seen any benefit mentioned, except perhaps that it would be more familiar to existing users of pkg-config who don't want to use gnustep-make.

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.

Same applies to gnustep.pc ... it could be anywhere. Usually it's in a standard/common location, but you can say the same about GNUstep.conf. In this respect there is no difference between the two and its therefore illogical to use it as an argument either way.

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.

The current setup was particularly designed to 'play nice with the rest of the world'. You can't get much nicer than a file in a standard location which both the shell and makefiles can use. A pkg-config file on the other hand does *not* play nice with the reset of the world. It can't be used except on systems where pkg-config is installed or where software is specially written to read it.

It seems to me that GNUstep.conf and pkg-config have rather different purposes. GNUstep.conf is distinctly more universal/portable which is critical for its intended use of relocating software and controlling options. On the other hand pkg-config metadata is convenient for getting command line flags but no good when pkg-config is not installed. So I like pkg-config as an option for external use, but not as a dependency... I'm in favor of gnustep-make storing the info it needs redundantly so that our makefiles can run reliably but people can use pkg-config externally.

I often need to build gnustep-base and proprietory software which uses it on solaris (and sometimes windows) systems that I don't own ... and the fewer packages I have to install to do it, the better.

reply via email to

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