[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 12:53:55 -0800
User-agent: GNUMail (Version 1.2.0)

On 2007-02-10 11:48:55 -0800 Richard Frith-Macdonald <address@hidden> wrote:

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 actually don't care about replacing GNUstep.conf at all....
I see how in certain cases you could(?) want to relocate GNUstep without recompiling GNUstep, and I consider this a highly niche situation, or override
configuration options for a precompiled GNUstep installation.
I consider *THIS* a niche situation... I can see how you might want to do it but... it aint a bad thing... but it seems such an uncommon practice I don't even see why we are arguing modifying 2 files is harder than 1 file for something very few libraries provide, and very few users will attempt. Add to this that you'd only have to modify 2 files .pc and .conf when the *developer* changes his build system.

Nicola or someone.
had reservations that GNUstep.pc contained duplicate information already stored in GNUstep.conf. I admit... using pkg-config to replace GNUstep.conf does not look like a good idea and is not the direction i'd want to take it.. but it would be possible.

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.

Agreed this actually was not the motivation behind the idea but is an added benefit.
for getting rid of GNUSTEP_MAKEFILES.

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.

Seems we're trying to comprimise with something neither you not I want :P
All GNUstep software has the same flags except the -l...
This would be more standard for each lib to have a .pc
but I don't consider it neccesary

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.

Yes it does add something... I can configure GNUstep to install into /some/random/path
and pkg-config would work without setting GNUSTEP_MAKEFILES.
It provides a single set of instructions for configuring a GNUstep build environment.

no if its installed in a standard location just type 'make', otherwise set GNUSTEP_MAKEFILES to the path where you installed GNUstep. (where did my distro install GNUstep the user asks?)

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.

I'm not talking about GNUstep here.. I believe GNUstep _needs_ a -config system. I don't see any point in not using pkg-config. the 300 pkg-config enabled libraries
on my system didn't need their own.

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

It should be i've stated it many many times...

and to provide a way to query GNUstep path configurations from outside of GNUstep

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.

gnuplot has something to the effect of

enter objc code...

this is in the normal .c files that build gnuplot
if it can find and define HAVE_AQUA_TERM, it adds the -L/-I/-l options to gcc along with -x objective-c to the gcc flags and everything is built using the normal gnuplot build system

GDL2 needs to be able to query for libInterfaceBuilder so that it can enable or disable configuration of its Gorm palette I could ask Greg to install Auxiliary/Gorm.make but would much prefer to just

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.

GNUstep.conf cannot be found its path is hard coded into GNUstep-make
and can be configured from gnustep-make.... It is completely useless for this purpose.

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.

Again GNUstep.conf is unable to be found by these things...

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.

No, If pkg-config cannot find the gnustep.pc the user has an incorrectly set up pkg-config configuration, it the 'x' software package autoconf script cannot find GNUstep.conf it has a correctly set up GNUstep, but external software cannot find it...

I could add --with-gnustep-conf= to tell gdl2 where to find GNUstep.conf or require GNUSTEP_CONFIG_FILE so its configure script can look for libInterfaceBuilder if the user has a non-standard location for GNUstep.conf
 but that just seems absurd.

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.

Then get rid of --with-config-file= from makes configure... it's not a 'standard location' it's a default location. with a non-default GNUstep.conf GNUstep-make works fine yet a theoretical GDL2 configure script would require GNUSTEP_CONFIG_FILE or --with-gnustep-config-file= flag set to the make was configured --with-config-file= with. so it can check for libInterfaceBuilder and enable or disable building of the palette... the most likely output of this circumstance would be "why didn't it compile the GDL2 Palette?"

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]