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
> 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
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
Fwd: emacs.app does not support -GSFilePath
Hello, Someone was asking me about whether Emacs.app supports the "- GSFilePath" option which GWorkspace uses to tell applications to open files. I thought that there were already two ways to do this in OpenStep / Cocoa: "-NSOpen" option, and NSApplication- application:openFIle: method via DO or notifications. Is this correct or is the GNUstep-specific -GSFilePath really needed? thanks, Adrian ___ 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
> 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: Duplicate Member in NSMenuItemCell.h
Ted Howard schrieb: > When I try to compile gui from the trunk, I get a duplicate member error > in NSMenuItemCell.h on _backgroundColor. > > Upon looking at the code, I noticed that NSButtonCell was recently > modified to include a _backgroundColor member. Since NSMenuItemCell > extends NSButtonCell, the _backgroundColor member of NSMenuItemCell > should be removed. > > I tried this on my machine, and it seems to work fine. I have attached > a patch that does this. This problem is interesting, as I did not get it reported by my gcc. I had noticed it myself before, but as gcc did accept my code without a warning I thought it wont pose a problem to anyone. So I thought, that I could address it later on, when in my progress of adding MacOS 10.4 methods to each class I ever would reach this one. I will correct this tomorrow, removing all references to the ivar in NSMenuItemCell, which never had been needed there at all. Cheers, Fred ___ 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
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: FAM based fswatcher - first try
On Wed, Jan 24, 2007 at 09:27:05PM +0200, Enrico Sersale wrote: > The original fswatcher doesn't create a new Watcher object if there already > is one for a path beeing added; it adds only a "listener", that is, it > increments a counter. When, removing all listeners, the counter becomes 0, > the Watcher object is removed from the watchers array. In this case, a Watcher keeps a NSCountedSet of clients/listeners. If you call fswatcher 10 times with the same path, a single watcher (with a single FAM request) will be created, modulo bugs of course. > '--daemon' is not intended to be used from the command line; it is only an > internal way to create a daemon using only NSTask instead of fork(); many > GNUstep daemons does this; gdnc, gpbs, etc. Ok, thanks for the explanation. Philippe -- Always think of something new; this helps you forget your last rotten idea. Seth Frankel ___ 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: FAM based fswatcher - first try
On 2007-01-24 19:05:01 +0200 Philippe Roussel <[EMAIL PROTECTED]> wrote: Hi all You will find attached a implementation of fswatcher using the FAM API. It should link either with FAM (1) or gamin (2), which are available on different flavors of unix. The goal is to take advantage of existing facilities and getting rid of timers. FAM and gamin use kernel helpers to avoid polling when they can. The code probably has some bugs and I'm not sure I followed exactly the different notifications semantics but it's a start. I tested it with GWorkspace and it seems to work well. Opinions ? The original fswatcher doesn't create a new Watcher object if there already is one for a path beeing added; it adds only a "listener", that is, it increments a counter. When, removing all listeners, the counter becomes 0, the Watcher object is removed from the watchers array. Philippe NB : fswatcher parameter '--daemon' results in the opposite, or I am missing something ? '--daemon' is not intended to be used from the command line; it is only an internal way to create a daemon using only NSTask instead of fork(); many GNUstep daemons does this; gdnc, gpbs, etc. 1 - http://oss.sgi.com/projects/fam/ 2 - http://www.gnome.org/~veillard/gamin/ ___ 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
> 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
> 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
FAM based fswatcher - first try
Hi all You will find attached a implementation of fswatcher using the FAM API. It should link either with FAM (1) or gamin (2), which are available on different flavors of unix. The goal is to take advantage of existing facilities and getting rid of timers. FAM and gamin use kernel helpers to avoid polling when they can. The code probably has some bugs and I'm not sure I followed exactly the different notifications semantics but it's a start. I tested it with GWorkspace and it seems to work well. Opinions ? Philippe NB : fswatcher parameter '--daemon' results in the opposite, or I am missing something ? 1 - http://oss.sgi.com/projects/fam/ 2 - http://www.gnome.org/~veillard/gamin/ -- The power of accurate observation is frequently called cynicism by those who don't have it. George Bernard Shaw fswatcher-fam-0.5.tar.gz Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Duplicate Member in NSMenuItemCell.h
When I try to compile gui from the trunk, I get a duplicate member error in NSMenuItemCell.h on _backgroundColor. Upon looking at the code, I noticed that NSButtonCell was recently modified to include a _backgroundColor member. Since NSMenuItemCell extends NSButtonCell, the _backgroundColor member of NSMenuItemCell should be removed. I tried this on my machine, and it seems to work fine. I have attached a patch that does this. Ted NSMenuItemCell-duplicate_backgroundColor.patch Description: Binary data ___ 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
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
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 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
> 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
GNUstep Testfarm Results
Test results for GNUstep as of Wed Jan 24 06:34:16 EST 2007 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to be a part of this automated testfarm, see http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F Fail Compile i386-unknown-netbsdelf3.1 Wed Jan 24 03:55:26 CET 2007 Fail Compile powerpc-apple-darwin8.8.0 Wed Jan 24 00:24:34 MST 2007 Success Compile sparc-sun-solaris2.7 Wed Jan 24 01:30:31 EST 2007 Success Compile x86_64-unknown-linux-gnu Wed Jan 24 04:09:05 GMT 2007 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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
gnustep-make experiment
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 it uses pkg-config to store the environment variables so you'd need to setup PKG_CONFIG_PATH to wherever adds 2 configure options --with-pkgconfig-path=whereever --with-bootstrap-path=somewhere for the rationale behind 'bootstrap-path' see info -f make -n "Include" where it talks about the makefile search paths. you can set this to wherever and make and pass -I on the command line to make if you want it installed somewhere outside of the builtin make search path so if you set up the PATH to tools, LD_LIBRARY_PATH (or whatever) to lib dirs and PKG_CONFIG_PATH to the gnustep.pc then change include $(GNUSTEP_MAKEFILES)/common.make to include gnustep.make which just gets the GNUSTEP_MAKEFILES from pkg-config then include $(GNUSTEP_MAKEFILES)/common.make now obviously people who want to have multiple GNUsteps installed or GNUstep installed into non-system places like ~/ will have a bit more fiddling to do than they do now, both will need to fiddle with their PKG_CONFIG_PATH, and install into ~/ (or something) will need to add -I to make or make an alias for make -I.. so whether this simplifies things or complicates things is a good question... in theory given the right install locations and what not you wouldn't have to do anything so it could simplify those... 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@/Libraries/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
