[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 GNUstep.sh/environment 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.
- Re: gnustep-make experiment, (continued)
- Re: gnustep-make experiment, Wim Oudshoorn, 2007/02/09
- Re: gnustep-make experiment, Matt Rice, 2007/02/09
- Re: gnustep-make experiment, Dennis Leeuw, 2007/02/09
- Re: gnustep-make experiment, Fred Kiefer, 2007/02/10
- Re: gnustep-make experiment, Matt Rice, 2007/02/10
- Re: gnustep-make experiment, Alex Perez, 2007/02/10
Re: gnustep-make experiment, Nicola Pero, 2007/02/08
Re: gnustep-make experiment, Nicola Pero, 2007/02/10
Re: gnustep-make experiment, Nicola Pero, 2007/02/10
Re: gnustep-make experiment, Nicola Pero, 2007/02/10