On 2007-02-10 11:48:55 -0800 Richard Frith-Macdonald
<[EMAIL PROTECTED]> 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 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.
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...
to bootstrap GNUSTEP_MAKEFILES
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
#ifdef HAVE_AQUA_TERM
enter objc code...
#endif
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
use AC_CHECK_LIB.
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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev