Re: gnustep-make experiment
On 2007-01-24 02:29:36 -0800 Matt Rice <[EMAIL PROTECTED]> wrote: attached is just sort of an experiment in getting rid of GNUstep.sh to compile stuff don't know if i expect anything to come out of it really, but figured i'd send it anyways :P apologies.. there were a number of issues when I switched over to pkg-config from a custom gnustep-config... this one should actually work Index: configure.ac === --- configure.ac(revision 24410) +++ configure.ac(working copy) @@ -224,6 +224,36 @@ AC_SUBST(GNUSTEP_CONFIG_FILE) #- +# location of GNUstep make bootstrap makefile +#- + +AC_MSG_CHECKING([GNUstep make bootstrap location]) +AC_ARG_WITH(makefile-dir,[ +--with-bootstrap-path=PATH +The location to install the bootstrap makefile gnustep.make], +GNUSTEP_BOOTSTRAP_PATH=$withval,) +if test "$GNUSTEP_BOOTSTRAP_PATH" = "" -o "$GNUSTEP_BOOTSTRAP_PATH" = "no"; then +GNUSTEP_BOOTSTRAP_PATH="/usr/local/include"; +fi +AC_MSG_RESULT($GNUSTEP_BOOTSTRAP_PATH) +AC_SUBST(GNUSTEP_BOOTSTRAP_PATH) + +#- +# location of pkg-config path +#- + +AC_MSG_CHECKING([pkg-config path location]) +AC_ARG_WITH(makefile-dir,[ +--with-pkgconfig-path=PATH +The location to install the file gnustep.pc], +GNUSTEP_PKGCONFIG_PATH=$withval,) +if test "$GNUSTEP_PKGCONFIG_PATH" = "" -o "$GNUSTEP_PKGCONFIG_PATH" = "no"; then +GNUSTEP_PKGCONFIG_PATH="/usr/local/lib/pkgconfig"; +fi +AC_MSG_RESULT($GNUSTEP_PKGCONFIG_PATH) +AC_SUBST(GNUSTEP_PKGCONFIG_PATH) + +#- # Now read/import the existing configuration file, if any #- @@ -1060,7 +1090,7 @@ # AC_CONFIG_FILES([config-noarch.make config.make openapp opentool executable.template GNUmakefile GNUstep.conf GNUstep.sh GNUstep.csh fixpath.sh -gnustep-make.spec]) +gnustep-make.spec gnustep.pc]) AC_CONFIG_COMMANDS([default], [[chmod a+x openapp opentool fixpath.sh executable.template]], [[]]) Index: gnustep.pc.in === --- gnustep.pc.in (revision 0) +++ gnustep.pc.in (revision 0) @@ -0,0 +1,9 @@ +system_root= @GNUSTEP_SYSTEM_ROOT@ +user_root= ~/@GNUSTEP_USER_DIR@ +network_root= @GNUSTEP_NETWORK_ROOT@ +local_root= @GNUSTEP_LOCAL_ROOT@ +path_list= ~/@GNUSTEP_USER_DIR@:@GNUSTEP_LOCAL_ROOT@:@GNUSTEP_SYSTEM_ROOT@:@GNUSTEP_NETWORK_ROOT@ +makefiles= @GNUSTEP_SYSTEM_ROOT@/Library/Makefiles +Name: GNUstep +Description: A Free software implementation of the OpenStep Specification. +Version: @GNUSTEP_MAKE_VERSION@ Index: GNUmakefile.in === --- GNUmakefile.in (revision 24410) +++ GNUmakefile.in (working copy) @@ -45,6 +45,8 @@ GNUSTEP_SYSTEM_ROOT = $(DESTDIR)@GNUSTEP_SYSTEM_ROOT@ GNUSTEP_LOCAL_ROOT = $(DESTDIR)@GNUSTEP_LOCAL_ROOT@ GNUSTEP_NETWORK_ROOT = $(DESTDIR)@GNUSTEP_NETWORK_ROOT@ +GNUSTEP_BOOTSTRAP_PATH = $(DESTDIR)@GNUSTEP_BOOTSTRAP_PATH@ +GNUSTEP_PKGCONFIG_PATH = $(DESTDIR)@GNUSTEP_PKGCONFIG_PATH@ makedir = $(DESTDIR)@GNUSTEP_MAKEFILES@ srcdir = @srcdir@ VPATH = @srcdir@ @@ -141,7 +143,8 @@ $(makedir)/Master \ $(makedir)/Instance \ $(makedir)/Instance/Shared \ - $(makedir)/Instance/Documentation) + $(makedir)/Instance/Documentation \ + $(GNUSTEP_BOOTSTRAP_PATH)) $(EC)(echo "Installing GNUstep configuration file in $(GNUSTEP_CONFIG_FILE)"; \ $(srcdir)/mkinstalldirs "$(GNUSTEP_CONFIG_FILE_DIR)"; \ $(INSTALL_DATA) GNUstep.conf "$(GNUSTEP_CONFIG_FILE)") @@ -159,7 +162,7 @@ $(INSTALL_PROGRAM) -m 755 GNUstep.csh $(makedir); \ $(INSTALL_PROGRAM) -m 755 fixpath.sh $(makedir); \ $(INSTALL_PROGRAM) -m 755 openapp $(tooldir); \ - $(INSTALL_PROGRAM) -m 755 opentool $(tooldir)) + $(INSTALL_PROGRAM) -m 755 opentool $(tooldir)) $(EC)(echo "Installing makefiles"; \ for f in $(MAKE_FILES); do \ $(INSTALL_DATA) $(srcdir)/$$f $(makedir); \ @@ -180,7 +183,9 @@ done; \ $(INSTALL_DATA) executable.template $(makedir); \ $(INSTALL_DATA) config-noarch.make $(makedir); \ - $(INSTALL_DATA) config.make $(makedir)/$(GNUSTEP_TARGET_LDIR)) + $(INSTALL_DATA) config.make $(makedir)/$(GNUSTEP_TARGET_LDIR); \ + $(INSTALL_DATA) gnustep.make $(GNUSTEP_BOOTSTRAP_PATH); \ + $(INSTALL_DATA) gnustep.pc $(GNUSTEP_PKGCONFIG_PATH)) $(EC)($(srcdir)/m
RE: gnustep-make experiment
> attached is just sort of an experiment in getting rid of GNUstep.sh to > compile stuff If you use trunk, you don't need GNUstep.sh to compile stuff ... ;-) 1. add /usr/GNUstep/System/Library/Libraries and /usr/GNUstep/Local/Library/Libraries to /etc/ld.so.conf and run ldconfig 2. add /usr/GNUstep/System/Tools and /usr/GNUstep/Local/Tools to your PATH 3. set GNUSTEP_MAKEFILES=/usr/GNUstep/System/Library/Makefiles and you're ready to go. Once we use FHS, then libraries and tools will automatically be in your PATHs, so you would need to: * do nothing to use GNUstep * set the single variable GNUSTEP_MAKEFILES to compile GNUstep stuff and you can also easily switch between different installations by using configuration files. Thanks PS: investigations are still welcome though ;-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: gnustep-make experiment
On 2007-01-24 04:17:17 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: attached is just sort of an experiment in getting rid of GNUstep.sh to compile stuff If you use trunk, you don't need GNUstep.sh to compile stuff ... ;-) 1. add /usr/GNUstep/System/Library/Libraries and /usr/GNUstep/Local/Library/Libraries to /etc/ld.so.conf and run ldconfig 2. add /usr/GNUstep/System/Tools and /usr/GNUstep/Local/Tools to your PATH 3. set GNUSTEP_MAKEFILES=/usr/GNUstep/System/Library/Makefiles and you're ready to go. Once we use FHS, then libraries and tools will automatically be in your PATHs, so you would need to: * do nothing to use GNUstep * set the single variable GNUSTEP_MAKEFILES to compile GNUstep stuff and you can also easily switch between different installations by using configuration files. Thanks PS: investigations are still welcome though ;-) In that case I still think that pkg-config support would be worthwhile, as GNUstep is then totally isolated theres no way for an external shell script/autoconf to know anything about GNUstep really since GNUstep.conf put anywhere and they can no longer rely on environment variables, I've come across at least 2 instances of needing the environment variables GDL2 needs to attempt to link to the Gorm libraries to see if it should enable building of the GDL2 Gorm palette and in porting aquaterm, and the gnuplot adaptor for aquaterm, it needs to also look for a lib in the GNUstep heirarchy to enable that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 24 Jan 2007, at 14:10, Matt Rice wrote: On 2007-01-24 04:17:17 -0800 Nicola Pero <[EMAIL PROTECTED] innovation.com> wrote: attached is just sort of an experiment in getting rid of GNUstep.sh to compile stuff If you use trunk, you don't need GNUstep.sh to compile stuff ... ;-) 1. add /usr/GNUstep/System/Library/Libraries and /usr/GNUstep/ Local/Library/Libraries to /etc/ld.so.conf and run ldconfig 2. add /usr/GNUstep/System/Tools and /usr/GNUstep/Local/Tools to your PATH 3. set GNUSTEP_MAKEFILES=/usr/GNUstep/System/Library/Makefiles and you're ready to go. Once we use FHS, then libraries and tools will automatically be in your PATHs, so you would need to: * do nothing to use GNUstep * set the single variable GNUSTEP_MAKEFILES to compile GNUstep stuff and you can also easily switch between different installations by using configuration files. Thanks PS: investigations are still welcome though ;-) In that case I still think that pkg-config support would be worthwhile, as GNUstep is then totally isolated theres no way for an external shell script/autoconf to know anything about GNUstep really since GNUstep.conf put anywhere and they can no longer rely on environment variables, I've come across at least 2 instances of needing the environment variables GDL2 needs to attempt to link to the Gorm libraries to see if it should enable building of the GDL2 Gorm palette and in porting aquaterm, and the gnuplot adaptor for aquaterm, it needs to also look for a lib in the GNUstep heirarchy to enable that. I find this discussion confusing ... I had assumed that the point of not using GNUstep.sh was for things which did not want to know anything about GNUstep. That seems reasonable enough... after all, why should you want to know about where resources are if all you want to do is run a program? However, when you talk about GDL2 wanting to know where the Gorm libraries are, you obviously DO want to know about GNUstep resource locations, and you can easily get the information by running GNUstep.sh ... so why do you want to not run it? What is the benefit of *not* running GNUstep.sh for scripts which want to know about GNUstep? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-01-24 06:22:54 -0800 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: On 24 Jan 2007, at 14:10, Matt Rice wrote: On 2007-01-24 04:17:17 -0800 Nicola Pero <[EMAIL PROTECTED] innovation.com> wrote: attached is just sort of an experiment in getting rid of GNUstep.sh to compile stuff If you use trunk, you don't need GNUstep.sh to compile stuff ... ;-) 1. add /usr/GNUstep/System/Library/Libraries and /usr/GNUstep/ Local/Library/Libraries to /etc/ld.so.conf and run ldconfig 2. add /usr/GNUstep/System/Tools and /usr/GNUstep/Local/Tools to your PATH 3. set GNUSTEP_MAKEFILES=/usr/GNUstep/System/Library/Makefiles and you're ready to go. Once we use FHS, then libraries and tools will automatically be in your PATHs, so you would need to: * do nothing to use GNUstep * set the single variable GNUSTEP_MAKEFILES to compile GNUstep stuff and you can also easily switch between different installations by using configuration files. Thanks PS: investigations are still welcome though ;-) In that case I still think that pkg-config support would be worthwhile, as GNUstep is then totally isolated theres no way for an external shell script/autoconf to know anything about GNUstep really since GNUstep.conf put anywhere and they can no longer rely on environment variables, I've come across at least 2 instances of needing the environment variables GDL2 needs to attempt to link to the Gorm libraries to see if it should enable building of the GDL2 Gorm palette and in porting aquaterm, and the gnuplot adaptor for aquaterm, it needs to also look for a lib in the GNUstep heirarchy to enable that. I find this discussion confusing ... I had assumed that the point of not using GNUstep.sh was for things which did not want to know anything about GNUstep. That seems reasonable enough... after all, why should you want to know about where resources are if all you want to do is run a program? However, when you talk about GDL2 wanting to know where the Gorm libraries are, you obviously DO want to know about GNUstep resource locations, and you can easily get the information by running GNUstep.sh ... so why do you want to not run it? What is the benefit of *not* running GNUstep.sh for scripts which want to know about GNUstep? well, my incentive was to trim a step off the entire process, sourcing GNUstep.sh or setting GNUSTEP_MAKEFILES before compiling. so that if the PATH was set up and LD_LIBRARY_PATH or alternately add a bunch of configure flags to install stuff into /usr/bin and /usr/lib then just type make like they normally do when compiling software and it would just compile. not hiding or not wanting to know about GNUstep, but by putting the information needed accessible via something in the path (in this case pkg-config) so the user doesn't need to do anything to make this information accessible to make. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Richard Frith-Macdonald schrieb: > > On 24 Jan 2007, at 14:10, Matt Rice wrote: > >> On 2007-01-24 04:17:17 -0800 Nicola Pero <[EMAIL PROTECTED] >> innovation.com> wrote: >> attached is just sort of an experiment in getting rid of GNUstep.sh to compile stuff >>> >>> If you use trunk, you don't need GNUstep.sh to compile stuff ... ;-) >>> 1. add /usr/GNUstep/System/Library/Libraries and /usr/GNUstep/ >>> Local/Library/Libraries to /etc/ld.so.conf and run ldconfig >>> 2. add /usr/GNUstep/System/Tools and /usr/GNUstep/Local/Tools to >>> your PATH >>> 3. set GNUSTEP_MAKEFILES=/usr/GNUstep/System/Library/Makefiles >>> and you're ready to go. Once we use FHS, then libraries and tools >>> will automatically be in your PATHs, so you would need to: >>> * do nothing to use GNUstep >>> * set the single variable GNUSTEP_MAKEFILES to compile GNUstep stuff >>> and you can also easily switch between different installations by >>> using configuration files. >>> Thanks >>> PS: investigations are still welcome though ;-) >> >> >> In that case I still think that pkg-config support would be >> worthwhile, as GNUstep is then totally isolated >> theres no way for an external shell script/autoconf to know anything >> about GNUstep really >> since GNUstep.conf put anywhere and they can no longer rely on >> environment variables, >> >> I've come across at least 2 instances of needing the environment >> variables >> GDL2 needs to attempt to link to the Gorm libraries to see if it >> should enable building of the GDL2 Gorm palette >> and in porting aquaterm, and the gnuplot adaptor for aquaterm, it >> needs to also look for a lib in the GNUstep heirarchy >> to enable that. > > > I find this discussion confusing ... > > I had assumed that the point of not using GNUstep.sh was for things > which did not want to know anything about GNUstep. That seems > reasonable enough... after all, why should you want to know about where > resources are if all you want to do is run a program? > > However, when you talk about GDL2 wanting to know where the Gorm > libraries are, you obviously DO want to know about GNUstep resource > locations, and you can easily get the information by running GNUstep.sh > ... so why do you want to not run it? What is the benefit of *not* > running GNUstep.sh for scripts which want to know about GNUstep? It's not stricty GDL2 in this case but ./configure of GDL2 which want to tweak make file fragments dependent on what's available. So maybe we need some tool in the path to query the values. Something like gnustep-config akin to apxs and xml2-config. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: gnustep-make experiment
> GDL2 needs to attempt to link to the Gorm libraries to see if it > should enable building of the GDL2 Gorm palette > and in porting aquaterm, and the gnuplot adaptor for aquaterm, it > needs to also look for a lib in the GNUstep heirarchy > to enable that. There are two solutions to that: 1. source GNUstep.sh inside ./configure. ./configure is a shell script, so I don't see what's the problem with that. You first check that GNUSTEP_MAKEFILES is set, if not you exit with an error. If it's set, you source $GNUSTEP_MAKEFILES/GNUstep.sh and then you have all your GNUstep variables available! ;-) 2. do it inside your GNUmakefile directly ... use a Makefile ifeq(,) with a wildcard expansion to check for the existence of the library. If it exists, you include palette.make, if not, you don't. ;-) I suppose we could have a prewritten, ready to use, autoconf check for libraries. Or we could have a gnustep-make macros that expands to 'yes' or 'no' depending if a certain specified library (or tool) is installed on the system or not (I can write that for you)! ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> It's not stricty GDL2 in this case but ./configure of GDL2 which want to > tweak make file fragments dependent on what's available. So maybe we > need some tool in the path to query the values. Something like > gnustep-config akin to apxs and xml2-config. Such a tool/shell script would be good. Presumably it's also what Matt was really looking for ? I think it would be a good addition. The tool would check if GNUSTEP_MAKEFILES is set, if it is, it would then source GNUstep.sh and iterate over whatever dirs you want to iterate over to check if libraries are there ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: gnustep-make experiment
> 1. source GNUstep.sh inside ./configure. > 2. do it inside your GNUmakefile directly ... Thinking about it, I'm not really with any of these two solutions ... when we change radically the location of libraries, both might be broken by the change. ;-) Probably the best solution is to add a gnustep-make macro and/or a shell script that will tell you if a GNUstep library/tool is installed or not. They would have a 'public API' to tell you that, API which doesn't depend on the internal location of libraries and things ... so we can freely change them without affecting users. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-01-24 11:10:24 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: It's not stricty GDL2 in this case but ./configure of GDL2 which want to tweak make file fragments dependent on what's available. So maybe we need some tool in the path to query the values. Something like gnustep-config akin to apxs and xml2-config. Such a tool/shell script would be good. Presumably it's also what Matt was really looking for ? I think it would be a good addition. The tool would check if GNUSTEP_MAKEFILES is set, if it is, it would then source GNUstep.sh and iterate over whatever dirs you want to iterate over to check if libraries are there ? sort of what i was looking for, and this is what the gnustep.pc basically does (I didn't add the -I/-L/-l stuff which is what pkg-config is normally for though) just if its going to be supported to compile with only $GNUSTEP_MAKEFILES set stuff _will_ need access to the older variables that were previously available but it doesn't depend upon GNUSTEP_MAKEFILES or any ivars, being generated when you configure make. so if you want multiple gnustep.pc's lying around you'll need to fiddle with PKG_CONFIG_PATH instead of setting GNUSTEP_MAKEFILES e.g. $ pkg-config gnustep --variable=system_root /usr/GNUstep/System export PKG_CONFIG_PATH=/tmp:$PKG_CONFIG_PATH pkg-config gnustep --variable=system_root /example/System so the idea was we replace all the environment variables with that we install gnustep.pc by default into somewhere pkg-config will find it, then people who want non-standard stuff fiddle with it can set PKG_CONFIG_PATH but it should just work by default ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Jan 24, 2007, at 15:10, Matt Rice wrote: I've come across at least 2 instances of needing the environment variables GDL2 needs to attempt to link to the Gorm libraries to see if it should enable building of the GDL2 Gorm palette and in porting aquaterm, and the gnuplot adaptor for aquaterm, it needs to also look for a lib in the GNUstep heirarchy to enable that. Maybe I'm entirely off-track, but I suppose whats being talked about is resource or bundle lookup :-) Which of course should also work in FHS settings. (ie Gorm should ideally work in plain FHS, no?) In OGo/SOPE we explicitly support both variants. If the GNUstep environment is sourced, we look in "GNUstep style pathes". If such a lookup fails (or if no environment is sourced), we continue searching in FHS locations (currently we hardcode /usr/local/ and /usr/, which obviously should be configurable using configure ...). Eg, a bundle "ABC.bundle" with resources a.gif/b.gif in GNUstep setup: (pathprefixlist) + Library /Bundles/ABC.bundle ABC /Resources /a.gif /b.gif In FHS: (pathprefixlist: /usr, /usr/local): /lib /abc-1.2.so /share /abc-1.2 /a.gif /b.gif Something like that ;-) Frameworks/bundles need to be "debundled" for FHS. Of course this can be done transparently in the NSBundle class. (though a separate class has the advantage that you can do FHS in combination with Cocoa). Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-01-24 14:24:59 -0800 Helge Hess <[EMAIL PROTECTED]>
wrote:
On Jan 24, 2007, at 15:10, Matt Rice wrote:
I've come across at least 2 instances of needing the environment
variables
GDL2 needs to attempt to link to the Gorm libraries to see if it
should
enable building of the GDL2 Gorm palette
and in porting aquaterm, and the gnuplot adaptor for aquaterm, it
needs to
also look for a lib in the GNUstep heirarchy
to enable that.
Maybe I'm entirely off-track, but I suppose whats being talked about
is
resource or bundle lookup :-) Which of course should also work in
FHS
settings. (ie Gorm should ideally work in plain FHS, no?)
In OGo/SOPE we explicitly support both variants. If the GNUstep
environment
is sourced, we look in "GNUstep style pathes". If such a lookup
fails (or if
no environment is sourced), we continue searching in FHS locations
(currently we hardcode /usr/local/ and /usr/, which obviously should
be
configurable using configure ...).
Eg, a bundle "ABC.bundle" with resources a.gif/b.gif in GNUstep setup:
(pathprefixlist) + Library
/Bundles/ABC.bundle
ABC
/Resources
/a.gif
/b.gif
In FHS:
(pathprefixlist: /usr, /usr/local):
/lib
/abc-1.2.so
/share
/abc-1.2
/a.gif
/b.gif
Something like that ;-) Frameworks/bundles need to be "debundled" for
FHS.
Of course this can be done transparently in the NSBundle class.
(though a
separate class has the advantage that you can do FHS in combination
with
Cocoa).
Well, sort of, though admittedly i'd attempted to avoid file system
discussions :D
I was just trying to get rid of GNUstep.sh or any setup required
before running make
and left it at that.
but admittedly, the patch i posted would work best if things installed
by default into
/usr/{,local}/bin for Tools/ and /usr/{,local}/lib (configurable of
course)
in that case you could just make; make install; run stuff
and if you really want something like a self contained installation,
or installation into somewhere like ~,
or multiple installations, you can but may have to to fiddle with
environment variables, configure flags and stuff.
the other part of this thread relates to just setting
GNUSTEP_MAKEFILES instead of sourcing GNUstep.sh
where i had some concerns about being able to run AC_CHECK_LIB from
configure files.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> so the idea was we replace all the environment variables with that we > install gnustep.pc by default into somewhere pkg-config will find it, then > people who want non-standard stuff fiddle with it can set PKG_CONFIG_PATH > but it should just work by default I'm a bit confused ... it looks like you are trying to solve some issues that have already been solved! ;-) I think I need to write more documentation on the new gnustep-make code, as it's considerably more advanced than what we had before, but nobody seems to know much about it. ;-) The current implementation works as follows: * you configure your GNUstep paths by editing /etc/GNUstep.conf. You can change them at any time by just editing the file * if you have multiple GNUstep installations, you should keep multiple conf files; you can specify that you want another config file to be used by setting GNUSTEP_CONFIG_FILE (or GNUSTEP_USER_CONFIG_FILE) * everything (both gnustep-make and gnustep-base) is getting the paths from the config files * everything executes once libraries are in the library paths and tools are in path * to compile, you only need to set GNUSTEP_MAKEFILES. GNUstep.sh is still required/handy for more complex scenarios, for example when you have fat binaries. You can still use it, keeping in mind it gets the paths from the config file now! We want to keep it for backwards compatibility anyway. Unfortunately, because all GNUmakefiles in the world start with the line include $(GNUSTEP_MAKEFILES)/common.make and we want to maintain backwards-compatibility as much as possible (ie, we don't want everyone in the world to have to modify their GNUmakefiles, or worse, to have two copies of each of them for different gnustep-make versions!), GNUSTEP_MAKEFILES has to be defined to compile. But we managed to make that variable the only requirement! :-) Our plan is that Linux FHS support will also be somewhat backward compatible. GNUstep.conf will be extended with more variables, and gnustep-make and gnustep-base will automatically get them all from there and use them. Once Linux FHS support is in place, stuff like GNUSTEP_SYSTEM_ROOT no longer has a useful meaning if you're using Linux FHS. You should not use it. All access to the filesystem should go through the OpenStep Foundation API (for ObjC code) or via gnustep-make public APIs/variables (eg, GNUSTEP_LIBRARIES); they will automatically take care of the local filesystem setup. I guess you have a point that the gnustep-make ones are not entirely defined yet; they would be clearly defined once we implement Linux FHS. I understand we might be missing some gnustep-make public APIs/variables/macros to locate things. In that case, we can add them. I don't agree with being able to get GNUSTEP_SYSTEM_ROOT though. That variable will no longer have a well-defined/useful meaning in the new world. It will be obsolete! ;-) Old software that is installed in the old way (in a GNUstep filesystem) and sources the old GNUstep.sh will still have that variable available and will keep working; but if you want the old software to work in a new context (eg, Linux FHS), you have to move away from that. Once you can freely configure gnustep-make to relocate system/local tools/bundles/apps/libs anywhere on the fileystem, then what does GNUSTEP_SYSTEM_ROOT mean / why would it be useful ? ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-01-24 16:14:47 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: so the idea was we replace all the environment variables with that we install gnustep.pc by default into somewhere pkg-config will find it, then people who want non-standard stuff fiddle with it can set PKG_CONFIG_PATH but it should just work by default Unfortunately, because all GNUmakefiles in the world start with the line include $(GNUSTEP_MAKEFILES)/common.make and we want to maintain backwards-compatibility as much as possible (ie, we don't want everyone in the world to have to modify their GNUmakefiles, or worse, to have two copies of each of them for different gnustep-make versions!), GNUSTEP_MAKEFILES has to be defined to compile. But we managed to make that variable the only requirement! :-) I don't really find this a very compelling argument, by just not removing GNUstep.sh for some period of time it is easy to be backwards compatible by sourcing it and its very easy to switch the makefiles with sed. Anyhow i'll read this more thoroughly tomorrow, but my main problem with GNUstep.sh isn't actually technical at all, its the very first thing potential developers are going to see, so will be the first impression, and imho gives the impression of being strange because it is uncommon for a build system to depend on environment variables to function. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Jan 25, 2007, at 01:35, Matt Rice wrote: Anyhow i'll read this more thoroughly tomorrow, but my main problem with GNUstep.sh isn't actually technical at all, its the very first thing potential developers are going to see, so will be the first impression, and imho gives the impression of being strange because it is uncommon for a build system to depend on environment variables to function. Yes. The thing we do (... ;-) is to have a very small (hand written) 'configure' script which locates gnustep-make and writes a small 'config.make' files containing the relevant GS variables. Then all makefiles include that config.make file like this: -include config.make include $(GNUSTEP_MAKEFILES)/common.make If configure was run, it works w/o an environment. If it wasn't, it still works when GNUstep.sh is sourced. Which is quite nice IMHO ;-) [actually SOPE even embeds gstep-make and builds that as part of the 'configure' process if it can't find an installed gstep-make. Which makes the package completely self-contained, IMHO rather nice and similiar to autoconf] Possibly a 'make dist' should automatically generate such a configure script for a given project? Don't know. Probably there is a smart solution to the issue ;-) BTW: personally I'm not quite sure whether I understand that /etc/ GNUstep.conf thing :-) Is it necessary or optional? Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> but my main problem with GNUstep.sh isn't actually technical at all, > its the very first thing potential developers are going to see, so > will be the first impression, > and imho gives the impression of being strange because it is uncommon > for a build system to depend on environment variables to function. I looked at your patch and I understand what you're trying to do ... it's good stuff and it's good to have this discussion, but let me first insist in claryfying something ... ;-) The build system does not depend on GNUstep.sh at all. We spent years working on removing that dependency, and it's no longer there! :-) It's not advertised much yet, but it will be clearly advertised in the release note of the forthcoming gnustep-make release. GNUstep.sh is obsolete in the default setup. You only need to set GNUSTEP_MAKEFILES and everything will work (assuming you have your tools in your path, and libs in your linker paths). This is all already implemented on trunk! :-) So forget about GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT, GNUSTEP_XX_YY. You don't need to set those variables to compile or run stuff. In fact, they are deprecated as shell variables. You shouldn't be using them. You may use them as make variables, keeping in mind they will have limited meaning/usefulness once we have support for non-GNUstep FHSes! ;-) You only need to set GNUSTEP_MAKEFILES. This is already on trunk! Once that's clear, we can discuss the patch ;-) I see two good ideas in the patch ... 1. I guess you are suggesting to put a makefile somewhere in the make search path and change all makefiles to include it so that you can compile without even setting GNUSTEP_MAKEFILES. I like the idea of not having to set any variable to compile, but I also see a couple of obvious cons -- it would be more difficult to switch between different gnustep-make installations (at the moment, you can easily switch by just changing GNUSTEP_MAKEFILES!), and we need to ask everyone on the planet to change their GNUmakefiles, and in a way that will likely make them stop working unless you use a recent gnustep-make - they won't like it. So we need to think a lot and make sure we make the right choice before we do it. Eg, if you have to modify your make include path to make this work, then you may as well ask people to set GNUSTEP_MAKEFILES. ;-) 2. you're suggesting to have a script that can help ./configure scripts examine the filesystem for GNUstep softtware. That sounds good, but having the script return GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT etc seems the wrong thing to do -- these are the variables that make it difficult to switch to Linux FHS and we are trying to move away from them! In fact, we have already moved away from them. As shell variables, they are obsolete and should not be used! Finally, your gnustep.pc seems a duplicate of /etc/GNUstep.conf! ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> Yes. The thing we do (... ;-) is to have a very small (hand written) > 'configure' script which locates gnustep-make and writes a small > 'config.make' files containing the relevant GS variables. Then all > makefiles include that config.make file like this: > > -include config.make > include $(GNUSTEP_MAKEFILES)/common.make > > If configure was run, it works w/o an environment. If it wasn't, it > still works when GNUstep.sh is sourced. Which is quite nice IMHO ;-) Sounds like an interesting solution. Then people would be able to do ./configure make make install and all would work with no variables defined. I think there is a smarter solution though ... if the approach is giving small fragments/snippets of code that people include in their project, then why not write directly a makefile fragment ? So we could have a small makefile fragment, let's call it find-gnustep.make, that searches for gnustep-make on disk and sets GNUSTEP_MAKEFILES to the best match. I'll write that makefile fragment, and it will be maintained inside gnustep-make. If you put/copy that makefile fragment in your project, then you could modify your GNUmakefiles to do -- include ./find-gnustep.make include $(GNUSTEP_MAKEFILES)/common.make ... then you can type 'make' and it would always work, even if GNUSTEP_MAKEFILES is not initially defined ;-) Hmm. > BTW: personally I'm not quite sure whether I understand that /etc/ > GNUstep.conf thing :-) Is it necessary or optional? It is necessary. The reason is that it allows gnustep-make and gnustep-base to have a common understanding of where the various directories are. The GNUstep.conf file describes the GNUstep filesystem and both gnustep-make and gnustep-base read it to know where to find things. Previously this shared understanding was based on shell variables set by GNUstep.sh; now we prefer a configuration file. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-01-24 22:05:26 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: but my main problem with GNUstep.sh isn't actually technical at all, its the very first thing potential developers are going to see, so will be the first impression, and imho gives the impression of being strange because it is uncommon for a build system to depend on environment variables to function. I looked at your patch and I understand what you're trying to do ... it's good stuff and it's good to have this discussion, but let me first insist in claryfying something ... ;-) The build system does not depend on GNUstep.sh at all. We spent years working on removing that dependency, and it's no longer there! :-) It's not advertised much yet, but it will be clearly advertised in the release note of the forthcoming gnustep-make release. GNUstep.sh is obsolete in the default setup. You only need to set GNUSTEP_MAKEFILES and everything will work (assuming you have your tools in your path, and libs in your linker paths). This is all already implemented on trunk! :-) Yes, but you still need to do something before running make, which is what this patch is mostly about. You only need to set GNUSTEP_MAKEFILES. This is already on trunk! Once that's clear, we can discuss the patch ;-) I see two good ideas in the patch ... 1. I guess you are suggesting to put a makefile somewhere in the make search path and change all makefiles to include it so that you can compile without even setting GNUSTEP_MAKEFILES. I like the idea of not having to set any variable to compile, but I also see a couple of obvious cons -- it would be more difficult to switch between different gnustep-make installations (at the moment, you can easily switch by just changing GNUSTEP_MAKEFILES!), Not really, the patch allows you to switch installations by setting PKG_CONFIG_PATH and specifying --with-pkgconfig-path to configure to tell it where to put gnustep.pc. The difference being instead of always having to configure it, configuration is made to be something only people who need that behaviour have to do. and we need to ask everyone on the planet to change their GNUmakefiles, and in a way that will likely make them stop working unless you use a recent gnustep-make - they won't like it. So we need to think a lot and make sure we make the right choice before we do it. Eg, if you have to modify your make include path to make this work, then you may as well ask people to set GNUSTEP_MAKEFILES. ;-) Well i still don't find this argument very compelling, for some undeterminable amount of time we need to source GNUstep.sh or set GNUSTEP_MAKEFILES to compile old software, of course it isn't forwards compatible so new software wouldn't compile on older installations 2. you're suggesting to have a script that can help ./configure scripts examine the filesystem for GNUstep softtware. That sounds good, but having the script return GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT etc seems the wrong thing to do -- these are the variables that make it difficult to switch to Linux FHS and we are trying to move away from them! In fact, we have already moved away from them. As shell variables, they are obsolete and should not be used! Yeah, the stuff stored inside gnustep.pc is by no means required to contain SYSTEM_ROOT/LOCAL_ROOT etc If these things change (as indeed it seems they have) so should the gnustep.pc, it was mainly intended as a demonstration to show how i was imagining this working anyhow yeah if e,g, $GNUSTEP_SYSTEM_ROOT/Library/Libraries is no longer reliable this will need to change Finally, your gnustep.pc seems a duplicate of /etc/GNUstep.conf! ;-) yeah it is, its a duplicate of a home-brew method, to use a relatively standard method though GNUstep.conf is available only to GNUstep, only GNUstep knows where it exists because its path is configurable. I assume you can set GNUSTEP_CONFIG_FILE (or something) to tell GNUstep where to find it, but this doesn't help in finding the deafult which is used if GNUSTEP_CONFIG_FILE (or something) doesn't exist. If the information in it is only attainable by GNUstep and no longer available in environment variables (or reliable if we can no longer $GNUSTEP_XX_ROOT/Library/Libraries for AC_CHECK_LIB) then i wouldn't consider it a complete solution anyhow If i understood correctly, i thought GNUstep.conf was initially always hard coded to /etc/GNUstep.conf and was intended to make stuff like GNUstep variables available to shell scripts and what not, then /path/to/GNUstep.conf became configurable at some point and it lost this purpose, and the purpose then was limited to configuration of GNUstep variables at runtime -- replacing the environment variables... but maybe I was wrong with that assumption ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/
Re: gnustep-make experiment
Thanks for your suggestions You seem to think that the current solution lacks: 1. a way to compile without setting GNUSTEP_MAKEFILES 2. a way to get the GNUstep bundle/libs/tools search paths for use in configure scripts etc. I agree we can do better to address those. Solutions that came to mind as natural ones would be to -- 1. have a (trivial) makefile fragment that locates gnustep-make and you can include in your project to make it bootstrap without having to rely on GNUSTEP_MAKEFILES being set (I suppose we should also consider just putting it into your make include path). 2. have a (trivial) shell script that can output the list of GNUstep bundle/libs/tools search paths. We install this as a system tool, so under Linux FHS it will automatically be in your PATH and you can just invoke it whenever you need (similar to the all the config files of other software that you mention). Maybe for 2. we could take the standard OpenStep search methods (for bundles etc.) and have shell script equivalents for them. That would seem like a reasonable way of designing our shell 'API' to get the filesystem locations, in a way that would work with Linux FHS as well. I was now feeling like jumping in and implementing all that, but it will likely be a few iterations and discussions before we get something good and stable, and if we're trying to make a release in the next few weeks, it's not the right time to add new stuff. I'd rather spend some time documenting what we already have before we try working on the next steps (nobody seems to have a clue about all the new stuff in gnustep-make). So can we come back to this in a few weeks ? ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-01-25 06:48:50 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: Thanks for your suggestions You seem to think that the current solution lacks: 1. a way to compile without setting GNUSTEP_MAKEFILES 2. a way to get the GNUstep bundle/libs/tools search paths for use in configure scripts etc. I agree we can do better to address those. Solutions that came to mind as natural ones would be to -- 1. have a (trivial) makefile fragment that locates gnustep-make and you can include in your project to make it bootstrap without having to rely on GNUSTEP_MAKEFILES being set (I suppose we should also consider just putting it into your make include path). true, this could be something similar to what i put in gnustep.make GNUSTEP_MAKEFILES ?= $(shell pkg-config --variable makefiles gnustep) include $(GNUSTEP_MAKEFILES)/common.make this should actually work with older installations of gnustep. the whole make bootstrap path thing that is admittedly just a hack but "include gnustep.make" was easier to remember than adding the above, shell snippet if adding some new line to makefiles is acceptable i'd be completely fine with that. maybe thats not what you meant though, its another idea anyhow... I was now feeling like jumping in and implementing all that, but it will likely be a few iterations and discussions before we get something good and stable, and if we're trying to make a release in the next few weeks, it's not the right time to add new stuff. I most definately agree on this I'd rather spend some time documenting what we already have before we try working on the next steps (nobody seems to have a clue about all the new stuff in gnustep-make). So can we come back to this in a few weeks ? ;-) Sure, thanks for hearing me out :D ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Nicola Pero schrieb: > I'd rather spend some time documenting what we already have before we try > working on the next > steps (nobody seems to have a clue about all the new stuff in gnustep-make). > So can we come > back to this in a few weeks ? ;-) Personally I'd prefer to suspend the release until we have an environment that has a chance of remaining stable. It seems that we already require -make users to adapt thier projects for this release (I remeber you cleaning up many projects in SVN) and it seems they may need to adapt again for the subsequent release. But as I'm not effected by it in a big way, I won't argue hard... Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Jan 26, 2007, at 24:04, David Ayers wrote: Personally I'd prefer to suspend the release until we have an environment that has a chance of remaining stable. It seems that we already require -make users to adapt thier projects for this release (I remeber you cleaning up many projects in SVN) and it seems they may need to adapt again for the subsequent release. Thats a good point. The last gstep-make release already gave us a major headache. Well, if the next one is explicitly marked as unstable it would be probably OK ;-) Thanks, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> Personally I'd prefer to suspend the release until we have an > environment that has a chance of remaining stable. It seems that we > already require -make users to adapt thier projects for this release (I > remeber you cleaning up many projects in SVN) and it seems they may need > to adapt again for the subsequent release. That's a good point to discuss, on the other hand sooner or later we need to ship the changes so they start getting widespread. I believe we have enough changes to ship a new release! The main changes in the new gnustep-make are: * libraries have now the same name no matter if you compile them with debug, porofile, static or what. _d, _p, _dp etc. are gone. * applications have now the same name no matter if you compile them with debug or what. Gorm.debug is gone. Now it's only Gorm.app. * all object files are now put in ./obj. shared_obj, shared_debug_obj, etc. are gone. Those may require projects that contain custom makefile code to be updated! The other main change is that using GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT, etc. in makefiles is now discouraged (because it won't work with Linux FHS). This has no effect though, for now you can happily use them. Also, the new release will work without sourcing GNUstep.sh, in which case you can't really use the GNUSTEP_SYSTEM_ROOT, etc. shell variables any more. They are effectively obsolete. Finally, the new gnustep-make supports GNUSTEP_INSTALLATION_DOMAIN and it's strongly recommended that this is used instead of GNUSTEP_INSTALLATION_DIR (GNUSTEP_INSTALLATION_DIR won't work with Linux FHS). You don't need to change it now, but over time we hope everyone will switch to GNUSTEP_INSTALLATION_DOMAIN I suppose maybe you (and Helge) are right, we could wait a few more months and finish off all changes, then we ship a gnustep-make 2.0.0 so there is a single major upgrade. ;-) It actually makes quite some sense, I'm tempted to do that now. :-) Comments welcome Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Matt Rice wrote: On 2007-01-24 22:05:26 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: but my main problem with GNUstep.sh isn't actually technical at all, its the very first thing potential developers are going to see, so will be the first impression, and imho gives the impression of being strange because it is uncommon for a build system to depend on environment variables to function. I looked at your patch and I understand what you're trying to do ... it's good stuff and it's good to have this discussion, but let me first insist in claryfying something ... ;-) The build system does not depend on GNUstep.sh at all. We spent years working on removing that dependency, and it's no longer there! :-) It's not advertised much yet, but it will be clearly advertised in the release note of the forthcoming gnustep-make release. GNUstep.sh is obsolete in the default setup. You only need to set GNUSTEP_MAKEFILES and everything will work (assuming you have your tools in your path, and libs in your linker paths). This is all already implemented on trunk! :-) Yes, but you still need to do something before running make, which is what this patch is mostly about. You only need to set GNUSTEP_MAKEFILES. This is already on trunk! Once that's clear, we can discuss the patch ;-) I see two good ideas in the patch ... 1. I guess you are suggesting to put a makefile somewhere in the make search path and change all makefiles to include it so that you can compile without even setting GNUSTEP_MAKEFILES. I like the idea of not having to set any variable to compile, but I also see a couple of obvious cons -- it would be more difficult to switch between different gnustep-make installations (at the moment, you can easily switch by just changing GNUSTEP_MAKEFILES!), Not really, the patch allows you to switch installations by setting PKG_CONFIG_PATH and specifying --with-pkgconfig-path to configure to tell it where to put gnustep.pc. The difference being instead of always having to configure it, configuration is made to be something only people who need that behaviour have to do. Sorry for being late to the party, but I've been busy... Right, and also, frankly, there's a very important non-technical aspect to this as well; Way more developers know what the heck .pc files and pkg-config are, as well as how they work, than a funky GNUstep.conf file, which, while somewhat self-explanatory, definitely is proprietary. pkg-config is commonly used and makes things easier for us. As we move towards a totally FHS-capable GNUstep, this is something which should be taken into account, IMHO. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Jan 25, 2007, at 07:15, Nicola Pero wrote: So we could have a small makefile fragment, let's call it find- gnustep.make, that searches for gnustep-make on disk and sets GNUSTEP_MAKEFILES to the best match. I'll write that makefile fragment, and it will be maintained inside gnustep-make. I don't get this one, you want to let the fragment search for gnustep- make? Where will it search? Isn't it expensive to search all locations everytime? I'm not convinced that this can happen automagically. My configure scripts has options to specify the gnustep-make installation you want to use (though of course it tests a few hardcoded locations as a fallback, but only once, at configure time). I think the 'configure' script should be maintained inside gnustep- make (the script which generates the config.make, usually not a real autoconf configure). You probably don't want to run configure everytime you call make ;-) BTW: personally I'm not quite sure whether I understand that /etc/ GNUstep.conf thing :-) Is it necessary or optional? It is necessary. The reason is that it allows gnustep-make and gnustep-base to have a common understanding of where the various directories are. The GNUstep.conf file describes the GNUstep filesystem and both gnustep-make and gnustep-base read it to know where to find things. Well, I'm talking about FHS, why would they need to know? In an FHS the gstep-base just needs a (fallback) prefix like other libraries to know where to look for associated files. Eg ./configure --prefix=/opt/gnustep-base-15 it would then know where to look for resources etc (because thats fixed in FHS). Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Jan 26, 2007, at 02:58, Nicola Pero wrote: The other main change is that using GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT, etc. in makefiles is now discouraged (because it won't work with Linux FHS). I wonder whether those are still useful in an FHS setup (eg let GNUSTEP_SYSTEM_ROOT point to /usr, GNUSTEP_LOCAL_ROOT to /usr/local, etc). Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
>> So we could have a small makefile fragment, let's call it find- >> gnustep.make, >> that searches for gnustep-make on disk and sets GNUSTEP_MAKEFILES >> to the best >> match. I'll write that makefile fragment, and it will be >> maintained inside >> gnustep-make. > >I don't get this one, you want to let the fragment search for gnustep- >make? Where will it search? Isn't it expensive to search all >locations everytime? I'm not convinced that this can happen >automagically. Here is an example -- put this at the top of your GNUmakefile, just before include $(GNUSTEP_MAKEFILES)/common.make -- GNUSTEP_MAKEFILES = $(word 1, \ $(wildcard /usr/GNUstep/System/Library/Makefiles) \ $(wildcard /var/lib/GNUstep/System/Library/Makefiles) \ $(wildcard /usr/local/GNUstep/System/Library/Makefiles) \ $(wildcard /opt/GNUstep/System/Library/Makefiles) \ $(wildcard /System/Library/Makefiles)) the result is that: * if you source GNUstep.sh or have your GNUstep environment properly setup, it gets used * if you set GNUSTEP_MAKEFILES, it gets used * if you have done none of those, the makefile will look for gnustep-make in those standard locations in the order; if it finds it, it will use it. * else, you'll have an error With this 'hack' and gnustep-make from trunk, I can compile stuff with no environment variable set whatsoever. Please note that this is just a draft to give the idea, we should polish the code. Don't use it in real projects yet ;-) And yes, checking that those 5 dirs exist will be done every time so in theory would slow down your compilation. In practice, on any OS they will be in the kernel's cache and you will see no difference in compilation times (if read disk access really mattered, then reading the actual makefiles fragments from gnustep-make's directory would be the dominant factor anyway!). So, no, it really doesn't matter. I even timed it and I can't see any reproducible difference. >My configure scripts has options to specify the gnustep-make >installation you want to use (though of course it tests a few >hardcoded locations as a fallback, but only once, at configure time). > >I think the 'configure' script should be maintained inside gnustep- >make (the script which generates the config.make, usually not a real >autoconf configure). >You probably don't want to run configure everytime you call make ;-) Looks good. I suppose that could be another option (I prefer would prefer a makefile fragment though). ;-) In fact, if we put the makefile bootstrap code into a separate file, we can do a lot better than the above. Ie, we can actually check that GNUSTEP_MAKEFILES is set/found, and print a nice warning message if not. At that point I'm not sure what is missing compared to a configure script. It's better because you just type 'make' and here you go. >>> BTW: personally I'm not quite sure whether I understand that /etc/ >>> GNUstep.conf thing :-) Is it necessary or optional? >> >> It is necessary. The reason is that it allows gnustep-make and >> gnustep-base to have a common understanding of where the various >> directories are. >> The GNUstep.conf file describes the GNUstep filesystem and both >> gnustep-make and gnustep-base read it to know where to find things. > > Well, I'm talking about FHS, why would they need to know? > They would need to know because you can have different FHSes. Different Linux distributions could/will put things in different places. Windows does put things in different places. We will get asked to be able to put things in different places. That's the whole point of the exercise ;-) I suppose we could hardcode all values into gnustep-make and gnustep-base but then they couldn't be relocated. If you can control the locations from a config file instead, it becomes easier to relocate them. Relocating is often a useful trick when building packages (eg), so it looked like a good feature to have. :-) > In an FHS the gstep-base just needs a (fallback) prefix like other > libraries to know where to look for associated files. Eg > > ./configure --prefix=/opt/gnustep-base-15 > Hopefully we can support the full standard range of GNU --bindir=... --xxxdir=yyy options that let you configure exactly where you want everything to go. That requires us to store those option values somewhere. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> Right, and also, frankly, there's a very important non-technical aspect > to this as well; Way more developers know what the heck .pc files and > pkg-config are, as well as how they work, than a funky GNUstep.conf > file, which, while somewhat self-explanatory, definitely is proprietary. > pkg-config is commonly used and makes things easier for us. > > As we move towards a totally FHS-capable GNUstep, this is something > which should be taken into account, IMHO. Thanks ... it's certainly an aspect. :-) There is also another important non-technical aspect, which is the amount of dependencies that you have, and the robustness of your GNUstep configuration/installation process. If we had gnustep-make depend on pkg-config, then you wouldn't be able to use GNUstep unless you installed pkg-config first. That seems a step backwards to me; adding more dependencies makes it more difficult to install things. End users are adversely affected. At the moment, gnustep-make depends on nothing, and doesn't even need building. You just configure it and install. That's very simple and very unlikely to break. :-) That's key. We should keep trying to simplify our configure/build/install process so that more people that try to try GNUstep actually manage to try it ... they are much more likely to stay. :-) So I don't want to add extra dependencies that provide nothing of value just because "way more developers know" about GNOME development tools than about GNUstep development tools. And if you go down that route, you'll end up using glade instead of Gorm! ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
>> If we had gnustep-make depend on pkg-config, then you wouldn't be >> able to use GNUstep unless you installed pkg-config first. > > That's not entirely correct. GNUstep can be taught how to read > pkgconfig-format-file, such as GNUstep.pc, thus eliminating the need > for GNUstep.conf entirely, We designed the GNUstep.conf syntax so that it can be very efficiently read from makefiles, shells, and C/ObjC code. The 'pkg-config' meta-file format can not be read easily from makefiles without firing off a subprocess. We'd then need to fire off an additional subprocess for each invocation of make, which, performance-wise, is bad. Thanks PS: I must be missing your point completely because I don't really understand what you're trying to say. Technically, you're suggesting we depend on the gnome/gtk config tools (which were not designed for us, so the integration would be massively painful) just for the sake of "being more similar to gnome/gtk". But I suspect what you'd really want to discuss is how to compile things without using gnustep-make. Which is a perfectly valid discussion, and in that context pkg-config might make sense. If you want to build using the autoconf/automake/pkg-config toolchain, then using pkg-config is an interesting option. Still, such an option shouldn't prevent the standard users from using the standard GNUstep fast/easy building system if they want, and shouldn't interfere with our internal implementation. The most obvious option is provide a gnustep-config tool that will output the gcc flags for the various stages/types of compilation, and provide some basic indication of where to install things, then you could at least compile and install tools and libraries without gnustep-make. We could make it reasonably similar to the traditional xxx-config gnome/gtk tools if you think that would make it easier to use. We can think about that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-08 20:29:50 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: If we had gnustep-make depend on pkg-config, then you wouldn't be able to use GNUstep unless you installed pkg-config first. That's not entirely correct. GNUstep can be taught how to read pkgconfig-format-file, such as GNUstep.pc, thus eliminating the need for GNUstep.conf entirely, We designed the GNUstep.conf syntax so that it can be very efficiently read from makefiles, shells, and C/ObjC code. The 'pkg-config' meta-file format can not be read easily from makefiles without firing off a subprocess. We'd then need to fire off an additional subprocess for each invocation of make, which, performance-wise, is bad. 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. This is a drop in the bucket. all that make does is execute subprocesses. And this seems to be an argument against -config in general. PS: I must be missing your point completely because I don't really understand what you're trying to say. Technically, you're suggesting we depend on the gnome/gtk config tools (which were not designed for us, so the integration would be massively painful) just for the sake of "being more similar to gnome/gtk". pkg-config is not strictly a gnome/gtk tool (it may have originated there i'm not sure) it is used by many non-gnome projects openssl and xorg are not gnome/gtk -config files in general have been embraced by libraries in general long before pkg-config came about, and it saves libraries from polluting the path with a ton of, -config scripts and generally provides a better -config than software creating their own. 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. in fact theres libxml2, openssl, cairo, libpng, libxslt, audiofile, portaudio, libart, freetype all possible gnustep dependencies from our howto page all which have embraced pkg-config. so out of the 16 potential deps listed there, more than half support pkg-config. But I suspect what you'd really want to discuss is how to compile things without using gnustep-make. Which is a perfectly valid discussion, and in that context pkg-config might make sense. If you want to build using the autoconf/automake/pkg-config toolchain, then using pkg-config is an interesting option. No I believe that he is saying is that pkg-config can be a dependency for gnustep-make and at runtime gnustep can read the .pc file directly. and avoid a runtime dependency on pkg-config. the patch I posted also only had a gnustep-make dependency on pkg-config but since it kept gnustep.conf if you wanted to modify gnustep.conf you also had to modify gnustep.pc The most obvious option is provide a gnustep-config tool that will output the gcc flags for the various stages/types of compilation, and provide some basic indication of where to install things, then you could at least compile and install tools and libraries without gnustep-make. We could make it reasonably similar to the traditional xxx-config gnome/gtk tools if you think that would make it easier to use. We can think about that. 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-08 05:13:32 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: So we could have a small makefile fragment, let's call it find- gnustep.make, that searches for gnustep-make on disk and sets GNUSTEP_MAKEFILES to the best match. I'll write that makefile fragment, and it will be maintained inside gnustep-make. I don't get this one, you want to let the fragment search for gnustep- make? Where will it search? Isn't it expensive to search all locations everytime? I'm not convinced that this can happen automagically. Here is an example -- put this at the top of your GNUmakefile, just before include $(GNUSTEP_MAKEFILES)/common.make -- GNUSTEP_MAKEFILES = $(word 1, \ $(wildcard /usr/GNUstep/System/Library/Makefiles) \ $(wildcard /var/lib/GNUstep/System/Library/Makefiles) \ $(wildcard /usr/local/GNUstep/System/Library/Makefiles) \ $(wildcard /opt/GNUstep/System/Library/Makefiles) \ $(wildcard /System/Library/Makefiles)) This doesn't actually fix anything, if we're going to change the GNUmakefiles so their usable without having environment variables we might as well fix it for all cases not just the most common ones. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 9 Feb 2007, at 13:04, Matt Rice wrote: On 2007-02-08 05:13:32 -0800 Nicola Pero <[EMAIL PROTECTED] innovation.com> wrote: So we could have a small makefile fragment, let's call it find- gnustep.make, that searches for gnustep-make on disk and sets GNUSTEP_MAKEFILES to the best match. I'll write that makefile fragment, and it will be maintained inside gnustep-make. I don't get this one, you want to let the fragment search for gnustep- make? Where will it search? Isn't it expensive to search all locations everytime? I'm not convinced that this can happen automagically. Here is an example -- put this at the top of your GNUmakefile, just before include $(GNUSTEP_MAKEFILES)/common.make -- GNUSTEP_MAKEFILES = $(word 1, \ $(wildcard /usr/GNUstep/System/Library/Makefiles) \ $(wildcard /var/lib/GNUstep/System/Library/Makefiles) \ $(wildcard /usr/local/GNUstep/System/Library/Makefiles) \ $(wildcard /opt/GNUstep/System/Library/Makefiles) \ $(wildcard /System/Library/Makefiles)) This doesn't actually fix anything, if we're going to change the GNUmakefiles so their usable without having environment variables we might as well fix it for all cases not just the most common ones. I don't think there *is* a fix for all cases. I'd certainly much rather have a solution which works for all common cases (as Nicola suggests) than have a dependency on external stuff like pkg-config which definitely won't work on some platforms unless we install it as additional software when installing GNUstep. Installing pkg-config with GNUstep is not a big issue in itsself, but then you get problems if someone else installs a version configured to look in a different place for its data files. It seems to me that using pkg-config would be more fragile than what Nicola suggests, but would be fine to include as a fallback to try when all else fails. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Feb 8, 2007, at 5:42 AM, Nicola Pero wrote: Right, and also, frankly, there's a very important non-technical aspect to this as well; Way more developers know what the heck .pc files and pkg-config are, as well as how they work, than a funky GNUstep.conf file, which, while somewhat self-explanatory, definitely is proprietary. pkg-config is commonly used and makes things easier for us. As we move towards a totally FHS-capable GNUstep, this is something which should be taken into account, IMHO. Thanks ... it's certainly an aspect. :-) There is also another important non-technical aspect, which is the amount of dependencies that you have, and the robustness of your GNUstep configuration/ installation process. If we had gnustep-make depend on pkg-config, then you wouldn't be able to use GNUstep unless you installed pkg-config first. That's not entirely correct. GNUstep can be taught how to read pkgconfig-format-file, such as GNUstep.pc, thus eliminating the need for GNUstep.conf entirely, and then pkgconfig is only a dependency for those who COMPILE or develop apps for GNUstep. Not end users who will likely be installing via a package in their favorite distribution. That seems a step backwards to me; adding more dependencies makes it more difficult to install things. End users are adversely affected. I do strongly believe this is an oversimplification. It is illogical to conclude that more dependencies = automatically a bad thing. At the moment, gnustep-make depends on nothing, and doesn't even need building. You just configure it and install. That's very simple and very unlikely to break. :-) That's key. We should keep trying to simplify our configure/build/ install process so that more people that try to try GNUstep actually manage to try it ... they are much more likely to stay. :-) It depends on what your definition of "simplification" is. Many would surely view some strange GNUstep.conf file as complex simply because it's foreign *to them*, while it's not to you because you played a crucial role in developing said mechanism. So I don't want to add extra dependencies that provide nothing of value just because "way more developers know" about GNOME development tools than about GNUstep development tools. And if you go down that route, you'll end up using glade instead of Gorm! ;-) pkgconfig is a Freedesktop component. It is used by Xorg, openssl, and many, many other projects. It is not simply a part of gnome any longer. See http://pkgconfig.freedesktop.org/ . As such, I personally consider this statement to be rhetorical hyperbole, and I'd like to suggest that perhaps there's a bit of unconscious "Not Invented Here" syndrome playing a role. Looking forward to hearing your thoughts, Alex Perez ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-09 05:27:39 -0800 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: On 9 Feb 2007, at 13:04, Matt Rice wrote: On 2007-02-08 05:13:32 -0800 Nicola Pero <[EMAIL PROTECTED] innovation.com> wrote: So we could have a small makefile fragment, let's call it find- gnustep.make, that searches for gnustep-make on disk and sets GNUSTEP_MAKEFILES to the best match. I'll write that makefile fragment, and it will be maintained inside gnustep-make. I don't get this one, you want to let the fragment search for gnustep- make? Where will it search? Isn't it expensive to search all locations everytime? I'm not convinced that this can happen automagically. Here is an example -- put this at the top of your GNUmakefile, just before include $(GNUSTEP_MAKEFILES)/common.make -- GNUSTEP_MAKEFILES = $(word 1, \ $(wildcard /usr/GNUstep/System/Library/Makefiles) \ $(wildcard /var/lib/GNUstep/System/Library/Makefiles) \ $(wildcard /usr/local/GNUstep/System/Library/Makefiles) \ $(wildcard /opt/GNUstep/System/Library/Makefiles) \ $(wildcard /System/Library/Makefiles)) This doesn't actually fix anything, if we're going to change the GNUmakefiles so their usable without having environment variables we might as well fix it for all cases not just the most common ones. I don't think there *is* a fix for all cases. Yeah, i agree with that... not exactly what I meant though. I meant pkg-config would work if one wanted to install GNUstep somewhere non-standard. I'd certainly much rather have a solution which works for all common cases (as Nicola suggests) than have a dependency on external stuff like pkg-config which definitely won't work on some platforms unless we install it as additional software when installing GNUstep. Installing pkg-config with GNUstep is not a big issue in itsself, but then you get problems if someone else installs a version configured to look in a different place for its data files. Either they can tell pkg-config where to find it with PKG_CONFIG_PATH or they can configure GNUstep to tell it where to put the .pc file.. I wouldn't think GNUstep should be installing pkg-config anyways. if its a compile time dependency only so distributing binaries thered be no risk of this. It seems to me that using pkg-config would be more fragile than what Nicola suggests, but would be fine to include as a fallback to try when all else fails. Not really... both either they work or you have to configure it, its home-brew configuration process or more standard one. his solution also doesn't fix the other issue with finding the libdir from autoconf. I don't really like the idea of using pkg-config as a fallback... because of the potential for people who understand pkg-config attempting to configure gnustep with PKG_CONFIG_PATH and find out its not falling back to using pkg-config... divergent paths of configuration anyhow i guess i will come up with a patch to use a gnustep-config which gets its information from GNUstep.conf and we can argue over that... (in other words reimplement pkg-config for GNUstep) I just don't think we should disregard existing tools/processes lightly. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Feb 9, 2007, at 8:48 AM, Matt Rice wrote: anyhow i guess i will come up with a patch to use a gnustep-config which gets its information from GNUstep.conf and we can argue over that... (in other words reimplement pkg-config for GNUstep) I just don't think we should disregard existing tools/processes lightly. Sure that's true, but remember that these tools are all for non- standard systems. Whenever I think about a change to the GNUstep system, I think first about how it will affect the standard, and I mean "ideal" system, that we are working towards (e.g. one with a nice working ProjectCenter, etc). Neither GNustep.conf nor PKG_CONFIG_PATH would really be needed in the standard installation. Developers always want to do something unusual, so we should make it POSSIBLE for them to do whatever they want, but it's not required to make it easy for them to do it. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-09 08:41:29 -0800 Adam Fedor <[EMAIL PROTECTED]> wrote: On Feb 9, 2007, at 8:48 AM, Matt Rice wrote: anyhow i guess i will come up with a patch to use a gnustep-config which gets its information from GNUstep.conf and we can argue over that... (in other words reimplement pkg-config for GNUstep) I just don't think we should disregard existing tools/processes lightly. Sure that's true, but remember that these tools are all for non- standard systems. Whenever I think about a change to the GNUstep system, I think first about how it will affect the standard, and I mean "ideal" system, that we are working towards (e.g. one with a nice working ProjectCenter, etc). Neither GNustep.conf nor PKG_CONFIG_PATH would really be needed in the standard installation. Developers always want to do something unusual, so we should make it POSSIBLE for them to do whatever they want, but it's not required to make it easy for them to do it. well heres a quick hack on that... only lightly tested just add GNUSTEP_MAKEFILES ?= $(shell gnustep-config --makefiles) include $(GNUSTEP_MAKEFILES)/common.make obviously gnustep-config needs to change wrt recent changes to make/FHS stuff just not sure what those changes are yet. Index: configure.ac === --- configure.ac(revision 24410) +++ configure.ac(working copy) @@ -224,6 +224,21 @@ AC_SUBST(GNUSTEP_CONFIG_FILE) #- +# location of gnustep-config path +#- + +AC_MSG_CHECKING([gnustep-config path location]) +AC_ARG_WITH(config-bindir,[ +--with-config-bindir=PATH +The location to install the gnustep-config binary], +GNUSTEP_CONFIG_BIN_DIR=$withval,GNUSTEP_CONFIG_BIN_DIR=no) +if test "$GNUSTEP_CONFIG_BIN_DIR" = "" -o "$GNUSTEP_CONFIG_BIN_DIR" = "no"; then +GNUSTEP_CONFIG_BIN_DIR="/usr/local/bin/"; +fi +AC_MSG_RESULT($GNUSTEP_CONFIG_BIN_DIR) +AC_SUBST(GNUSTEP_CONFIG_BIN_DIR) + +#- # Now read/import the existing configuration file, if any #- @@ -1060,7 +1075,7 @@ # AC_CONFIG_FILES([config-noarch.make config.make openapp opentool executable.template GNUmakefile GNUstep.conf GNUstep.sh GNUstep.csh fixpath.sh -gnustep-make.spec]) +gnustep-make.spec gnustep-config]) AC_CONFIG_COMMANDS([default], [[chmod a+x openapp opentool fixpath.sh executable.template]], [[]]) Index: gnustep-config.in === --- gnustep-config.in (revision 0) +++ gnustep-config.in (revision 0) @@ -0,0 +1,58 @@ +#!/bin/sh + +if [ $# -lt 1 ]; then +echo "$0: argument required."; +fi + +# Determine the location of the system configuration file +if [ -z "$GNUSTEP_CONFIG_FILE" ]; then + [EMAIL PROTECTED]@ +fi + +# Determine the location of the user configuration file +if [ -z "$GNUSTEP_USER_CONFIG_FILE" ]; then + [EMAIL PROTECTED]@ +fi + +# Read the system configuration file +if [ -f "$GNUSTEP_CONFIG_FILE" ]; then + . "$GNUSTEP_CONFIG_FILE" +fi + +# Read the user configuration file ... unless it is disabled (ie, set +# to an empty string) +if [ -n "$GNUSTEP_USER_CONFIG_FILE" ]; then + case "$GNUSTEP_USER_CONFIG_FILE" in +/*) # An absolute path +if [ -f "$GNUSTEP_USER_CONFIG_FILE" ]; then + . "$GNUSTEP_USER_CONFIG_FILE" +fi;; + *) # Something else +if [ -f "$GNUSTEP_HOME/$GNUSTEP_USER_CONFIG_FILE" ]; then + . "$GNUSTEP_HOME/$GNUSTEP_USER_CONFIG_FILE" +fi;; + esac +fi + + +case "$1" in --makefiles) + echo $GNUSTEP_SYSTEM_ROOT/Library/Makefiles; + exit + ;; +--system-root) + echo $GNUSTEP_SYSTEM_ROOT + exit + ;; +--local-root) + echo $GNUSTEP_LOCAL_ROOT + exit + ;; +--network-root) + echo $GNUSTEP_NETWORK_ROOT + exit + ;; +--user-root) + echo ~/$GNUSTEP_USER_DIR + exit + ;; +esac Index: GNUmakefile.in === --- GNUmakefile.in (revision 24410) +++ GNUmakefile.in (working copy) @@ -141,7 +141,8 @@ $(makedir)/Master \ $(makedir)/Instance \ $(makedir)/Instance/Shared \ - $(makedir)/Instance/Documentation) + $(makedir)/Instance/Documentation \ + @GNUSTEP_CONFIG_BIN_DIR@) $(EC)(echo "Installing GNUstep configuration file in $(GNUSTEP_CONFIG_FILE)"; \ $(srcdir)/mkinstalldirs "$(GNUSTEP_CONFIG_FILE_DIR)"; \ $(INSTALL_DATA) GNUstep.conf "$(GNUSTEP_CONFIG_FILE)") @@ -159,7 +160,8 @@ $(INSTALL_PROGRAM) -m 755 GNUstep.csh $(makedir); \
Re: gnustep-make experiment
Hm, I just read part of this discussion. Apparently pkg-config is a very popular tool for finding dependencies etc. Also it seems to be used by plenty of libraries and people, although I never encountered it in practice. For me a .pc is probably a mystery. So before forming an opinion on pkg-connfig integration with gnustep-make I would like to read up a little on pkg-config. However the only thing I quickly found was a wiki page: http://pkgconfig.freedesktop.org/wiki And beside a link to download section and a list of supportd platforms there seems to be no documentation for pkg-config at all. Obviously that is because I do not look in the right place. Another thing that caught my eye was the dependency on glib, I have had some bad experiences with glib on windows. So next I tried to download pkg-config version 0.21 and compile it (on MS Windows). Of course that failed because I hadn't installed glib. So I gave up. (I tried once to get glib compiled on windows and it wasn't a pleasant experience.) Moral of the story, if someone want to add pkg-config, better make it a smooth experience. I for one don't want to spend a lot of time installing another tool with intricate dependencies just to be able to compile my own application. Wim Oudshoorn. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-09 09:18:02 -0800 Wim Oudshoorn <[EMAIL PROTECTED]> wrote: Hm, I just read part of this discussion. Apparently pkg-config is a very popular tool for finding dependencies etc. Also it seems to be used by plenty of libraries and people, although I never encountered it in practice. For me a .pc is probably a mystery. So before forming an opinion on pkg-connfig integration with gnustep-make I would like to read up a little on pkg-config. However the only thing I quickly found was a wiki page: http://pkgconfig.freedesktop.org/wiki And beside a link to download section and a list of supportd platforms there seems to be no documentation for pkg-config at all. Obviously that is because I do not look in the right place. Another thing that caught my eye was the dependency on glib, I have had some bad experiences with glib on windows. So next I tried to download pkg-config version 0.21 and compile it (on MS Windows). Of course that failed because I hadn't installed glib. So I gave up. (I tried once to get glib compiled on windows and it wasn't a pleasant experience.) It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. (from the page you linked). Moral of the story, if someone want to add pkg-config, better make it a smooth experience. I for one don't want to spend a lot of time installing another tool with intricate dependencies just to be able to compile my own application. Wim Oudshoorn. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Matt Rice <[EMAIL PROTECTED]> writes: > On 2007-02-09 09:18:02 -0800 Wim Oudshoorn <[EMAIL PROTECTED]> wrote: >> So next I tried to download pkg-config version 0.21 and compile it >> (on >> MS Windows). Of course that failed because I hadn't installed glib. >> So >> I gave up. (I tried once to get glib compiled on windows and it >> wasn't a pleasant experience.) >> > > It does not require anything but a reasonably well working C compiler > and a C library, > but can use an installed glib if that is present. Well, did you actually try compiling pkg-config? I did not investigate deeply but the suggested way of compiling: ./configure make Did not work. ./configure succeeded splendidly, but make failed and the reason was that glib.h could not be found. But I don't want to start a discussion in the GNUstep mailing lists on how to install pkg-config. I just wanted to see how it would work on windows. Wim Oudshoorn. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-09 09:37:11 -0800 Wim Oudshoorn <[EMAIL PROTECTED]> wrote: Matt Rice <[EMAIL PROTECTED]> writes: On 2007-02-09 09:18:02 -0800 Wim Oudshoorn <[EMAIL PROTECTED]> wrote: So next I tried to download pkg-config version 0.21 and compile it (on MS Windows). Of course that failed because I hadn't installed glib. So I gave up. (I tried once to get glib compiled on windows and it wasn't a pleasant experience.) It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. Well, did you actually try compiling pkg-config? I did not investigate deeply but the suggested way of compiling: ../configure make Did not work. ./configure succeeded splendidly, but make failed and the reason was that glib.h could not be found. But I don't want to start a discussion in the GNUstep mailing lists on how to install pkg-config. I just wanted to see how it would work on windows. No not on win32, but it seems to be covered in README.win32, it seems win32 build requires glib-2.0. linux without win32 will build glib-1.2.8 which doesn't work on win32 or something.. kinda odd. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Just to chime in... I compiled pkg-config from source a couple of times and it does need glib. I haven't been able to work around glib. Dennis Wim Oudshoorn wrote: Matt Rice <[EMAIL PROTECTED]> writes: On 2007-02-09 09:18:02 -0800 Wim Oudshoorn <[EMAIL PROTECTED]> wrote: So next I tried to download pkg-config version 0.21 and compile it (on MS Windows). Of course that failed because I hadn't installed glib. So I gave up. (I tried once to get glib compiled on windows and it wasn't a pleasant experience.) It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. Well, did you actually try compiling pkg-config? I did not investigate deeply but the suggested way of compiling: ./configure make Did not work. ./configure succeeded splendidly, but make failed and the reason was that glib.h could not be found. But I don't want to start a discussion in the GNUstep mailing lists on how to install pkg-config. I just wanted to see how it would work on windows. Wim Oudshoorn. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Wim Oudshoorn schrieb: > Matt Rice <[EMAIL PROTECTED]> writes: > >> On 2007-02-09 09:18:02 -0800 Wim Oudshoorn <[EMAIL PROTECTED]> wrote: >>> So next I tried to download pkg-config version 0.21 and compile it >>> (on >>> MS Windows). Of course that failed because I hadn't installed glib. >>> So >>> I gave up. (I tried once to get glib compiled on windows and it >>> wasn't a pleasant experience.) >>> >> It does not require anything but a reasonably well working C compiler >> and a C library, >> but can use an installed glib if that is present. > > Well, did you actually try compiling pkg-config? > I did not investigate deeply but the suggested way of compiling: > > ./configure > make > > Did not work. ./configure succeeded splendidly, but make > failed and the reason was that glib.h could not be found. > > But I don't want to start a discussion in the GNUstep mailing lists on > how to install pkg-config. I just wanted to see how it would work on > windows. > I wanted to keep out of this discussion, but somehow these resolutions never work out :-) First of all there is a pre-compiled pkg-config for Windows on the Gimp download page, but be warned, I have not used it myself: http://www.gimp.org/~tml/gimp/win32/pkg-config-0.20.zip Second, I like the idea of using more standard tools in the GNUstep configuration and compilation process. pkg-config could come in rather nicely here. But I don't quite understand, how it could be used as a replacement for GNUstep.conf. Not that I like the role GNUstep.conf is currently playing in GNUstep, but this is clearly different from what pkg-config is normally doing. GNUstep.conf is a file that gets accessed each time a GNUstep application is run to find out about the various GNUstep settings. It is there to allow GNUstep installations to be moved to arbitrary places after compilation. pkf-config is by its intention a compile time tool. It looks for include paths and libraries and such stuff. It is not supposed to be around when a compiled application or libraries is run. Third, Nicola keeps on claiming in this thread that a standard GNUstep could be compiled by just setting the values in GNUstep.conf and doing nothing else. This does not work for me, I still need to source GNUstep.sh to get things working. Otherwise the compilation of gui complains that it cannot find the base library. This is not too bad, I am used to this behaviour. I just wanted to scale back some claims made here. Last, I would expect that a standard GNUstep should even run without a GNUstep.conf file being set up. It may be easier for people who love to move things to have a template file that they only need to change. But do we really have to install this template already? Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Feb 8, 2007, at 14:13, Nicola Pero wrote: Here is an example -- put this at the top of your GNUmakefile, just before include $(GNUSTEP_MAKEFILES)/common.make -- GNUSTEP_MAKEFILES = $(word 1, \ $(wildcard /usr/GNUstep/System/Library/Makefiles) \ $(wildcard /var/lib/GNUstep/System/Library/Makefiles) \ $(wildcard /usr/local/GNUstep/System/Library/Makefiles) \ $(wildcard /opt/GNUstep/System/Library/Makefiles) \ $(wildcard /System/Library/Makefiles)) the result is that: * if you source GNUstep.sh or have your GNUstep environment properly setup, it gets used I suppose this hack would work for me, but I don't think that this is what admins expect from a GNU software package. Regular thing to do is ./configure --prefix, then make. Though of course the real fragment could also check for 'config.make', giving us both things, the automatic attempt and the configurability ;-) Well, I'm talking about FHS, why would they need to know? They would need to know because you can have different FHSes. Last time I checked there is only one file hierarchy standard! ;-) Well, really, this is something which belongs into the resource- lookup class (NSBundle and friends), not into an environment configuration (why would you ever want to switch that for a compiled binary!). I think Unixes only really differ in the PREFIX? Then we have Windows, completely different approach. MacOS is more like GNUstep and should not be treated as FHS (in contrary, on MacOS you probably also want to have some stuff in FHS, and some in MacOS layout). Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-10 05:20:45 -0800 Fred Kiefer <[EMAIL PROTECTED]> wrote: Wim Oudshoorn schrieb: Matt Rice <[EMAIL PROTECTED]> writes: On 2007-02-09 09:18:02 -0800 Wim Oudshoorn <[EMAIL PROTECTED]> wrote: So next I tried to download pkg-config version 0.21 and compile it (on MS Windows). Of course that failed because I hadn't installed glib. So I gave up. (I tried once to get glib compiled on windows and it wasn't a pleasant experience.) It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. Well, did you actually try compiling pkg-config? I did not investigate deeply but the suggested way of compiling: ./configure make Did not work. ./configure succeeded splendidly, but make failed and the reason was that glib.h could not be found. But I don't want to start a discussion in the GNUstep mailing lists on how to install pkg-config. I just wanted to see how it would work on windows. Second, I like the idea of using more standard tools in the GNUstep configuration and compilation process. pkg-config could come in rather nicely here. But I don't quite understand, how it could be used as a replacement for GNUstep.conf. Not that I like the role GNUstep.conf is currently playing in GNUstep, but this is clearly different from what pkg-config is normally doing. GNUstep.conf is a file that gets accessed each time a GNUstep application is run to find out about the various GNUstep settings. It is there to allow GNUstep installations to be moved to arbitrary places after compilation. pkf-config is by its intention a compile time tool. It looks for include paths and libraries and such stuff. It is not supposed to be around when a compiled application or libraries is run. Yes, someone pointed out the gnustep.pc and GNUstep.conf files duplicate information, and then the discussion went to gnustep libraries could also be tought to read gnustep.pc directly without pkg-config to replace gnustep.conf, so we don't have to add a runtime dependency but i admit, this is stretching pkg-config and abnormal usage. but personally I was fine with the duplicate information as they do different things, gnustep.pc for compile time and gnustep.conf for runtime. actually most of this information was auxiliary and wasn't even used by GNUstep-make only GNUSTEP_MAKEFILES was used. I initially thought it was required, but it is not with Nicolas recent changes to svn. but the rest should stay for things unable to use gnustep-make Third, Nicola keeps on claiming in this thread that a standard GNUstep could be compiled by just setting the values in GNUstep.conf and doing nothing else. This does not work for me, I still need to source GNUstep.sh to get things working. Otherwise the compilation of gui complains that it cannot find the base library. This is not too bad, I am used to this behaviour. I just wanted to scale back some claims made here. I actually haven't tried this but i assume you set GNUSTEP_MAKEFILES? I don't believe Nicola actually said that, he said you don't have to source GNUstep.sh, only set GNUSTEP_MAKEFILES. I'd assume you must have set GNUSTEP_MAKEFILES otherwise i'd expect it to bail out before including common.make... strange Last, I would expect that a standard GNUstep should even run without a GNUstep.conf file being set up. It may be easier for people who love to move things to have a template file that they only need to change. But do we really have to install this template already? not sure about this one ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> 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. I consider that unacceptable considering we don't gain anything in functionality, and the improvement in 'standardization' is extremely doubtful. > 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. 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. > 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. ;-) 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. 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. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-10 09:27:32 -0800 Nicola Pero <[EMAIL PROTECTED]> 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 GNUstep.sh/environment 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
Re: gnustep-make experiment
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
Re: gnustep-make experiment
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 w
Re: gnustep-make experiment
On 2007-02-10 12:53:55 -0800 Matt Rice <[EMAIL PROTECTED]> wrote: 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. Forgot to mention it'd also have to look for GNUSTEP_USER_CONFIG file and do all that stuff GNUstep.sh does... it seems much more complicated and with possible configurations/documentation forking all over the place in different directions.. than just saying "pkg-config" is not configured correctly. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-10 11:48:55 -0800 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: 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. The 'dependency' on pkg-config is exagerated actually... if pkg-config is not installed as i somewhere in this thread suggested GNUSTEP_MAKEFILES ?= $(shell pkg-config --variable=makefiles) include $(GNUSTEP_MAKEFILES)/common.make you could just set GNUSTEP_MAKEFILES and be done with it. that line is functionally equivalent to ifeq ($(origin GNUSTEP_MAKEFILES), undefined GNUSTEP_MAKEFILES = $(shell pkg-config --variable=makefiles) endif and if you tried to ./configure something which required the gnustep pkg-config support you'd get an error that pkg-config wasn't found in the configure.log this was so that new makefiles could work with old gnustep-make versions but is equally usable with new gnustep-makes without pkg-config. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Wim Oudshoorn wrote: Hm, I just read part of this discussion. Apparently pkg-config is a very popular tool for finding dependencies etc. Also it seems to be used by plenty of libraries and people, although I never encountered it in practice. For me a .pc is probably a mystery. So before forming an opinion on pkg-connfig integration with gnustep-make I would like to read up a little on pkg-config. However the only thing I quickly found was a wiki page: http://pkgconfig.freedesktop.org/wiki And beside a link to download section and a list of supportd platforms there seems to be no documentation for pkg-config at all. Obviously that is because I do not look in the right place. Another thing that caught my eye was the dependency on glib, I have had some bad experiences with glib on windows. So next I tried to download pkg-config version 0.21 and compile it (on MS Windows). Of course that failed because I hadn't installed glib. So I gave up. (I tried once to get glib compiled on windows and it wasn't a pleasant experience.) Moral of the story, if someone want to add pkg-config, better make it a smooth experience. I for one don't want to spend a lot of time installing another tool with intricate dependencies just to be able to compile my own application. I think we're missing the point of pkg-config here. pkgconfig is useless under Window. It's not designed to work under windows. Windows has its own library lookup mechanisms. They should be used. pkgconfig simply should not be used under windows, nor should gnustep.conf. Wim Oudshoorn. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> Third, Nicola keeps on claiming in this thread that a standard GNUstep > could be compiled by just setting the values in GNUstep.conf and doing > nothing else. This does not work for me, I still need to source > GNUstep.sh to get things working. Otherwise the compilation of gui > complains that it cannot find the base library. This is not too bad, I > am used to this behaviour. I just wanted to scale back some claims made > here. Did you add your System Libraries directory and your Local Libraries directory to /etc/ld.so.conf ? Did you run ldconfig after installing any new library ? If not, it won't work. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> The only objection i've heard from gnustep.pc is "Its not the way > GNUstep stores information". Here is a refresher -- 1. it adds an external dependency upon which *everything* would depend 2. it is slower 3. it is designed for something else (which adds complexity) 4. it requires rewriting and redesigning stuff with no clear advantages > The objection i have with GNUstep.conf is it isolates gnustep from the > rest of the world. I find that objection vague. Can you explain the practical meaning of "it isolates gnustep from the rest of the world" ? It's a text file in /etc/GNUstep.conf containing something like GNUSTEP_SYSTEM_ROOT=/usr/GNUstep/System GNUSTEP_LOCAL_ROOT=/usr/GNUstep/Local It's not like we're designing a massive new language to use in the config file. We have a sequence of key=value lines in a plain text file. Editing GNUstep.conf is something that should be very unusual, but if it happens, it shouldn't be very difficult. It's just a plain key=value text file! > We cannot have a build system where information is only available to > GNUstep-make. It makes sense ... so I added a script called gnustep-config.sh that is installed in system Tools (hence always in PATH), that will print out the values of whatever configuration variable you want ... eg, [EMAIL PROTECTED] make]$ gnustep-config.sh GNUSTEP_MAKEFILES /opt/gnustep-new/System/Library/Makefiles [EMAIL PROTECTED] make]$ gnustep-config.sh GNUSTEP_IS_FLATTENED yes [EMAIL PROTECTED] make]$ gnustep-config.sh GNUSTEP_SYSTEM_ROOT /opt/gnustep-new/System [EMAIL PROTECTED] make]$ gnustep-config.sh GNUSTEP_USER_DEFAULTS_DIR GNUstep/Defaults Using that information, you can use whatever external tools you want to build or configure. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
I like the idea of your patch, so I rewrote the shell script and committed it. Thanks! ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-10 17:35:44 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: I like the idea of your patch, so I rewrote the shell script and committed it. Thanks! so can we change everything to GNUSTEP_MAKEFILES ?= $(shell gnustep-config.sh GNUSTEP_MAKEFILES) include $(GNUSTEP_MAKEFILES)/common.make or something like the makefile include path, (though i prefer the above) this was the original intention of my patch, to make it possible to not set any GNUstep specific environment variables and just have make work. I understand that now makefiles *CAN* but will it be the standard practice ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-10 17:34:59 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: The only objection i've heard from gnustep.pc is "Its not the way GNUstep stores information". Here is a refresher -- 1. it adds an external dependency upon which *everything* would depend an entirely optional dependency, people could continue sourcing GNUstep.sh. 2. it is slower -make is not a bottleneck... for example on my machine -make building base here takes 2 minutes 3 seconds... make when base is already built takes 2 seconds.. where adding this stuff to make would be 0.006th of a second per invocation of pkg-config/gnustep-config this argument is hogwash. 3. it is designed for something else (which adds complexity) It does exactly the same thing gnustep-config.sh does. that adds no complexity... 4. it requires rewriting and redesigning stuff with no clear advantages there are clear advantages... now I can add stuff to configure for things *using* gnustep-make which attempts to see if GNUstep libraries exist. there could be a way to bootstrap gnustep-make to "just work" without any gnustep specific environment variables. The objection i have with GNUstep.conf is it isolates gnustep from the rest of the world. I find that objection vague. Can you explain the practical meaning of "it isolates gnustep from the rest of the world" ? It's a text file in /etc/GNUstep.conf containing something like it can be set by --with-config-file when configuring make. If this is done, GNUstep can find GNUstep.conf without setting GNUSTEP_CONFIG_FILE... GNUSTEP_CONFIG_FILE is provided to override the location of /etc/GNUstep.conf if you didn't change the default GNUstep.conf location. I refuse to rely on a feature which a) 99% of the time is fine. b) the 1% of the time works unless your relying on GNUstep.conf being findable theres no way to reliably locate it if the caller was not generated by GNUstep-make's configure script. GNUSTEP_SYSTEM_ROOT=/usr/GNUstep/System GNUSTEP_LOCAL_ROOT=/usr/GNUstep/Local It's not like we're designing a massive new language to use in the config file. We have a sequence of key=value lines in a plain text file. Thats all fine and dandy if it can be located. Editing GNUstep.conf is something that should be very unusual, but if it happens, it shouldn't be very difficult. It's just a plain key=value text file! that is why i don't understand the need to refrain from duplicate information in GNUstep.conf and gnustep.pc if you are relocating a build environment (should be much more unusual than GNUstep.conf requiring being changed) modify gnustep.pc and GNUstep.conf otherwise modify GNUstep.conf not very difficult ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Hi I usually try to avoid playing with GNUstep on Windows as it always takes too long to setup an environment to run stuff in, but these pkg-config discussions drew me back in. > Wim Oudshoorn schrieb: > > > > Well, did you actually try compiling pkg-config? > > I did not investigate deeply but the suggested way of compiling: > > > > ./configure > > make > > > > Did not work. ./configure succeeded splendidly, but make > > failed and the reason was that glib.h could not be found. > > > > But I don't want to start a discussion in the GNUstep mailing lists on > > how to install pkg-config. I just wanted to see how it would work on > > windows. > > > > I wanted to keep out of this discussion, but somehow these resolutions > never work out :-) > > First of all there is a pre-compiled pkg-config for Windows on the Gimp > download page, but be warned, I have not used it myself: > http://www.gimp.org/~tml/gimp/win32/pkg-config-0.20.zip I started by trying to compile the glib included with pkg-config on Windows...this failed to work properly. I then tried to download the source code for glib 2.0 on Windows. Quite annoyingly, glib 2.0 depends on pkg-config, and pkg-config depends on glib, which leads to a ridiculous chicken-and-egg situation. I gave up trying to compile either of them and downloaded the binaries from gimp.org. They seem to work correctly, although I was struggling with the pkg-config files that come with all the gnuwin32 stuff (i.e. all those precompiled dependencies such as zlib, libjpeg, libtiff, libpng, etc). This is because as pkg-config hardcodes paths in its .pc files, and the .pc files distributed with gnuwin32 binaries pathnames to directories on the machines they were compiled on e.g. c:/progra~1/libiconv. Hopefully things like this can be cleaned up with a sed script. > Second, I like the idea of using more standard tools in the GNUstep > configuration and compilation process. pkg-config could come in rather > nicely here. But I don't quite understand, how it could be used as a > replacement for GNUstep.conf. Not that I like the role GNUstep.conf is > currently playing in GNUstep, but this is clearly different from what > pkg-config is normally doing. GNUstep.conf is a file that gets accessed > each time a GNUstep application is run to find out about the various > GNUstep settings. It is there to allow GNUstep installations to be moved > to arbitrary places after compilation. pkf-config is by its intention a > compile time tool. It looks for include paths and libraries and such > stuff. It is not supposed to be around when a compiled application or > libraries is run. Considering some of the effort needed to get pkg-config working on Windows, could we please maintain all existing build methods in gnustep-make? IMHO pkg-config still feels like a alpha quality programme in some environments, despite being widely used. The classic gnustep-make build environment is still my first choice and is alot easier to install as it has no unusual or difficult dependencies. Lastly, on a slightly unrelated note, the GNU dependencies (zlib, libpng, libjpeg, etc) that are needed to compile GNUstep on Windows can be automated using an installer from the gnuwin32.sf.net project which downloads most of the precompiled GNU environment. I was thinking that it may be possible to take the scripts given there, combine them with scripts for installing mingw/msys and create an installable mingw environment on Windows that is ready to compile source code within. Regards Chris -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-10 20:46:30 -0800 Christopher Armstrong <[EMAIL PROTECTED]> wrote: Considering some of the effort needed to get pkg-config working on Windows, could we please maintain all existing build methods in gnustep-make? IMHO pkg-config still feels like a alpha quality programme in some environments, despite being widely used. The classic gnustep-make build environment is still my first choice and is alot easier to install as it has no unusual or difficult dependencies. Yes somewhere in this thread backwards compatibility with old GNUstep-makes was discussed and it was stated that one could add GNUSTEP_MAKEFILES ?= $(shell pkg-config --variables=makefiles) include $(GNUSTEP_MAKEFILES)/common.make and create makefiles which work with old GNUstep-makes which weren't pkg-config enabled this same mechanism can be used to subvert the pkg-config dependency by manually setting GNUSTEP_MAKEFILES or sourcing GNUstep.sh Anyhow now we have gnustep-config.sh which works similarly to pkg-config without the optional dependency... Its definately up in the air though whether this will become a recommended addition to GNUmakefiles or not... Lastly, on a slightly unrelated note, the GNU dependencies (zlib, libpng, libjpeg, etc) that are needed to compile GNUstep on Windows can be automated using an installer from the gnuwin32.sf.net project which downloads most of the precompiled GNU environment. I was thinking that it may be possible to take the scripts given there, combine them with scripts for installing mingw/msys and create an installable mingw environment on Windows that is ready to compile source code within. Regards Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 11 Feb 2007, at 00:38, Nicola Pero wrote: Third, Nicola keeps on claiming in this thread that a standard GNUstep could be compiled by just setting the values in GNUstep.conf and doing nothing else. This does not work for me, I still need to source GNUstep.sh to get things working. Otherwise the compilation of gui complains that it cannot find the base library. This is not too bad, I am used to this behaviour. I just wanted to scale back some claims made here. Did you add your System Libraries directory and your Local Libraries directory to /etc/ld.so.conf ? Did you run ldconfig after installing any new library ? If not, it won't work. That's the same for lots of non-gnustep stuff too, but mostly non- gnustep stuff seems to avoid the problem. I suspect that many packages have their installation scripts run ldconfig for you. Perhaps gnustep-make could be enhanced to do that on systems where / etc/ld.so.conf and ldconfig are available? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 11 Feb 2007, at 04:33, Matt Rice wrote: On 2007-02-10 17:34:59 -0800 Nicola Pero <[EMAIL PROTECTED] innovation.com> wrote: The only objection i've heard from gnustep.pc is "Its not the way GNUstep stores information". Here is a refresher -- 1. it adds an external dependency upon which *everything* would depend an entirely optional dependency, people could continue sourcing GNUstep.sh. That implies that either you expect people to write makefiles which are deliberately non-portable (ie they make use of pkg-config and don't work on systems where pkg-config is not installed) or you require them to adopt some convention for having the makefile determine whether pkg-config is available, use it if is, and tell them to source GNUstep.sh if it isn't (presumably include several lines at the top of each makefile). To while it could be optional, it could not be optional in a transparent way. So Nicola's objection stands it adds a dependency, or unpleasent consequences of working round the natural dependency. 2. it is slower -make is not a bottleneck... for example on my machine -make building base here takes 2 minutes 3 seconds... make when base is already built takes 2 seconds.. where adding this stuff to make would be 0.006th of a second per invocation of pkg-config/gnustep-config this argument is hogwash. I agree that performance is not a significant issue ... however, where we are looking at two alternative solutions providing identical benefits in all other respects, this could swing the argument. 3. it is designed for something else (which adds complexity) It does exactly the same thing gnustep-config.sh does. that adds no complexity... No difference in complexity of usage, but gnustep-sh parses a simpler file format and uses simpler code so is less complex / more maintainable in that sense. However I suspect the issue is pretty much unimportant. 4. it requires rewriting and redesigning stuff with no clear advantages there are clear advantages... now I can add stuff to configure for things *using* gnustep-make which attempts to see if GNUstep libraries exist. there could be a way to bootstrap gnustep-make to "just work" without any gnustep specific environment variables. Those are not advantages of pkg-config. Those are examples of where the use of pkg-config would provide the same functionality. Early on in this thread Nicola suggested both gnustep-config.sh and the use of a makefile fragment as ways of doing the same thing, so pkg-config provides no advantage in this respect. The objection i have with GNUstep.conf is it isolates gnustep from the rest of the world. I find that objection vague. Can you explain the practical meaning of "it isolates gnustep from the rest of the world" ? It's a text file in /etc/GNUstep.conf containing something like it can be set by --with-config-file when configuring make. If this is done, GNUstep can find GNUstep.conf without setting GNUSTEP_CONFIG_FILE... GNUSTEP_CONFIG_FILE is provided to override the location of /etc/GNUstep.conf if you didn't change the default GNUstep.conf location. I refuse to rely on a feature which a) 99% of the time is fine. b) the 1% of the time works unless your relying on GNUstep.conf being findable theres no way to reliably locate it if the caller was not generated by GNUstep-make's configure script. What that boils down to is the fact that you need to be able to find part of GNUstep (eg by having gnustep-config.sh or something else in your PATH or having the GNUstep.conf in a standard location). Certainly someone can hide GNUstep from you, but why should they. Of course the same objection applies to pkg-config ... there is no way to reliably find that if it is in a non standard location and hasn't been put in your PATH. So to summarise the 'why not to use pkg-config to avoid defining GNUSTEP_MAKEFILES': 1. argument stands 2. argument stands but is very weak 3. argument stands but is very weak 4. argument stands, strength depends on the amount of rewriting required, which I haven't assessed. The idea of using pkg-config to avoid defining GNUSTEP_MAKEFILES is comprehensively demolished, but the idea was a good one for raising the point that it's nice if people can just they 'make' with no other preparation needed to build stuff. I think it makes sense to recommend that people use: GNUSTEP_MAKEFILES ?= $(shell gnustep-config.sh GNUSTEP_MAKEFILES) include $(GNUSTEP_MAKEFILES)/common.make All this really has no relevance to whether we want to make pkg- config metadata files available for external build systems to use in linking with GNUstep libraries, bundles, and frameworks... I think that would be a nice feature. People wanting to produce portable packages would not use it, but most developers are probably quite happy producing software which only runs on gnu/linux and these people cou
Re: gnustep-make experiment
Matt Rice wrote: On 2007-02-10 17:34:59 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: The only objection i've heard from gnustep.pc is "Its not the way GNUstep stores information". Here is a refresher -- 1. it adds an external dependency upon which *everything* would depend an entirely optional dependency, people could continue sourcing GNUstep.sh. 2. it is slower -make is not a bottleneck... for example on my machine -make building base here takes 2 minutes 3 seconds... make when base is already built takes 2 seconds.. where adding this stuff to make would be 0.006th of a second per invocation of pkg-config/gnustep-config this argument is hogwash. 3. it is designed for something else (which adds complexity) It does exactly the same thing gnustep-config.sh does. that adds no complexity... 4. it requires rewriting and redesigning stuff with no clear advantages there are clear advantages... now I can add stuff to configure for things *using* gnustep-make which attempts to see if GNUstep libraries exist. there could be a way to bootstrap gnustep-make to "just work" without any gnustep specific environment variables. The objection i have with GNUstep.conf is it isolates gnustep from the rest of the world. I find that objection vague. Can you explain the practical meaning of "it isolates gnustep from the rest of the world" ? It's a text file in /etc/GNUstep.conf containing something like it can be set by --with-config-file when configuring make. If this is done, GNUstep can find GNUstep.conf without setting GNUSTEP_CONFIG_FILE... GNUSTEP_CONFIG_FILE is provided to override the location of /etc/GNUstep.conf if you didn't change the default GNUstep.conf location. I refuse to rely on a feature which a) 99% of the time is fine. b) the 1% of the time works unless your relying on GNUstep.conf being findable theres no way to reliably locate it if the caller was not generated by GNUstep-make's configure script. That's a chicken and egg problem with every configuration. If I compile apache in /opt the configuration of apache will live in /opt/etc/apache, or /opt/etc/httpd, which is not the system default location. Because I choose it to be different, hence the need for a configure option to point to the config file. The same goes for the .pc files. Ever tried to build the pkg-package supported libraries in non-default places (like in /usr/GNUstep/System/Library/Libraries)... then you also have to set the PKG_CONFIG_PATH variable to make make it all happen. Same goes for ldconfig... it per default only searches the FHS default places. Hence the need for /etc/ld.so.conf... but what if you configure ldconfig for /usr/GNUstep/System/Configuration as the /etc directory. What I am trying to say is that every system that you invent to do "automagic" for paths, libraries etc. will rely on defaults and needs environment vars for the exceptions. I doubt you will ever find a package that solves all problems. Just my 2 cents. Dennis ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Nicola Pero schrieb:
> I like the idea of your patch, so I rewrote the shell script and committed it.
>
Minor nit... isn't gnustep-config.sh meant to be executed, not sourced?
So shouldn't it be named gnustep-config instead of gnustep.config.sh?
I'm trying to follow this discussion but it seems that we are not
addressing the issues which /I/ thought we are trying to solve.
I thought the main point was to enable ./configure to test for the
existence/usability of GNUstep libraries/frameworks. So shouldn't it be
installed in into a standard system path instead of
GNUSTEP_SYSTEM_ROOT/Tools? I would expect /usr/local/bin or whatever
--bindir is set to for configure of -make.
So how does is help with writing configure scripts?
Maybe something like?
GNUSTEP_MAKEFILES=${GNUSTEP_MAKEFILES:=`gnustep-config GNUSTEP_MAKEFILES`}
if test -z "$GNUSTEP_PATHLIST"; then
. ${GNUSTEP_MAKEFILES}/GNUstep.sh
fi
And then, once all the variables are set, how should we write configure
script tests? (and which variables are we allowed to use?)
Should we
1) tweak the environment to allow AC_CHECK_LIB to work?
2) create our own:
- AC_CHECK_GNUSTEP_LIBRARY
- AC_CHECK_GNUSTEP_FRAMWORK
- AC_CHECK_GNUSTEP_NATIVELIBRARY
macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES?
3) invoke 'make' with gnustep makefiles in some config subdirectory
during ./configure
4) other ideas which I may have missed?
Note that I haven't really understood how pkg-config would be used at
this level either. But I get the feeling that we are not solving the
issues we are aiming at. But maybe I'm just confused, so I guess it
would be great if the usage of the two approaches in the context of
configure scripts could be summarized.
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> so can we change everything to > > GNUSTEP_MAKEFILES ?= $(shell gnustep-config.sh GNUSTEP_MAKEFILES) > include $(GNUSTEP_MAKEFILES)/common.make I think it's a good suggestion, even if I'd change it (slightly) to be ifeq ($(GNUSTEP_MAKEFILES),) GNUSTEP_MAKEFILES := $(shell gnustep-config.sh GNUSTEP_MAKEFILES) endif include $(GNUSTEP_MAKEFILES)/common.make ... At the moment, this does look like the best suggestion to avoid setting GNUSTEP_MAKEFILES before compiling. :-) Probably a good idea to be careful here and wait a week or two to make sure nobody comes up with a good objection / better solution, else, yes, I'd say we can make it an official recommendation and start to update all makefiles. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
>> I like the idea of your patch, so I rewrote the shell script and committed >> it. > > > Minor nit... isn't gnustep-config.sh meant to be executed, not sourced? > So shouldn't it be named gnustep-config instead of gnustep.config.sh? Yes, it is meant to be executed, not sourced. Not sure what implication that does have on the '.sh' at the end of the name though. Maybe omitting the '.sh' would allow us more freedom in the future, eg, to replace the script with a compiled binary if we ever need ? Any suggestions/comments on what the best name is ? > I thought the main point was to enable ./configure to test for the > existence/usability of GNUstep libraries/frameworks. So shouldn't it be > installed in into a standard system path instead of > GNUSTEP_SYSTEM_ROOT/Tools? I would expect /usr/local/bin or whatever > --bindir is set to for configure of -make. If GNUSTEP_SYSTEM_ROOT/Tools is not in your PATH, then GNUstep is either not installed, or completely unusable - and your configure should fail in that case. ;-) Thanks PS: I'll answer the rest of your email later on, I have to catch a flight now, just wanted to make sure we have the discussion on gnustep-config.sh vs gnustep-config ASAP. ;-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-11 04:47:50 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: so can we change everything to GNUSTEP_MAKEFILES ?= $(shell gnustep-config.sh GNUSTEP_MAKEFILES) include $(GNUSTEP_MAKEFILES)/common.make I think it's a good suggestion, even if I'd change it (slightly) to be ifeq ($(GNUSTEP_MAKEFILES),) GNUSTEP_MAKEFILES := $(shell gnustep-config.sh GNUSTEP_MAKEFILES) endif include $(GNUSTEP_MAKEFILES)/common.make i'm wondering why? the first works if GNUSTEP_MAKEFILES is unset. the second works if GNUSTEP_MAKEFILES is unset or empty. include $(GNUSTEP_MAKEFILES)/common.make would never have worked in either case, i'd rather fix case 1 and consider case 2 a broken build environment. unless this is about = vs := where there exists nothing like :?= and I think the first one is alot easier to remember/easier on the eyes. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-11 05:02:53 -0800 Matt Rice <[EMAIL PROTECTED]> wrote: unless this is about = vs := where there exists nothing like :?= this seems to be the case how := only execute the $(shell) a few times instead of once per time $(GNUSTEP_MAKEFILES) is used ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-11 05:00:20 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: I like the idea of your patch, so I rewrote the shell script and committed it. Minor nit... isn't gnustep-config.sh meant to be executed, not sourced? So shouldn't it be named gnustep-config instead of gnustep.config.sh? Yes, it is meant to be executed, not sourced. Not sure what implication that does have on the '.sh' at the end of the name though. Maybe omitting the '.sh' would allow us more freedom in the future, eg, to replace the script with a compiled binary if we ever need ? Any suggestions/comments on what the best name is ? definately prefer gnustep-config for the above reasons ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Nicola Pero schrieb: >>>I like the idea of your patch, so I rewrote the shell script and committed >>>it. >> >> >>Minor nit... isn't gnustep-config.sh meant to be executed, not sourced? >>So shouldn't it be named gnustep-config instead of gnustep.config.sh? > > > Yes, it is meant to be executed, not sourced. Not sure what implication > that does have on the '.sh' at the end of the name though. > > Maybe omitting the '.sh' would allow us more freedom in the future, eg, > to replace the script with a compiled binary if we ever need ? > > Any suggestions/comments on what the best name is ? IIRC we had some extensive discussions on the mailing lists that .sh/.csh should only be used for scripts that are sourced. But since GNUStep.sh is referenced so often in the archives, I'm having a hard time finding the discussion. >>I thought the main point was to enable ./configure to test for the >>existence/usability of GNUstep libraries/frameworks. So shouldn't it be >>installed in into a standard system path instead of >>GNUSTEP_SYSTEM_ROOT/Tools? I would expect /usr/local/bin or whatever >>--bindir is set to for configure of -make. > > > If GNUSTEP_SYSTEM_ROOT/Tools is not in your PATH, then GNUstep is either > not installed, or completely unusable - and your configure should fail in that > case. ;-) OK, I guess I missing the point of the pkg-config/gnustep-config discussion. I admit that I'm confused about role/intent of all of these configuration files and relocaction capabilities. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-11 03:23:35 -0800 David Ayers <[EMAIL PROTECTED]> wrote:
Nicola Pero schrieb:
So how does is help with writing configure scripts?
Maybe something like?
GNUSTEP_MAKEFILES=${GNUSTEP_MAKEFILES:=`gnustep-config
GNUSTEP_MAKEFILES`}
if test -z "$GNUSTEP_PATHLIST"; then
. ${GNUSTEP_MAKEFILES}/GNUstep.sh
fi
Yes, I think gnustep-config still needs to go a bit further and add
GNUSTEP_CFLAGS
GNUSTEP_CPPFLAGS
GNUSTEP_LDFLAGS
and possibly some more stuff
as we still need to hard code the obsoleted
-I$GNUSTEP_SYSTEM_ROOT/Library/Headers, etc
I assume this will happen when --includedir/--libdir/--bindir etc, etc
are supported as per
the TODO in common.make:264
And then, once all the variables are set, how should we write
configure
script tests? (and which variables are we allowed to use?)
Should we
1) tweak the environment to allow AC_CHECK_LIB to work?
2) create our own:
- AC_CHECK_GNUSTEP_LIBRARY
- AC_CHECK_GNUSTEP_FRAMWORK
- AC_CHECK_GNUSTEP_NATIVELIBRARY
macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES?
3) invoke 'make' with gnustep makefiles in some config subdirectory
during ./configure
4) other ideas which I may have missed?
It definately seems the autoconf way to check system capabilities
regardless of
platform, if one takes this stand AC_CHECK_NATIVELIBRARY seems out of
place
and you should call both
AC_CHECK_GNUSTEP_LIBRARY and
AC_CHECK_GNUSTEP_FRAMEWORK
I don't feel strongly either way
though about naming conflicts e.g. libInterfaceBuilder vs
InterfaceBuilder.framework
If we theoretically promote libInterfaceBuilder to a native-library
and take in to account the different ways people use GNUstep-make on
apple
a) using gnustep
b) just using gnustep-baseadd/make
theres currently no way to stop gcc from looking in
/System/Library/Frameworks etc
(well i believe there is in gcc svn) we can just add
/path/to/GNUstep/System/Library/Frameworks
to the beginning with -F option
and if its found it'll link against the GNUstep one... before looking
in system places
runtime is probably a whole other deal requiring environment variables
and stuff
but yeah 1) and 2) look good
or a combination of 1) + AC_CHECK_FRAMEWORK used to implement 2)
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Richard Frith-Macdonald wrote: On 11 Feb 2007, at 04:33, Matt Rice wrote: On 2007-02-10 17:34:59 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: The only objection i've heard from gnustep.pc is "Its not the way GNUstep stores information". Here is a refresher -- 1. it adds an external dependency upon which *everything* would depend an entirely optional dependency, people could continue sourcing GNUstep.sh. That implies that either you expect people to write makefiles which are deliberately non-portable (ie they make use of pkg-config and don't work on systems where pkg-config is not installed) or you require them to adopt some convention for having the makefile determine whether pkg-config is available, use it if is, and tell them to source GNUstep.sh if it isn't (presumably include several lines at the top of each makefile). To while it could be optional, it could not be optional in a transparent way. So Nicola's objection stands it adds a dependency, or unpleasent consequences of working round the natural dependency. No, you make GNUstep-make do this for the user. Doesn't this seem obvious? 2. it is slower -make is not a bottleneck... for example on my machine -make building base here takes 2 minutes 3 seconds... make when base is already built takes 2 seconds.. where adding this stuff to make would be 0.006th of a second per invocation of pkg-config/gnustep-config this argument is hogwash. I agree that performance is not a significant issue ... however, where we are looking at two alternative solutions providing identical benefits in all other respects, this could swing the argument. They are not identical in *all* other respects, and that's frankly the point. 3. it is designed for something else (which adds complexity) It does exactly the same thing gnustep-config.sh does. that adds no complexity... No difference in complexity of usage, but gnustep-sh parses a simpler file format and uses simpler code so is less complex / more maintainable in that sense. However I suspect the issue is pretty much unimportant. Exactly, and when it's unimportant, frankly, familiarity for newcompers should be taken into consideration. It's absolutely not being, and in fact, it's been rejected repeatedly by Nicola. I dare say you are not approaching this conversation from a rational point of view, and perhaps have too much emotional investment in make, something you care deeply about. This is an all-too-common problem with OSS developers. Take a few steps back and look at things from everyone elses' perspective, instead of trying to shoehorn your own beliefs into everyone else's perspective. Dependophobia is a treatable condition, and it's usually illogical anyways, most definitely in this case, where it's purely an optional dependency, and where most people are going to have pkgconfig on their system anyways, due to the fact that hundreds of other libs on their system already depend on it. Once again, pkgconfig is a red herring under windows. It's not needed nor is it necessary. Windows has its own mechanisms. 4. it requires rewriting and redesigning stuff with no clear advantages there are clear advantages... now I can add stuff to configure for things *using* gnustep-make which attempts to see if GNUstep libraries exist. there could be a way to bootstrap gnustep-make to "just work" without any gnustep specific environment variables. Those are not advantages of pkg-config. Those are examples of where the use of pkg-config would provide the same functionality. Early on in this thread Nicola suggested both gnustep-config.sh and the use of a makefile fragment as ways of doing the same thing, so pkg-config provides no advantage in this respect. They advantages in that many other people already know how the hell they work, and pretty much any newcomer does NOT know how this other funky system we invented works; even if it's very simple, this RAISES the barrier to entry. It does not lower it. This is why the whole dependency argument isn't as critical as some of us seem to believe it is. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Christopher Armstrong wrote: Hi I usually try to avoid playing with GNUstep on Windows as it always takes too long to setup an environment to run stuff in, but these pkg-config discussions drew me back in. Wim Oudshoorn schrieb: Well, did you actually try compiling pkg-config? I did not investigate deeply but the suggested way of compiling: ./configure make Did not work. ./configure succeeded splendidly, but make failed and the reason was that glib.h could not be found. But I don't want to start a discussion in the GNUstep mailing lists on how to install pkg-config. I just wanted to see how it would work on windows. I wanted to keep out of this discussion, but somehow these resolutions never work out :-) First of all there is a pre-compiled pkg-config for Windows on the Gimp download page, but be warned, I have not used it myself: http://www.gimp.org/~tml/gimp/win32/pkg-config-0.20.zip I started by trying to compile the glib included with pkg-config on Windows...this failed to work properly. I then tried to download the source code for glib 2.0 on Windows. Quite annoyingly, glib 2.0 depends on pkg-config, and pkg-config depends on glib, which leads to a ridiculous chicken-and-egg situation. I gave up trying to compile either of them and downloaded the binaries from gimp.org. They seem to work correctly, although I was struggling with the pkg-config files that come with all the gnuwin32 stuff (i.e. all those precompiled dependencies such as zlib, libjpeg, libtiff, libpng, etc). This is because as pkg-config hardcodes paths in its .pc files, and the .pc files distributed with gnuwin32 binaries pathnames to directories on the machines they were compiled on e.g. c:/progra~1/libiconv. Hopefully things like this can be cleaned up with a sed script. Second, I like the idea of using more standard tools in the GNUstep configuration and compilation process. pkg-config could come in rather nicely here. But I don't quite understand, how it could be used as a replacement for GNUstep.conf. Not that I like the role GNUstep.conf is currently playing in GNUstep, but this is clearly different from what pkg-config is normally doing. GNUstep.conf is a file that gets accessed each time a GNUstep application is run to find out about the various GNUstep settings. It is there to allow GNUstep installations to be moved to arbitrary places after compilation. pkf-config is by its intention a compile time tool. It looks for include paths and libraries and such stuff. It is not supposed to be around when a compiled application or libraries is run. Considering some of the effort needed to get pkg-config working on Windows, could we please maintain all existing build methods in gnustep-make? IMHO pkg-config still feels like a alpha quality programme in some environments, despite being widely used. The classic gnustep-make build environment is still my first choice and is alot easier to install as it has no unusual or difficult dependencies. If my understanding is correct, nobody is proposing that we make pkg-config required, or get rid of GNUstep.conf completely, and once again, I argue it's a bad match and relatively useless under Windows. Lastly, on a slightly unrelated note, the GNU dependencies (zlib, libpng, libjpeg, etc) that are needed to compile GNUstep on Windows can be automated using an installer from the gnuwin32.sf.net project which downloads most of the precompiled GNU environment. I was thinking that it may be possible to take the scripts given there, combine them with scripts for installing mingw/msys and create an installable mingw environment on Windows that is ready to compile source code within. Yes, that would be a great thing to have available to the community :) I've thought about doing exactly this many times myself, but unfortunately do not have the time. Are you volunteering? If not, would anyone else like to volunteer? If we don't get any responses, perhaps it would be wise to trim this particular subthread down and forward it to gnustep-discuss to see if there are any willing volunteers. Regards Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
>> Did you add your System Libraries directory and your Local Libraries >> directory to /etc/ld.so.conf ? Did you run ldconfig after installing >> any new library ? If not, it won't work. > > That's the same for lots of non-gnustep stuff too, but mostly non- > gnustep stuff seems to avoid the problem. > I suspect that many packages have their installation scripts run > ldconfig for you. > Perhaps gnustep-make could be enhanced to do that on systems where > /etc/ld.so.conf and ldconfig are available? Yes, it sounds like an excellent idea to do it automatically. :-) Main questions for discussion are -- * How we decide if we have to run ldconfig or not ? Do we need to run it only on GNU/Linux ? Are there similar tools on other unixes ? (I imagine so, so we'll have a general-purpose post-library-install target-dependent command that we run automatically) * Should we try running ldconfig only if LD_LIBRARY_PATH does not include the GNUstep libraries directories ? Or do we run it always ? * How would you disable running ldconfig automatically ? Do we add a command line flag ? Like 'make ldconfig=no' ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Feb 11, 2007, at 3:30 PM, Alex Perez wrote: there are clear advantages... now I can add stuff to configure for things *using* gnustep-make which attempts to see if GNUstep libraries exist. there could be a way to bootstrap gnustep-make to "just work" without any gnustep specific environment variables. Those are not advantages of pkg-config. Those are examples of where the use of pkg-config would provide the same functionality. Early on in this thread Nicola suggested both gnustep-config.sh and the use of a makefile fragment as ways of doing the same thing, so pkg-config provides no advantage in this respect. They advantages in that many other people already know how the hell they work, and pretty much any newcomer does NOT know how this other funky system we invented works; even if it's very simple, this RAISES the barrier to entry. It does not lower it. This is why the whole dependency argument isn't as critical as some of us seem to believe it is. That is not an advantage in this case. pkg-config main reason for being is to help find compile and link flags for linking in other libraries. It can be extended, which Matt has suggested in this case. But the extension here is just to FIND the GNUstep makefiles - and now we are just back were we started - the newcomer still has to learn how to use our 'funky' makefile system. The thing that various people have been arguing about here is, 'how do we find out various bits of meta-data about the GNUstep system?'. pkg-config is woefully inadequate for this work and doesn't even come close to covering other requirements of the make system, like compiling and linking in bundles, frameworks, palettes, etc. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Adam Fedor wrote: On Feb 11, 2007, at 3:30 PM, Alex Perez wrote: there are clear advantages... now I can add stuff to configure for things *using* gnustep-make which attempts to see if GNUstep libraries exist. there could be a way to bootstrap gnustep-make to "just work" without any gnustep specific environment variables. Those are not advantages of pkg-config. Those are examples of where the use of pkg-config would provide the same functionality. Early on in this thread Nicola suggested both gnustep-config.sh and the use of a makefile fragment as ways of doing the same thing, so pkg-config provides no advantage in this respect. They advantages in that many other people already know how the hell they work, and pretty much any newcomer does NOT know how this other funky system we invented works; even if it's very simple, this RAISES the barrier to entry. It does not lower it. This is why the whole dependency argument isn't as critical as some of us seem to believe it is. That is not an advantage in this case. pkg-config main reason for being is to help find compile and link flags for linking in other libraries. It can be extended, which Matt has suggested in this case. But the extension here is just to FIND the GNUstep makefiles - and now we are just back were we started - the newcomer still has to learn how to use our 'funky' makefile system. The thing that various people have been arguing about here is, 'how do we find out various bits of meta-data about the GNUstep system?'. pkg-config is woefully inadequate for this work and doesn't even come close to covering other requirements of the make system, like compiling and linking in bundles, frameworks, palettes, etc. The only way to work around the fact that we somehow have to find "The GNUstep Environment" is by having a script in a file system compliant place that returns what is needed. So on a Unix system place gnustep-config.sh in /usr/local/bin or /usr/bin and on Windows in /Windows/Programs (?)... etc. Dennis ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 11 Feb 2007, at 22:30, Alex Perez wrote: Richard Frith-Macdonald wrote: On 11 Feb 2007, at 04:33, Matt Rice wrote: On 2007-02-10 17:34:59 -0800 Nicola Pero <[EMAIL PROTECTED] innovation.com> wrote: The only objection i've heard from gnustep.pc is "Its not the way GNUstep stores information". Here is a refresher -- 1. it adds an external dependency upon which *everything* would depend an entirely optional dependency, people could continue sourcing GNUstep.sh. That implies that either you expect people to write makefiles which are deliberately non-portable (ie they make use of pkg- config and don't work on systems where pkg-config is not installed) or you require them to adopt some convention for having the makefile determine whether pkg-config is available, use it if is, and tell them to source GNUstep.sh if it isn't (presumably include several lines at the top of each makefile). To while it could be optional, it could not be optional in a transparent way. So Nicola's objection stands it adds a dependency, or unpleasent consequences of working round the natural dependency. No, you make GNUstep-make do this for the user. Doesn't this seem obvious? We are discussing how to find gnustep-make ... If our makefile can use gnustep-make to chose whether or not to use pkg-config to find gnustep-make, then obviously it has already found gnustep-make ... in which case there is no reason to use pkg-config to find gnustep-make. Exactly, and when it's unimportant, frankly, familiarity for newcompers should be taken into consideration. It's absolutely not being, and in fact, it's been rejected repeatedly by Nicola. I think that's a complete misrepresentation ... I think he just rejects the religious notion that familiarity is everything. That attitude leads to turning projects into clones of microsoft products (or the product used by whatever group you happen to target). I dare say you are not approaching this conversation from a rational point of view, and perhaps have too much emotional investment in make, something you care deeply about. This is an all- too-common problem with OSS developers. Take a few steps back and look at things from everyone elses' perspective, instead of trying to shoehorn your own beliefs into everyone else's perspective. Dependophobia is a treatable condition, and it's usually illogical anyways, most definitely in this case, where it's purely an optional dependency, and where most people are going to have pkgconfig on their system anyways, due to the fact that hundreds of other libs on their system already depend on it. Once again, pkgconfig is a red herring under windows. It's not needed nor is it necessary. Windows has its own mechanisms. If you look at the aim of the project you will find that it is to be a cross platform development environment. Among other things, that means that someone working on one platform should be able to use the same toolset (as much as reasonably possible) to build their application on every other platform they want to target. It's fine and good to be able to use the most popular tools on each platform, but it's fundamental to the aims of the project to be able to use a common recommended toolset across all platforms. The nature of the GNUstep project is that we must be particularly careful about portability/dependency issues. GNUstep uses the make system because it is highly portable and effective, and in this case (the ability of a makefile to automatically locate the make system and get it to run) we have an example where portability is paramount ... we need to make it as easy as possible for people to write makefiles which don't need to be changed when we try to run them on different platforms. 4. it requires rewriting and redesigning stuff with no clear advantages there are clear advantages... now I can add stuff to configure for things *using* gnustep-make which attempts to see if GNUstep libraries exist. there could be a way to bootstrap gnustep-make to "just work" without any gnustep specific environment variables. Those are not advantages of pkg-config. Those are examples of where the use of pkg-config would provide the same functionality. Early on in this thread Nicola suggested both gnustep-config.sh and the use of a makefile fragment as ways of doing the same thing, so pkg-config provides no advantage in this respect. They advantages in that many other people already know how the hell they work, and pretty much any newcomer does NOT know how this other funky system we invented works; even if it's very simple, this RAISES the barrier to entry. It does not lower it. This is why the whole dependency argument isn't as critical as some of us seem to believe it is. I put it to you that NOBODY knows how pkg-config works to locate the relevant part of gnustep-make (the topic under discussion
Re: gnustep-make experiment
On 11 Feb 2007, at 11:23, David Ayers wrote:
Nicola Pero schrieb:
I like the idea of your patch, so I rewrote the shell script and
committed it.
Minor nit... isn't gnustep-config.sh meant to be executed, not
sourced?
So shouldn't it be named gnustep-config instead of gnustep.config.sh?
I'm trying to follow this discussion but it seems that we are not
addressing the issues which /I/ thought we are trying to solve.
Watching the thread, it became clear to me that it was a confused
mess of two ideas ...
1. how to obtain information for configure et al (your idea I think)
2. how to have makefiles automatically find the make system (matt
said this was his primary issue)
So when I butted in, I explicitly/carefully addressed the two
separately ...
Hopefully issue 1 is done-to-death now, and we can just document use
of gnustep-config.sh and forget about it.
I thought the main point was to enable ./configure to test for the
existence/usability of GNUstep libraries/frameworks. So shouldn't
it be
installed in into a standard system path instead of
GNUSTEP_SYSTEM_ROOT/Tools? I would expect /usr/local/bin or whatever
--bindir is set to for configure of -make.
Yes, that was/is my understanding of what Nicola was saying about
gnustep-config.sh
So how does is help with writing configure scripts?
Maybe something like?
GNUSTEP_MAKEFILES=${GNUSTEP_MAKEFILES:=`gnustep-config
GNUSTEP_MAKEFILES`}
if test -z "$GNUSTEP_PATHLIST"; then
. ${GNUSTEP_MAKEFILES}/GNUstep.sh
fi
And then, once all the variables are set, how should we write
configure
script tests? (and which variables are we allowed to use?)
Should we
1) tweak the environment to allow AC_CHECK_LIB to work?
2) create our own:
- AC_CHECK_GNUSTEP_LIBRARY
- AC_CHECK_GNUSTEP_FRAMWORK
- AC_CHECK_GNUSTEP_NATIVELIBRARY
macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES?
3) invoke 'make' with gnustep makefiles in some config subdirectory
during ./configure
4) other ideas which I may have missed?
Note that I haven't really understood how pkg-config would be used at
this level either. But I get the feeling that we are not solving the
issues we are aiming at. But maybe I'm just confused, so I guess it
would be great if the usage of the two approaches in the context of
configure scripts could be summarized.
Well, here I feel pkg-config syntax is actually pretty good. For a
configure script using pkg-config you would use pkg-config to
determine/set the CPP/CC/LD flags before calling AC_CHECK_HEADERS and
AC_CHECK_LIB etc. I would be happy to just use pkg-config to do the
same for gnustep packages were it not for the fact that I know it
wouldn't work on the windows, apple, and sun operating systems I need
to use sometimes. It would be great if the gnustep-config.sh script
could accept the same arguments that pkg-config does, and produce the
same sort of results for gnustep packages. That's the kind of
functionality we need and a usage style familiar to users of pkg-
config (and convenient for use with the autoconf macros). Another
option is to just use pkg-config and bundle it with gnustep-make so
that the gnustep-make installation process guarantees the presence of
pgk-config, installing it if necessary. However, my suspicion is
that the maintenance overheads involved in making sure we have a pkg-
config we can use may actually be higher than those involved in
putting the functionality required into gnustep-config.sh.
Of your list of ideas ... I think
1 is obviously good,
2 i can understand having our own checks for frameworks and bundles,
but I don't understand the library/nativelibrary distinction ...
wouldn't you just use AC_CHECK_LIB?
3. OI don't really understand this one.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Richard Frith-Macdonald schrieb: > > On 11 Feb 2007, at 11:23, David Ayers wrote: > >> >> Should we >> 1) tweak the environment to allow AC_CHECK_LIB to work? >> 2) create our own: >> - AC_CHECK_GNUSTEP_LIBRARY >> - AC_CHECK_GNUSTEP_FRAMWORK >> - AC_CHECK_GNUSTEP_NATIVELIBRARY >> macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES? >> 3) invoke 'make' with gnustep makefiles in some config subdirectory >> during ./configure >> 4) other ideas which I may have missed? >> [snip] > > Of your list of ideas ... I think > 1 is obviously good, > 2 i can understand having our own checks for frameworks and bundles, > but I don't understand the library/nativelibrary distinction ... > wouldn't you just use AC_CHECK_LIB? > 3. OI don't really understand this one. Well the reason for the native library stems from the essentially obvious fact that native libraries are libraries on non-Darwin systems and frameworks on Darwin system (well unless your name is Matt and you've implemented native frameworks in GNU/Linux and GNU/Hurd ;-) ). So when /checking/ for projects that are native library projects we could duplicate -make's logic to decide to use _LIBRARY or _FRAMEWORK in every configure.ac script, or we could add the code to a macro supplied by -make that could be used by all and that would be updated in sync with -make when/if other platforms support frameworks. But I actually want to clarify what I meant with the third option for the configure issue... My goal is to have ./configure of GDL2 identify whether libGorm is installed/usable so it can decide whether the palette should be build or not. (The servers I deploy my GSWeb App on do not have X/AppKit/GORM but use GDL2 & GSWeb... currently I need to disable building the palette explicitly via configure option.) Now most configure checks like AC_CHECK_LIB work by trying to build a minimal example code snipit and link it against the library. For GNUstep we probably need a lot of the features of -make to accomplish this. So to avoid duplicating -make in new configure macros, one could imagine creating config/gorm/ subdirs which contain a minimal test.m file and a minimal GNUmakefile (or have them generated by the new macros). And then have ./configure invoke 'make' in this subdirectory to see if this minimal project can be built/linked to decide whether to set a ./configure variable or not. OT1H, I feel this might be "shooting at pigeons with canons" (is that expression used in English?), yet OTOH it might be the only reasonable approach without duplicating -make features in configure macros especially for the cross-compilation case. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 12 Feb 2007, at 11:51, David Ayers wrote: Richard Frith-Macdonald schrieb: On 11 Feb 2007, at 11:23, David Ayers wrote: Should we 1) tweak the environment to allow AC_CHECK_LIB to work? 2) create our own: - AC_CHECK_GNUSTEP_LIBRARY - AC_CHECK_GNUSTEP_FRAMWORK - AC_CHECK_GNUSTEP_NATIVELIBRARY macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES? 3) invoke 'make' with gnustep makefiles in some config subdirectory during ./configure 4) other ideas which I may have missed? [snip] Of your list of ideas ... I think 1 is obviously good, 2 i can understand having our own checks for frameworks and bundles, but I don't understand the library/nativelibrary distinction ... wouldn't you just use AC_CHECK_LIB? 3. OI don't really understand this one. Well the reason for the native library stems from the essentially obvious fact that native libraries are libraries on non-Darwin systems and frameworks on Darwin system (well unless your name is Matt and you've implemented native frameworks in GNU/Linux and GNU/Hurd ;-) ). So when /checking/ for projects that are native library projects we could duplicate -make's logic to decide to use _LIBRARY or _FRAMEWORK in every configure.ac script, or we could add the code to a macro supplied by -make that could be used by all and that would be updated in sync with -make when/if other platforms support frameworks. I see. That makes sense. I guess the ideal would be to use AC_CHECK_NATIVE_LIB everywhere, and let that macro determine whether we are dealing with a library or a framework and set the flags accordingly? That sounds live a very useful facility to have. But I actually want to clarify what I meant with the third option for the configure issue... My goal is to have ./configure of GDL2 identify whether libGorm is installed/usable so it can decide whether the palette should be build or not. (The servers I deploy my GSWeb App on do not have X/AppKit/GORM but use GDL2 & GSWeb... currently I need to disable building the palette explicitly via configure option.) Now most configure checks like AC_CHECK_LIB work by trying to build a minimal example code snipit and link it against the library. For GNUstep we probably need a lot of the features of -make to accomplish this. So to avoid duplicating -make in new configure macros, one could imagine creating config/gorm/ subdirs which contain a minimal test.m file and a minimal GNUmakefile (or have them generated by the new macros). And then have ./configure invoke 'make' in this subdirectory to see if this minimal project can be built/linked to decide whether to set a ./configure variable or not. Right ... that's clear now, thanks. It sounds like a very reliable approach ... and is consistent with the way autoconf/configure tends to work (ie by actually checking that something works rather than simply querying a database of information). OT1H, I feel this might be "shooting at pigeons with canons" (is that expression used in English?), yet OTOH it might be the only reasonable approach without duplicating -make features in configure macros especially for the cross-compilation case. I'm not familiar with the phrase, but I suspect it's equivalent to 'using a sledgehammer to crack a nut' I agree ... that it sounds like doing a lot of work to get a little information, but gnustep-make is fast, so i don't think it would be much slower than what autoconf macros already do in similar cases. Unless someone comes up with a better idea, I like yours. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Hi On Sun, 11 Feb 2007 14:51:39 -0800, "Alex Perez" <[EMAIL PROTECTED]> said: > > Lastly, on a slightly unrelated note, the GNU dependencies (zlib, > > libpng, libjpeg, etc) that are needed to compile GNUstep on Windows can > > be automated using an installer from the gnuwin32.sf.net project which > > downloads most of the precompiled GNU environment. I was thinking that > > it may be possible to take the scripts given there, combine them with > > scripts for installing mingw/msys and create an installable mingw > > environment on Windows that is ready to compile source code within. > > Yes, that would be a great thing to have available to the community :) > I've thought about doing exactly this many times myself, but > unfortunately do not have the time. Are you volunteering? If not, would > anyone else like to volunteer? If we don't get any responses, perhaps it > would be wise to trim this particular subthread down and forward it to > gnustep-discuss to see if there are any willing volunteers. Whilst I would love to volunteer to do this I'm really pressed for time at the moment, and when university resumes I will be even more pressed for time, so much so that I am unable to do any serious work on GNUstep. Please feel free to forward the idea to the gnustep-discuss list and see if anyone's up for it. From what I can work out, it could be done with a series of batch files and an installer programme. The gnuwin32 project actually includes some utilities like sed, grep and wget in its installer to locate and download all the latest versions of the binaries. MINGW currently uses a binary installer which is likely to be a InstallShield style install-programme builder kind of thing. Regards Chris -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 12 Feb 2007, at 12:29, Christopher Armstrong wrote: Hi On Sun, 11 Feb 2007 14:51:39 -0800, "Alex Perez" <[EMAIL PROTECTED]> said: Lastly, on a slightly unrelated note, the GNU dependencies (zlib, libpng, libjpeg, etc) that are needed to compile GNUstep on Windows can be automated using an installer from the gnuwin32.sf.net project which downloads most of the precompiled GNU environment. I was thinking that it may be possible to take the scripts given there, combine them with scripts for installing mingw/msys and create an installable mingw environment on Windows that is ready to compile source code within. Yes, that would be a great thing to have available to the community :) I've thought about doing exactly this many times myself, but unfortunately do not have the time. Are you volunteering? If not, would anyone else like to volunteer? If we don't get any responses, perhaps it would be wise to trim this particular subthread down and forward it to gnustep-discuss to see if there are any willing volunteers. Whilst I would love to volunteer to do this I'm really pressed for time at the moment, and when university resumes I will be even more pressed for time, so much so that I am unable to do any serious work on GNUstep. Please feel free to forward the idea to the gnustep-discuss list and see if anyone's up for it. From what I can work out, it could be done with a series of batch files and an installer programme. The gnuwin32 project actually includes some utilities like sed, grep and wget in its installer to locate and download all the latest versions of the binaries. MINGW currently uses a binary installer which is likely to be a InstallShield style install-programme builder kind of thing. Someone (a few weeks ago) suggested using WiX ... apparently the windows standard installer stuff. I had a look at it and it seems to have the advantage of being xml data fie driven, so might be relatively easy to automate. I haven't actually had time to try it though. It would be nice to use the most 'standard' windows mechanism we can (unless it's unbearably awful). Maybe the gnuwin32 project wraps WiX? Maybe it does something similar but better? Anyway, I'd really love to see three things for windows. 1. an installer that installs all the required binaries and gnustep core (and something to automatically rebuild this installer) 2. an installer that installs the mingw development tools and all our headers etc (and something to automatically rebuild it) 3. an extension to gnustep-make to generate installer packages for anything we build with gnustep-make. So a developer would install (2), which would automatically install (1) as well They would build their application and then do something like 'make windowspkg' ... generating an installer package for their application A user would download the application installer package and run it, and it would install (1) and the application I don't know if WiX and similar installer systems are able to automatically download and install dependencies ... if not, it might be worth looking for something which does support that capability. There are few things more irritating than getting part way through an installation and finding out that you need to locate and download something else, then doing that and finding out that it depends on yet another thing ... However, even if we can't automate download/install of dependencies, it would still be great to have something built into the gnustep core to generate windows installer packages. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Feb 11, 2007, at 9:16 PM, Nicola Pero wrote: * How we decide if we have to run ldconfig or not ? Do we need to run it only on GNU/Linux ? Are there similar tools on other unixes ? (I imagine so, so we'll have a general-purpose post- library-install target-dependent command that we run automatically) I'm pretty sure even libtool doesn't do that. It prints out a big warning about having to add the paths to your ld.conf yourself. I'd feel uncomfortable having something automatically mess with a system file that could potential make the system unusable (however remotely). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
>> * How we decide if we have to run ldconfig or not ? Do we need to >> run it only on GNU/Linux ? Are there similar tools on other >> unixes ? (I imagine so, so we'll have a general-purpose post- >> library-install target-dependent command that we run automatically) > > I'm pretty sure even libtool doesn't do that. It prints out a big > warning about having to add the paths to your ld.conf yourself. Yes > I'd feel uncomfortable having something automatically mess with a system > file that could potential make the system unusable (however remotely). That's a good point - yes, ldconfig might generate issues. ;-) I suppose the right thing to do is printing a warning too then! ;-) Do we print it only on Linux ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 12 Feb 2007, at 15:51, Nicola Pero wrote: * How we decide if we have to run ldconfig or not ? Do we need to run it only on GNU/Linux ? Are there similar tools on other unixes ? (I imagine so, so we'll have a general-purpose post- library-install target-dependent command that we run automatically) I'm pretty sure even libtool doesn't do that. It prints out a big warning about having to add the paths to your ld.conf yourself. Yes I'd feel uncomfortable having something automatically mess with a system file that could potential make the system unusable (however remotely). That's a good point - yes, ldconfig might generate issues. ;-) I suppose the right thing to do is printing a warning too then! ;-) Do we print it only on Linux ? I agree that the point about not messing with system files is good ... but I never meant that we should do that without asking. What I really had in mind was something like this ... 1. determine what system we are installing on and do something specific to the system type as below. 2. check to see if we need to add a path to /etc/ld.so.conf, If we do, print out a message explaining and ask the user if they want us to add the path for them. If they say yes, explain that we will try using sudo/su and they will need to enter a password ... 3. Check to see if we need to rerun /sbin/ldconfig, If we do, print out a message to explain and ask the user if they want us to do it. If they say yes, run it if it's s-bit set, otherwise go through the su/sudo thing again ... Obviously stages 2 and 3 would vary from system to system and we don't have to implement everything at once ... on a system where we don't know what to do, we could just print out a message explaining the issue and telling the user they need to sort things out and we would appreciate contribution of code to do it automatically. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> IIRC we had some extensive discussions on the mailing lists that > .sh/.csh should only be used for scripts that are sourced. But since > GNUStep.sh is referenced so often in the archives, I'm having a hard > time finding the discussion. I don't remember that discussion, but it's plain obvious that gnustep-make is not following that convention! There are lot of .sh files in gnustep-make that are not supposed to be sourced (eg, clean_cpu.sh, clean_os.sh, fixpath.sh, etc). We could change gnustep-make to follow the convention though if it can be argued that it is a good one - most of the scripts are only used internally in gnustep-make, so we should be able to rename them fairly easily. :-) Anyway, for a start I did change gnustep-config.sh to be gnustep-config. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Thanks ... good points. I like the idea of doing it automatically only if the user wants it, but I'm (personally) not too keen on having scripts that try to talk to the user and that require attention. Maybe we could just print a warning at the end of compilation, saying "Important: you may need to run ldconfig for your installed libraries to work. Tip: If you want gnustep-make to do it automatically for you, please use the command 'make install ldconfig=yes'." Then if you want gnustep-make to always do it for you (I will be one of those when I'm not testing crazy setups) you can just add ldconfig=yes to your environment ... Thanks -Original Message- From: Richard Frith-Macdonald <[EMAIL PROTECTED]> Sent: Mon, February 12, 2007 5:32 pm To: [EMAIL PROTECTED] Cc: Adam Fedor <[EMAIL PROTECTED]>, Developer GNUstep Subject: Re: gnustep-make experiment On 12 Feb 2007, at 15:51, Nicola Pero wrote: > >>> * How we decide if we have to run ldconfig or not ? Do we need to >>> run it only on GNU/Linux ? Are there similar tools on other >>> unixes ? (I imagine so, so we'll have a general-purpose post- >>> library-install target-dependent command that we run automatically) >> >> I'm pretty sure even libtool doesn't do that. It prints out a big >> warning about having to add the paths to your ld.conf yourself. > > Yes > > >> I'd feel uncomfortable having something automatically mess with a >> system >> file that could potential make the system unusable (however >> remotely). > > That's a good point - yes, ldconfig might generate issues. ;-) > > I suppose the right thing to do is printing a warning too then! ;-) > > Do we print it only on Linux ? I agree that the point about not messing with system files is good ... but I never meant that we should do that without asking. What I really had in mind was something like this ... 1. determine what system we are installing on and do something specific to the system type as below. 2. check to see if we need to add a path to /etc/ld.so.conf, If we do, print out a message explaining and ask the user if they want us to add the path for them. If they say yes, explain that we will try using sudo/su and they will need to enter a password ... 3. Check to see if we need to rerun /sbin/ldconfig, If we do, print out a message to explain and ask the user if they want us to do it. If they say yes, run it if it's s-bit set, otherwise go through the su/sudo thing again ... Obviously stages 2 and 3 would vary from system to system and we don't have to implement everything at once ... on a system where we don't know what to do, we could just print out a message explaining the issue and telling the user they need to sort things out and we would appreciate contribution of code to do it automatically. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> But I actually want to clarify what I meant with the third option for > the configure issue... My goal is to have ./configure of GDL2 identify > whether libGorm is installed/usable so it can decide whether the palette > should be build or not. > > (The servers I deploy my GSWeb App on do not have X/AppKit/GORM but use > GDL2 & GSWeb... currently I need to disable building the palette > explicitly via configure option.) I agree with Matt and others that we want to have gnustep-config able to output compile/link flags. I have a plan in mind for that. :-) But in your case, what about some makefile variable/function that lets you check if a gnustep library is installed or not ? We could add to gnustep-make a GNUSTEP_FIND_LIBRARY and GNUSTEP_FIND_FRAMEWORK functions, that would return the location of a GNUstep library/framework, or nothing if they don't exist. Then in your GNUmakefile you could just do ifneq ($(call GNUSTEP_FIND_LIBRARY, Gorm)$(call GNUSTEP_FIND_FRAMEWORK, Gorm),) SUBPROJECTS += GormPalette fi to compile your GormPallette iff libGorm.so (or Gorm.framework) is installed, without even needing the configure step. :-) Thanks NB: Here is an example GNUSTEP_FIND_LIBRARY implementation for you to test with -- GNUSTEP_FIND_LIBRARY = $(strip $(wildcard $(addsuffix $(strip $(1)).so, \ $(GNUSTEP_SYSTEM_ROOT)/Library/Libraries/lib \ $(GNUSTEP_LOCAL_ROOT)/Library/Libraries/lib \ $(GNUSTEP_NETWORK_ROOT)/Library/Libraries/lib \ $(GNUSTEP_USER_ROOT)/Library/Libraries/lib))) It would be defined inside gnustep-make though, so it will get automatically updated for the filesystem changes. You call it, and gnustep-make will make sure to look in the right library locations. PS: We could do this with standard variables (rather than functions), but functions have a more familiar syntax, and it looks like all GNU makes in the last 5 years or so support them, so we should probably start using them. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
(discussion about how to get the compile/link flags out of gnustep-make) > That's the kind of functionality we need and a usage style familiar to users > of pkg-config (and convenient for use with the autoconf macros). Another > option is to just use pkg-config and bundle it with gnustep-make so > that the gnustep-make installation process guarantees the presence of > pgk-config, installing it if necessary. pkg-config works best if compile/link flags are fixed and listed in a file. The compile/link flags in gnustep-make are determined dynamically instead, they are not fixed. You can have non-flattened multi-platform installations that are mounted from the network; the same gnustep-make will then use different compilation flags/tools for the different hosts (keep in mind that each host might also have a different filesystem configuration, eg, they could be sharing a network-mounted System domain, while having different domains in different locations). Or, more commonly, even in a flattened system, each user can organize their own user domain however they want, and control it via the GNUstep user config file (that's great for testing various versions of your own GNUstep lib/app without messing up your system). So, every user should get a different list of -I and -L flags to lookup things in their user domain - in whatever way it is currently configured in their user config file. That's for the general flags to compile/link a tool or an application, which are the only ones which are not trivial; all the other flags are trivial (that is, -llibrary to link against library) and to get them you don't need pkg-config and you don't need gnustep-make. The easier way to have gnustep-config output the right flags that you should use for compiling/linking a tool against gnustep-base/gnustep-gui seems to be to have gnustep-config do a quick gnustep-make run in the background asking it to determine the right flags, and return them. That's my current plan. I don't see any easy solution with pkg-config unless we rewrite large parts of gnustep-make. If the syntax of gnustep-config is reasonably similar to the pkg-config one, there shouldn't be much difference though. :-) Thanks PS: Building a bundle or a framework (or even an app) will always be very troublesome without gnustep-make because it's not just a matter of a couple of compile/link flags. I think what we hope to achieve is something more limited, which is that you can easily get the flags to compile an ObjC file and to link a program against gnustep-base and gnustep-gui. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Nicola Pero schrieb: >>But I actually want to clarify what I meant with the third option for >>the configure issue... My goal is to have ./configure of GDL2 identify >>whether libGorm is installed/usable so it can decide whether the palette >>should be build or not. >> >>(The servers I deploy my GSWeb App on do not have X/AppKit/GORM but use >>GDL2 & GSWeb... currently I need to disable building the palette >>explicitly via configure option.) > > > I agree with Matt and others that we want to have gnustep-config able to > output compile/link flags. I have a plan in mind for that. :-) > > But in your case, what about some makefile variable/function that lets you > check if a gnustep library is installed or not ? > > We could add to gnustep-make a > > GNUSTEP_FIND_LIBRARY > > and > > GNUSTEP_FIND_FRAMEWORK > > functions, that would return the location of a GNUstep library/framework, or > nothing if they don't exist. > > Then in your GNUmakefile you could just do > > ifneq ($(call GNUSTEP_FIND_LIBRARY, Gorm)$(call GNUSTEP_FIND_FRAMEWORK, > Gorm),) > SUBPROJECTS += GormPalette > fi > > to compile your GormPallette iff libGorm.so (or Gorm.framework) is installed, > without even needing the configure step. :-) > > Thanks > > > NB: Here is an example GNUSTEP_FIND_LIBRARY implementation for you to test > with -- > > GNUSTEP_FIND_LIBRARY = $(strip $(wildcard $(addsuffix $(strip $(1)).so, \ > $(GNUSTEP_SYSTEM_ROOT)/Library/Libraries/lib \ > $(GNUSTEP_LOCAL_ROOT)/Library/Libraries/lib \ > $(GNUSTEP_NETWORK_ROOT)/Library/Libraries/lib \ > $(GNUSTEP_USER_ROOT)/Library/Libraries/lib))) > > It would be defined inside gnustep-make though, so it will get automatically > updated for the filesystem changes. You call it, and gnustep-make will make > sure > to look in the right library locations. > > PS: We could do this with standard variables (rather than functions), but > functions > have a more familiar syntax, and it looks like all GNU makes in the last 5 > years or so > support them, so we should probably start using them. Well I guess the approach would work but - the variables still need to take into account the non-flattened configuration (not sure show to do that with the variable approach without duplicating the block) and - this search would be executed for /every/ make invocation instead of once during configure. But I see that other projects that don't yet already need ./configure for other purposes like GDL2 would profit from this approach. Also I think the order should be according to precedence i.e. GNUSTEP_FIND_LIBRARY = $(strip $(wildcard $(addsuffix $(strip $(1)).so, \ $(GNUSTEP_USER_ROOT)/Library/Libraries/lib \ $(GNUSTEP_LOCAL_ROOT)/Library/Libraries/lib \ $(GNUSTEP_NETWORK_ROOT)/Library/Libraries/lib \ $(GNUSTEP_SYSTEM_ROOT)/Library/Libraries/lib))) So, do you have suggestion on how to handle the LIBRARY_COMBO/GNUSTEP_TARGET_DIR or will it be function approach? Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
David Ayers schrieb: > Also I think the order should be according to precedence i.e. > > GNUSTEP_FIND_LIBRARY = $(strip $(wildcard $(addsuffix $(strip $(1)).so, \ > $(GNUSTEP_USER_ROOT)/Library/Libraries/lib \ > $(GNUSTEP_LOCAL_ROOT)/Library/Libraries/lib \ > $(GNUSTEP_NETWORK_ROOT)/Library/Libraries/lib \ > $(GNUSTEP_SYSTEM_ROOT)/Library/Libraries/lib))) Actually that's moot... it doesn't matter where it is found or if it's found multiple times. It will be linked according to precedence independent of what's in the variable. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> - this search would be executed for /every/ make invocation instead of > once during configure. It would be really slow if we were trying to compile something against the library for every make invocation. Subprocesses are very slow, and the compiler is particularly slow. :-/ But if we're just checking if 4 or 10 files exist, that's a completely different operation -- that is a fast operation. Reading very little data from disk becomes unmeasurably fast very quickly ... reading the information from disk will be really fast the first time it's done; subsequent checks will hit the OS cache and the disk won't even spin, so it takes almost zero time. :-) The general rule of thumb for makefile performance is: * forking a subprocess is slow * reading a small file is reasonably fast * checking if a file exist is really fast The reason that reading is usually fast is that it can benefit from caching. ;-) > But I see that other projects that don't yet already need ./configure > for other purposes like GDL2 would profit from this approach. > > [...] > > So, do you have suggestion on how to handle the > LIBRARY_COMBO/GNUSTEP_TARGET_DIR or will it be function approach? The actual function would need to be defined inside common.make and the list of paths that are searched will mirror exactly the list of -L flags that we build in there. It will be easy to keep them in sync since they are defined in the same place. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-12 10:30:57 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: pkg-config works best if compile/link flags are fixed and listed in a file. The compile/link flags in gnustep-make are determined dynamically instead, they are not fixed. This is possible with pkg-config, you can reference external variables with --define-variable=foo=bar so you could pass the architecture in from gnustep-make. You can have non-flattened multi-platform installations that are mounted from the network; the same gnustep-make will then use different compilation flags/tools for the different hosts (keep in mind that each host might also have a different filesystem configuration, eg, they could be sharing a network-mounted System domain, while having different domains in different locations). this is also possible if you split up the .pc files one for each domain configuration then the different hosts can configure their PKG_CONFIG_PATH's to different search orders so each machine/user gets different configurations for different. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
>> You can have non-flattened multi-platform installations that are >> mounted from >> the network; the same gnustep-make will then use different >> compilation >> flags/tools for the different hosts (keep in mind that each host >> might also >> have a different >> filesystem configuration, eg, they could be sharing a network-mounted >> System >> domain, >> while having different domains in different locations). > > this is also possible if you split up the .pc files one for each > domain configuration > then the different hosts can configure their PKG_CONFIG_PATH's to > different search orders so each machine/user gets different > configurations for different. What I was trying to explain is that pkg-config only prints a set of fixed flags from a text file. But that's the very easy bit! ;-) The hard part in the implementation is actually getting the flags. The only easy way I can think of doing that is by having a quick gnustep-make run with some special targets that just print the values. This can be embedded into a gnustep-config script, since we are free to put whatever shell code we want into gnustep-config. :-) So, in all cases we need to have a gnustep-config script that outputs the flags, and implemented as explained (that script will also work on all platforms). I suppose using this gnustep-config script you could then generate .pc files and put them somewhere ... so people can use pkg-config instead of gnustep-config to print the flags on Linux. ;-) I can't see why they would want to do that though, as the tools could have a similar syntax, but gnustep-config would be automatically available everywhere gnustep-make is, while pkg-config wouldn't. So anyone who understands what they are doing will always want to use gnustep-config for portability. ;-) This is not because of some evil prejudice against pkg-config, it's just that the building system we have works in a different way. Getting the compile/link flags so that you're able to compile/link things without using gnustep-make is certainly something we want to be able to support, but the fact that pkg-config can print flags reading from a text file doesn't really help in getting there. Because we don't even store fixed sets of flags, but we compute them dynamically, using pkg-config to print them is more of an additional problem than a solution. And then adding an external dependency - which is a massive pain for users, developers and maintainers - just to do the equivalent of 'echo $CFLAGS' is somehow hardly attractive. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Tue, Feb 13, 2007 at 03:59:06AM +0100, Nicola Pero wrote: > And then adding an external dependency - which is a massive pain for > users, developers and maintainers - just to do the equivalent of 'echo > $CFLAGS' is somehow hardly attractive. An extra dependency here is not an issue, especially considering the widespread use of pkg-config. I'm still scratching my head here figuring out why it is so often claimed an issue throughout this thread when most people will already have this on their system. - Andy -- Andrew Ruder <[EMAIL PROTECTED]> http://www.aeruder.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-02-12 18:59:06 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: Because we don't even store fixed sets of flags, but we compute them dynamically, using pkg-config to print them is more of an additional problem than a solution. I forget exactly how non-flattend looks having not used it since the default changed... but heres an example of a dynamic -L for a specific architecture $ pkg-config --define-variable=host_os=linux-gnu --define-variable=host_cpu=ix86 --libs-only-L gnustep -L/System/Library/Libraries/linux-gnu/ix86 -L/Local/Library/Libraries/linux-gnu/ix86 because it is only a file, is a benefit because it forces you to keep your logic separated from all the flags. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
>> Because we don't even store fixed sets of flags, but we compute them >> dynamically, >> using pkg-config to print them is more of an additional problem >> than a solution. > > I forget exactly how non-flattend looks having not used it since the > default changed... > > but heres an example of a dynamic -L for a specific architecture > > $ pkg-config --define-variable=host_os=linux-gnu > --define-variable=host_cpu=ix86 --libs-only-L gnustep > -L/System/Library/Libraries/linux-gnu/ix86 > -L/Local/Library/Libraries/linux-gnu/ix86 > > because it is only a file, is a benefit because it forces you to keep > your logic separated from all the flags. I think I'm wasting my time answering this question. Is it even a question ? Where exactly would we be using pkg-config ? Put forward a proposal and we discuss. It seems you're just trying to prove that pkg-config can print out some text from a text file, replacing variables. Who cares ? Why is it relevant ? Compile/link flags can be just anything on different machines. Try gnustep-make on different machines (Windows cygwin/mingw32, Apple, Linux, Solaris, *BSD, etc) and you'll see completely different flags. Thanks PS: And you're missing my all important -L/home/nicola/GNUstep-test-4/Library/Libraries flag that is required to find my locally hacked Renaissance. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Feb 12, 2007, at 8:19 PM, Andrew Ruder wrote: An extra dependency here is not an issue, especially considering the widespread use of pkg-config. I'm still scratching my head here figuring out why it is so often claimed an issue throughout this thread when most people will already have this on their system. Think of it also as a dependancy of something we need to support. GNUstep make in particular has all kinds of these dependancies, many of which don't work now because no one uses them anymore. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 13 Feb 2007, at 03:19, Andrew Ruder wrote: On Tue, Feb 13, 2007 at 03:59:06AM +0100, Nicola Pero wrote: And then adding an external dependency - which is a massive pain for users, developers and maintainers - just to do the equivalent of 'echo $CFLAGS' is somehow hardly attractive. An extra dependency here is not an issue, especially considering the widespread use of pkg-config. I'm still scratching my head here figuring out why it is so often claimed an issue throughout this thread when most people will already have this on their system. An extra dependency most emphatically IS an issue ... because the 'people' you are referring to actually just means 'you', and you are just guessing about other users, and even assuming that 'most' is actually the case, then what you are proposing is to have something that only works for 'most', not for all. Is your guess that 'most' is 55%, 70%, 95%? At what point is the remaining 45%, 30%, 5% sufficiently small a minority that they become a non-issue? GNUstep is supposed to be a cross-platform development system, and anyone who actually does cross platform development would hit a problem with pkg-config. Dependency issues do not rule out using things (indeed, GNUstep has plenty of dependencies), but they are a big factor to consider, and only appear minor to the people they don't happen to effect, so when adding a dependency we need to be clear that what we are adding has overwhelming advantages over the alternatives. While pkg-config is quite nice (and looking at it provides inspiration), it has no such advantages. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 12 Feb 2007, at 16:47, Nicola Pero wrote: IIRC we had some extensive discussions on the mailing lists that .sh/.csh should only be used for scripts that are sourced. But since GNUStep.sh is referenced so often in the archives, I'm having a hard time finding the discussion. I don't remember that discussion, but it's plain obvious that gnustep-make is not following that convention! There are lot of .sh files in gnustep-make that are not supposed to be sourced (eg, clean_cpu.sh, clean_os.sh, fixpath.sh, etc). We could change gnustep-make to follow the convention though if it can be argued that it is a good one - most of the scripts are only used internally in gnustep-make, so we should be able to rename them fairly easily. :-) Anyway, for a start I did change gnustep-config.sh to be gnustep- config. I don't remember that discussion either ... perhaps it was on another mailing list or a private email converstion? To the best of my knowledge, the standard convention is that a '.sh' extension indicates a shell script and that implies no distinction between one intended to be sourced and one intended to be executed. The distinction between a script intended to be executed and one intended to be sourced is normally made by file permissions ... one is made readable and executable but the other is made read only. Incidentally, GNUstep.sh has the wrong permissions (0755 rather than 0111) when installed by default on my system. On unix-like systems, the '#!/bin/sh' at the start of a script is enough to ensure that the script is executed properly when simply run. However, the '.sh' extension is important if you expect people to interpret a script with a specific shell (eg. they know to do 'sh foo.sh' rather than 'csh foo.sh'). So, if some discussion concluded that we should create a new convention to distinguish between executable and sourceable scripts by whether there is an extension or not ... I think it was wrong. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Richard Frith-Macdonald schrieb: > > On 12 Feb 2007, at 16:47, Nicola Pero wrote: > >> >>> IIRC we had some extensive discussions on the mailing lists that >>> .sh/.csh should only be used for scripts that are sourced. But since >>> GNUStep.sh is referenced so often in the archives, I'm having a hard >>> time finding the discussion. >> >> >> I don't remember that discussion, but it's plain obvious that >> gnustep-make is >> not following that convention! There are lot of .sh files in >> gnustep-make >> that are not supposed to be sourced (eg, clean_cpu.sh, clean_os.sh, >> fixpath.sh, >> etc). >> >> We could change gnustep-make to follow the convention though if it >> can be argued that >> it is a good one - most of the scripts are only used internally in >> gnustep-make, >> so we should be able to rename them fairly easily. :-) >> >> Anyway, for a start I did change gnustep-config.sh to be gnustep- config. > > > I don't remember that discussion either ... perhaps it was on another > mailing list or a private email converstion? I'll try to find it. Please give me a bit. > To the best of my knowledge, the standard convention is that a '.sh' > extension indicates a shell script and that implies no distinction > between one intended to be sourced and one intended to be executed. > > The distinction between a script intended to be executed and one > intended to be sourced is normally made by file permissions ... one is > made readable and executable but the other is made read only. > Incidentally, GNUstep.sh has the wrong permissions (0755 rather than > 0111) when installed by default on my system. > > On unix-like systems, the '#!/bin/sh' at the start of a script is > enough to ensure that the script is executed properly when simply run. > However, the '.sh' extension is important if you expect people to > interpret a script with a specific shell (eg. they know to do 'sh > foo.sh' rather than 'csh foo.sh'). > > So, if some discussion concluded that we should create a new convention > to distinguish between executable and sourceable scripts by whether > there is an extension or not ... I think it was wrong. [EMAIL PROTECTED]: /usr/local/src/svn/gnustep/projects/make$ locate -- '-config'|grep config$|grep bin|xargs file /usr/bin/aalib-config: Bourne shell script text executable /usr/bin/apr-config: Bourne shell script text executable /usr/bin/apt-config: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped /usr/bin/apu-config: Bourne shell script text executable /usr/bin/artsc-config: Bourne shell script text executable /usr/bin/audiofile-config: Bourne shell script text executable /usr/bin/autoopts-config: Bourne shell script text executable /usr/bin/cups-config: Bourne shell script text executable /usr/bin/esd-config: Bourne shell script text executable /usr/bin/ffmpeg-config:Bourne shell script text executable /usr/bin/freetype-config: Bourne shell script text executable /usr/bin/gnucash-config: Bourne shell script text executable /usr/bin/gpg-error-config: Bourne shell script text executable /usr/bin/guile-1.6-config: a /usr/bin/guile \ script text executable /usr/bin/guile-config: symbolic link to `/etc/alternatives/guile-config' /usr/bin/imlib-config: Bourne shell script text executable /usr/bin/kde-config: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped /usr/bin/libart2-config: Bourne shell script text executable /usr/bin/libgcrypt-config: Bourne shell script text executable /usr/bin/libgnutls-config: Bourne shell script text executable /usr/bin/libgnutls-extra-config: Bourne shell script text executable /usr/bin/libpng-config:symbolic link to `libpng12-config' /usr/bin/libpng12-config: Bourne shell script text executable /usr/bin/libpq3-config:symbolic link to `../lib/postgresql/bin/libpq3-config' /usr/bin/libtasn1-config: Bourne shell script text executable /usr/bin/opencdk-config: Bourne shell script text executable /usr/bin/pcre-config: Bourne shell script text executable /usr/bin/pkg-config: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped /usr/bin/scrollkeeper-config: Bourne shell script text executable /usr/bin/sdl-config: Bourne shell script text executable /usr/bin/xml2-config: Bourne shell script text executable /usr/bin/xslt-config: Bourne shell script text executable
Re: gnustep-make experiment
On 13 Feb 2007, at 11:36, David Ayers wrote: I fear we would be starting a new convention by using .sh, but I'm sure we would get more discussion on conventions if take this to [EMAIL PROTECTED] I didn't mean to imply that use of a '.sh' suffix is in any way universal. My point what that where '.sh' is used, it indicates that you have a shell script of some sort, not that you have a file which should be sourced. If you use a search engine to look up something like ',sh file extension', I'm pretty sure you will quickly find a some places telling you that it denotes a shell script, and also pretty sure you won't easily find anything saying that a .sh extension denotes a file which should be sourced by a shell ... except perhaps this mailing list :-) So a '.sh' extension is IMO fine for both purposes and required for neither. What I want to forestall is the idea that we *should* start trying to enforce a new convention about using/not-using a .sh extension, when practically nobody else uses it and where there is a perfectly good convention (file permission) which already provides the distinction required. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
