GNUstep Testfarm Results
Test results for GNUstep as of Thu Oct 12 06:34:19 EDT 2006 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 Success Compile i386-unknown-netbsdelf3.0 Thu Oct 12 03:56:27 CEST 2006 Success Compile powerpc-apple-darwin7.9.0 Thu Oct 12 03:10:01 MDT 2006 Fail Compile sparc-sun-solaris2.7 Thu Oct 12 01:55:09 EDT 2006 Success Compile x86_64-unknown-linux-gnu Thu Oct 12 04:08:52 BST 2006 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On consideration, I think we should stick to current conventions ... Ok ... but then you seem to have a weird perception of the current conventions ... ;-) The GNUstep filesystem document (which took ages of mailing list flamewars to write) explicitly says that -- Every software (except for gnustep-make, gnustep-base, gnustep-gui and gnustep-back which by default install into the System domain) should install by default into the Local domain, so that if you download a source tarball of the software and you install it, it installs by default in the right place for this operation (the Local domain). Distributions should override this default manually when they package the software they want to distribute as part of their distribution, so that in that case the software is installed in the System domain. It has been saying that for the past few years, so I guess that's what the current convention is. ;-) On a system where the traditional GNUstep filesystem layout is not used, the System domain should be /usr/local or /opt or whatever, unless the people managing a distribution want it to be /usr on that distribution of course. I imagine that on such systems the System and Local domains might be the same place. I don't agree at all ... the System domain will of course be /usr, and the Local domain will be /usr/local. Otherwise, why do we have domains at all ? :-) Presumably FHS compliance will also require that ... stuff coming with the distribution goes into System (/usr), stuff you manually install yourself from sources goes into Local (/usr/local) ... feels obvious. Let's make an example. Let's say I take gnustep-make and gnustep-base from Debian packages. They use Debian FHS policy, so no doubt System will be /usr and Local will be /usr/local (or /opt, whatever). They will then be installed in /usr. Which is great, as I know /usr is stuff managed by Debian. Then, I download sqlclient and compile it manually. Should it go in /usr or in /usr/local ? Obviously in /usr/local. Which is great, as I know that /usr/local is stuff I installed myself. sqlclient is still part of GNUstep, but by default if I download a package, it goes into /usr/local. That would work exactly like any other GNU/Unix/Debian package. Which is the whole reason we're working for FHS integration etc. etc. People want to be able to use GNUstep like they use any other package, without special setups / conventions / etc. Anyway I suggest as a reasonable agreement, we'll use b. to set the installation domain as System for the 4 core packages (make, base, gui, back). All other packages should have no default set and so install by default in Local (packagers are encouraged to install them into System instead when they package though). Makes sense ? No ... not really. The System domain is for all system packages, not just a few core libraries. I agree ... but who decides what are the system packages ? Not us. :-) It's decided by the packagers. ;-) The reason to have separate System and Local domains is not to have first class packages in System and second class packages in Local. The reason is that when you look at your hard disk, you know what is managed by your distribution and you shouldn't touch, and what you are managing yourself and can mess up as you wish. The fact that a package belongs to GNUstep or not doesn't tell me anything about whether my distribution/packaging system is managing it or whether I installed it from scratch. They are separate issues. ;-) I would like to see *more* packages brought into GNUstep and the System domain rather than having things excluded from it, as I feel that it would be good to have a complete environment. For instance, it would be nice if GNUMail was part of GNUstep. The fact that something is installed by the packager into the System domain or not has nothing to do with being part of the GNUstep project. It would be the same as saying that things installed in /usr are part of the GNU project, while things installed in /usr/local are not. But these are totally unrelated issues. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GSEncodingName
Hello Richard, This function returned an non-localized NSString representation of an NSStringEncoding allowing a way to specify a human readable/set-able yet locale independent property list representation. On the one hand it was a documented Function, one which replaced a deprecated predecessor. On the other hand a comment in the header stated it was part of a set of private functions. We use it GDL2 to allow the user to define the string encoding used by the database in a locale independent manner with the model. Of course we could maintain a local mapping, but it seems to me that this functionality should be kept together with the NSStringEncoding definitions which -base provides. I would like to request that we keep this IMHO very useful addition unless there is some new API that replaces this functionality which I'm not aware of. At least I'd like to see a deprecation cycle despite the comment in the header, which I admit I was not aware of until now. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSEncodingName
Hi, I also vote for a rehabilitation of that function. Otherwise you have to keep a local copy in the Database framework or apps like EOModeler. The strings used in EOModels are NOT to be localised. As such, the Apple API lacks this functionality, but I am sure they have it hidden... Dave -- _ _ _(_)(_)_ David Wetzel, Turbocat's Development, (_) __ (_) Buchhorster Strasse 23, D-16567 Muehlenbeck/Berlin, FRG, _/ \_ Fax +49 33056 82835 Phone +49 33056 82834 (__) http://www.turbocat.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On Thu, 12 Oct 2006 22:00:18 +0200 (CEST), Nicola Pero [EMAIL PROTECTED] said: [...] On a system where the traditional GNUstep filesystem layout is not used, the System domain should be /usr/local or /opt or whatever, unless the people managing a distribution want it to be /usr on that distribution of course. I imagine that on such systems the System and Local domains might be the same place. I don't agree at all ... the System domain will of course be /usr, and the Local domain will be /usr/local. Otherwise, why do we have domains at all ? :-) Well, according to the FHS, if you download GNUstep and compile it on your own (not obtaining it from your distribution), then it should go under /usr/local, or /opt. In which case, Local and System are probably equivalent, since GNUstep itself is a local package, and there is no distribution involved. But if you obtain GNUstep from your distribution, then it should definitely go under /usr. So IMHO by default, the System and Local domains should be /usr/local, but the distributions will of course override that for their own packages. -- Hubert Chan - email Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSEncodingName
On 12 Oct 2006, at 22:30, David Wetzel wrote:
Richard Frith-Macdonald wrote:
I didn't realise this was used outside the base library.
I've no strong objection to putting it back, but I do want to
minimise/remove non-standard APIs (just declaring them private is not
good enough).
Would it really be a great hardship to just use the numeric values of
the string encodings?
I don't know the current state of GDL2 ... I guess if you dislike
using a number there is no gui tool for manipulating models and you
edit plists by hand?
I use EOModeler on a Mac.
index.eomodeld:
{
EOModelVersion = 2.1;
adaptorName = PostgreSQL;
connectionDictionary = {databaseName = ; hostName = ;
databaseEncoding =
NSUTF8StringEncoding; };
entities = ( ...
I meant that if you used a gui tool the value in the model would be
hidden, so you wouldn't care what representation it used.
Sure, I use the inspector to insert NSUTF8StringEncoding there.
But it is possible that in some version
of OSX or GNUstep the (internal) number is changed.
Less possible than them changing the string value ... the numeric
value is specified in the header files. Not a big issue anyway,
Also, NSUTF8StringEncoding is better readable
that a numeric value, which you would have to look up.
Is that a good reason?
I've done an fgrep of the entire subversion repository, and googled
to try to wind any other mention on the web.
The only place I can find this function used is once in gdl2
It seems likely that either it's not actually very useful, or people
have refrained from using it because it was commented as private.
Anyway ... as it's used in only one place, why don't I just implement
the function there (gdl2/EOAccess/EOAdaptor.m)?
Any objections?
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSEncodingName
Richard Frith-Macdonald wrote: Anyway ... as it's used in only one place, why don't I just implement the function there (gdl2/EOAccess/EOAdaptor.m)? Any objections? as it is not database dependent in any way, I would put it into base or base extensions on platforms where we use a different foundation framework. That way it is a extension/addition and everybody can use it. Dave -- _ _ _(_)(_)_ David Wetzel, Turbocat's Development, (_) __ (_) Buchhorster Strasse 23, D-16567 Muehlenbeck/Berlin, FRG, _/ \_ Fax +49 33056 82835 Phone +49 33056 82834 (__) http://www.turbocat.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSEncodingName
On 12 Oct 2006, at 21:13, David Ayers wrote: Hello Richard, This function returned an non-localized NSString representation of an NSStringEncoding allowing a way to specify a human readable/set- able yet locale independent property list representation. On the one hand it was a documented Function, one which replaced a deprecated predecessor. On the other hand a comment in the header stated it was part of a set of private functions. We use it GDL2 to allow the user to define the string encoding used by the database in a locale independent manner with the model. Of course we could maintain a local mapping, but it seems to me that this functionality should be kept together with the NSStringEncoding definitions which -base provides. I would like to request that we keep this IMHO very useful addition unless there is some new API that replaces this functionality which I'm not aware of. At least I'd like to see a deprecation cycle despite the comment in the header, which I admit I was not aware of until now. I didn't realise this was used outside the base library. I've no strong objection to putting it back, but I do want to minimise/remove non-standard APIs (just declaring them private is not good enough). Would it really be a great hardship to just use the numeric values of the string encodings? I don't know the current state of GDL2 ... I guess if you dislike using a number there is no gui tool for manipulating models and you edit plists by hand? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSEncodingName
Richard Frith-Macdonald wrote:
I didn't realise this was used outside the base library.
I've no strong objection to putting it back, but I do want to
minimise/remove non-standard APIs (just declaring them private is not
good enough).
Would it really be a great hardship to just use the numeric values of
the string encodings?
I don't know the current state of GDL2 ... I guess if you dislike
using a number there is no gui tool for manipulating models and you
edit plists by hand?
I use EOModeler on a Mac.
index.eomodeld:
{
EOModelVersion = 2.1;
adaptorName = PostgreSQL;
connectionDictionary = {databaseName = ; hostName = ;
databaseEncoding = NSUTF8StringEncoding; };
entities = ( ...
Sure, I use the inspector to insert NSUTF8StringEncoding there. But it is
possible that in some version
of OSX or GNUstep the (internal) number is changed. Also, NSUTF8StringEncoding
is better readable
that a numeric value, which you would have to look up.
Is that a good reason?
Dave
--
_ _
_(_)(_)_ David Wetzel, Turbocat's Development,
(_) __ (_) Buchhorster Strasse 23, D-16567 Muehlenbeck/Berlin, FRG,
_/ \_ Fax +49 33056 82835 Phone +49 33056 82834
(__) http://www.turbocat.de/
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSEncodingName
Richard Frith-Macdonald schrieb: I would like to request that we keep this IMHO very useful addition unless there is some new API that replaces this functionality which I'm not aware of. At least I'd like to see a deprecation cycle despite the comment in the header, which I admit I was not aware of until now. I didn't realise this was used outside the base library. I've no strong objection to putting it back, but I do want to minimise/remove non-standard APIs (just declaring them private is not good enough). Would it really be a great hardship to just use the numeric values of the string encodings? I don't know the current state of GDL2 ... I guess if you dislike using a number there is no gui tool for manipulating models and you edit plists by hand? This is part of a string we expected the user to actually enter as a text into a text field/cell or even in text view in plist format in EO/DBModeler (the application used to manipulate the models). I guess we could also provide an additional interface with a combo box cell but it would be pretty inconsistent with the way other keys of the same connection dictionary are handled. (One NSTextFieldCell of a table view would need to be replaced automagically when a certain key is entered into another cell.) Also current models contain these strings and they would have to be adapted. I think that I'd rather add the mapping to GDL2 if it's not provided by base in the future. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
Richard Frith-Macdonald schrieb: On 12 Oct 2006, at 21:43, David Ayers wrote: Nicola Pero schrieb: Anyway I suggest as a reasonable agreement, we'll use b. to set the installation domain as System for the 4 core packages (make, base, gui, back). All other packages should have no default set and so install by default in Local (packagers are encouraged to install them into System instead when they package though). Makes sense ? No ... not really. The System domain is for all system packages, not just a few core libraries. I agree ... but who decides what are the system packages ? Not us. :-) It's decided by the packagers. ;-) Indeed, and I believe this is the core argument. The way I see it is, installing a self compiled -make and -base into the Local domain (potentially hiding the packager installation in the System domain) is analogous to installing a self compiled gcc into /usr/local hiding the system gcc (and related libraries like libobjc). Yes ... it's why I think there should be a distinction made between building/installing a package as the maintainter of a distribution and building/installing as a normal user. In both cases the package should automatically be installed in the correct place. The normal case should be that you do *not* have to specify where it should go. Well I think the dispute is based on the perception of the role of the GNUstep project. Just like source distributed by the gcc project doesn't install into /usr but into /usr/local, I don't think it is the GNUstep's -make/-base/-gui/-back packages prerogative to install into 'System'. Just like Debian and other OS distributions have their builds setup to install gcc into /usr, I think it would be a GNUstep distributions prerogative to install -make/-base/-gui/-back into System. I.e. if we hosted a distribution like SimplyGNUstep which provided the build scripts to build a GNUstep System, then I think it would be that projects prerogative to set the GNUSTEP_INSTALLATION_DOMAIN in it's build scripts. I'm only trying to make myself clear and I'm not on a mission to convince anyone here who simply has a different view. So I'll gladly clarify any misunderstandings but will refrain from further lobbying. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On 12 Oct 2006, at 21:00, Nicola Pero wrote: On consideration, I think we should stick to current conventions ... Ok ... but then you seem to have a weird perception of the current conventions ... ;-) The GNUstep filesystem document (which took ages of mailing list flamewars to write) explicitly says that -- Every software (except for gnustep-make, gnustep-base, gnustep-gui and gnustep-back which by default install into the System domain) should install by default into the Local domain, so that if you download a source tarball of the software and you install it, it installs by default in the right place for this operation (the Local domain). Distributions should override this default manually when they package the software they want to distribute as part of their distribution, so that in that case the software is installed in the System domain. It has been saying that for the past few years, so I guess that's what the current convention is. ;-) No ... I guess it's just what the filesystem document says ... not what's actually done. AFAIK nothing has been changed to do what that says, perhaps because people didn't notice the change, or perhaps because it didn't make sense to them? On a system where the traditional GNUstep filesystem layout is not used, the System domain should be /usr/local or /opt or whatever, unless the people managing a distribution want it to be /usr on that distribution of course. I imagine that on such systems the System and Local domains might be the same place. I don't agree at all ... the System domain will of course be /usr, and the Local domain will be /usr/local. Otherwise, why do we have domains at all ? :-) I think you completely miss the point ... being that the managers of a distribution decide where they want things to install on their distribution. There is a BIG distinction between distribution managers installing packages as part of a distribution and normal users installing additional packages. Presumably FHS compliance will also require that ... stuff coming with the distribution goes into System (/usr), stuff you manually install yourself from sources goes into Local (/usr/local) ... feels obvious. Sure ... exactly what I said. The location of stuff coming with the distribution is handled by the managers of the distribution. Let's make an example. Let's say I take gnustep-make and gnustep-base from Debian packages. They use Debian FHS policy, so no doubt System will be /usr and Local will be /usr/local (or /opt, whatever). They will then be installed in /usr. Which is great, as I know /usr is stuff managed by Debian. Only if they are part of the debian distribution ... ie the managers of the distribution want to put them there. If they are *not* part of the distribution, I think it's debian policy to put them in /usr/local. Then, I download sqlclient and compile it manually. Should it go in /usr or in /usr/local ? Obviously in /usr/local. Which is great, as I know that /usr/local is stuff I installed myself. sqlclient is still part of GNUstep, but by default if I download a package, it goes into /usr/local. Sure ... you are not the manager of the distribution, but the distribution supplied GNUstep stuff, so for you to conform to distribution conventions, the system domain for installation should be set to /usr/local on that system. NB. the system domain for installation purposes would not be the same as the system domain for all other purposes in this case. It depends how you want to look at it, but the point is that the installation process should not treat installation by a normal user the same as installation by the package distributor ... a normal user should not be overwriting packages provided by the system. Take the base library for instance ... it's default location is the system domain. When a distribution maintainer installs it they may want the system domain to be /usr so it goes in /usr. However, when a normal user downloads and installs a version it should get installed in /usr/local because normal users should not be installing into /usr. The easy way to do this is for the maintainer to build/install using a copy of the make system where the system domain is set to /usr, but to send out the distribution with a copy of the make system set to install system domain packages into /usr/local That would work exactly like any other GNU/Unix/Debian package. Which is the whole reason we're working for FHS integration etc. etc. People want to be able to use GNUstep like they use any other package, without special setups / conventions / etc. Exactly what I'm proposing. Anyway I suggest as a reasonable agreement, we'll use b. to set the installation domain as System for the 4 core packages (make, base, gui, back). All other packages should have no default set and so install by default in Local (packagers are encouraged to
Re: GNUSTEP_INSTALLATION_DOMAIN
Nicola Pero wrote: Would it be an idea to have an option that decides what kind of tree is going to be used like: GNUSTEP_FS_STRUCTURE=[FHS|GNUSTEP|WINDOWS|SOLARIS] We're not far from that ;-) ... that option will be used when configuring gnustep-make. It is -base which decides what goes where so we shouldn't we really be configuring base, not -make? Decoupling the dependencies is a good thing, IMHO. We just need to save the configured filesystem structure in GNUstep.conf, and use it to set GNUSTEP_APPS etc. in common.make, and we're almost done (except that a few things, like GNUSTEP_INSTALLATION_DIR, will no longer work in that context). ;-) Then every application, at launch time, must set up the whole fs structure? And then GNUSTEP_INSTALLATION_DIR decides where the root is, maybe it should be called GNUSTEP_FS_ROOT, like in GNUSTEP_FS_ROOT=[/usr/GNUstep/System|/usr/GNUstep/Local|/usr|/usr/local|/opt] Why not GNUSTEP_INSTALLATION_DOMAIN then, which is an 'abstract' definition of where things should be installed ? gnustep-make would then map it to the local reality. :-) For consideration, isn't GNUSTEP_INSTALLATION_DOMAIN a little too confusing? I'd prefer something a little more like: GNUSTEP_INSTALLATION_DIR (we'd have to change some -make internals) GNUSTEP_INSTALL_INTO GNUSTEP_INSTALL_DESTINATION or perhaps we should be thinking more along packaging lines... GNUSTEP_PACKAGE_LOCATION Packagers can easily add a line to their makefile or preamble this way... Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
NB. the system domain for installation purposes would not be the same as the system domain for all other purposes in this case. This is a new, confusing distinction that you are introducing and that would make everything lot more complicated. ;-) You're proposing to introduce 'installation domains' as separated from 'runtime domains', ie, you could have /usr/lib as the runtime System/Libraries dir, while /usr/local/lib is the installation System/Libraries dir. That would be a hell lot of a complication (and there is more complexity for packagers). ;-) Hopefully we can negotiate some other solution, as I don't want to add such complexity. :-/ I had written more on this, but I don't want to discuss it. Too complex. ;-) I agree ... but who decides what are the system packages ? Not us. :-) It's decided by the packagers. ;-) But we *are* the packagers for the *default* system ... the GNUstep system. We only distribute the source code, not binaries. If we distribute binaries, then yes, we should install the GNUstep ones into System. When we distribute source code, it should install by default into Local. I agree we should have binaries distributions of the default system, and those should install all GNUstep packages into System. In fact, anything that they package should be put into System. That would be great. :-) Only where you are using a system with GNUstep stuff pre-installed. Many (most?) people are not using such a system ... they have installed the 'GNUstep system' on their machine. It's located in /usr/GNUstep. The standard packages are in /usr/GNUstep/System Other stuff is in /usr/GNUstep/Local Core developers (/most people at the moment) that compile and install from scratch are not using a distribution. ;-) (guess I need to clarify that by 'distribution' I mean 'binary distribution'). When you're not using a distribution, the difference between System and Local is irrelevant. They could well be the same ... you're installing everything from scratch anyway. :-) In fact, why would you care where things go at all ? It could well all go into Local and you wouldn't notice. At the moment, software installs randomly into System or Local. Nobody cares because nobody is using a distribution. When occasionally they look at the directories they might like seeing 'core' stuff in System and other stuff in Local, but it's only aesthetical. If we had distributions (and we hope to get more of that as a result of the massive simplification and Unix nativization), then people would start to get some packages from the distribution, and to compile some of them manually. Then the difference starts to be important. If you're getting -make and -base from the binary distribution, but you're installing -gui from sources, you would want -make and -base into /usr/GNUstep/System, and -gui into /usr/GNUstep/Local ... and you start to care about the difference, because stuff in /usr/GNUstep/System is package-managed, while stuff in /usr/GNUstep/Local is not. The standard GNU solution that everyone is using is that source code by default installs into Local unless you specify differently. Users do nothing and it all works; packagers simply specify differently, which is a single install flag, and it all works. We should do the same IMO. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
Would it be an idea to have an option that decides what kind of tree is going to be used like: GNUSTEP_FS_STRUCTURE=[FHS|GNUSTEP|WINDOWS|SOLARIS] We're not far from that ;-) ... that option will be used when configuring gnustep-make. It is -base which decides what goes where so we shouldn't we really be configuring base, not -make? Decoupling the dependencies is a good thing, IMHO. You would be able to change your filesystem structure at any time by editing your GNUstep.conf. GNUstep.conf is initially created by gnustep-make, so it makes sense to have the option there. Things should be decoupled ... -make and -base don't really talk or depend on each other. Everything is driven by GNUstep.conf. You'll be able to use -base (/any other GNUstep software) without -make if you want, if you set manually everything in GNUstep.conf. We just need to save the configured filesystem structure in GNUstep.conf, and use it to set GNUSTEP_APPS etc. in common.make, and we're almost done (except that a few things, like GNUSTEP_INSTALLATION_DIR, will no longer work in that context). ;-) Then every application, at launch time, must set up the whole fs structure? Yes ... we're not really almost done. :-( ... we also need to have gnustep-base load the directory structure from GNUstep.conf and use it when searching for stuff at runtime :-/ For consideration, isn't GNUSTEP_INSTALLATION_DOMAIN a little too confusing? I'd prefer something a little more like: GNUSTEP_INSTALLATION_DIR (we'd have to change some -make internals) The problem with this is that it would break backwards compatibility ;-) There are makefiles out there that might be using it in the old meaning. We can't break those, at least not when they are used in the old context. ;-) GNUSTEP_INSTALL_INTO GNUSTEP_INSTALL_DESTINATION or perhaps we should be thinking more along packaging lines... GNUSTEP_PACKAGE_LOCATION Packagers can easily add a line to their makefile or preamble this way... I don't really have an opinion, I like GNUSTEP_INSTALLATION_DOMAIN but we can change the option name, it's not a problem. :-) Comments/suggestions on the name are welcome. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
I don't agree at all ... the System domain will of course be /usr, and the Local domain will be /usr/local. Otherwise, why do we have domains at all ? :-) Well, according to the FHS, if you download GNUstep and compile it on your own (not obtaining it from your distribution), then it should go under /usr/local, or /opt. In which case, Local and System are probably equivalent, since GNUstep itself is a local package, and there is no distribution involved. But if you obtain GNUstep from your distribution, then it should definitely go under /usr. Yes :-) So IMHO by default, the System and Local domains should be /usr/local, but the distributions will of course override that for their own packages. I would rather say that, by default, System is /usr and Local is /usr/local, and source packages install by default into Local. Distributions will override that for their own packages. If System/Local domains are the same (/usr/local), then we would ignore /usr, so resources from system packages in /usr would not be found. Really, if System packages are in /usr, the System domain should be available as /usr. This means resources/frameworks/bundles/etc. in System (/usr) would be available/visibile to -make, -base and to any other gnustep stuff (such as openapp or whatever). Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
Things should be decoupled ... -make and -base don't really talk or depend on each other. Not entirely true. Currently -base depends on -make for configuration. Thanks, I see your point ... which is a very good one :-) You're suggesting that, for example, in a binary distribution (say, Debian) you could install gnustep-base without installing gnustep-make. Then you can also install any other GNUstep software that is binary packaged by the distribution. You don't need gnustep-make, because everything is in the FHS locations and you're not building anything, you're just installing binary packages. I agree it would be a nice thing :-) In that case, yes, you would need GNUstep.conf, yet you have no gnustep-make installed. I suppose the right way of addressing the issue is to create a 'gnustep-common' package, that only installs GNUstep.conf. Then, on top of that, you can install gnustep-make and/or gnustep-base; you only install gnustep-make if you want to build. We could make all this explicit by extracting the creation of GNUstep.conf into a separate software ... to be installed before gnustep-make. It sounds very clumsy though ;-) At the moment, I'd leave everything as it is (a packager could still install GNUstep.conf in a separate package to get the effect above). Moving the creation of GNUstep.conf into gnustep-base doesn't make much sense, because gnustep-make can't work without it. You may want to use gnustep-make without gnustep-base (eg, for building documentation or resources or java stuff, or for building using non-gnustep-base foundation libraries, eg on apple-apple-apple or gnu-fd-nil), and at the moment you can't build gnustep-base without gnustep-make anyway ;-) Anyway, good idea to keep it in mind, I mean, yes, conceptually, the step of creating GNUstep.conf is separate from gnustep-make and gnustep-base. It's a preliminary step if you want. ;-) Yes ... we're not really almost done. :-( ... we also need to have gnustep-base load the directory structure from GNUstep.conf and use it when searching for stuff at runtime :-/ For long lived processes this might be fine but for short lived tools you're imposing a considerable startup delay. There is already such a delay, since we are already reading GNUstep.conf. I doubt adding ten more lines or so to read would make any difference in speed. If we could avoid reading the file altogether, that would be faster. ;-) I imagine the 20 lines GNUstep.conf file will always be in the kernel cache so it will all be extremely fast. Maybe we could benchmark it, but even for a Unix command-line utility that has to be as fast as 'grep' or 'sed' or those thingies, I'm not sure it would make a measurable difference. If it makes a considerable difference, presumably you'd disable GNUstep.conf and just run from hardcoded values. That would work and be as fast as you can get :-) I added PLATFORM_SUPPORT as a step in avoiding that. If you said something like: GNUSTEP_INSTALLATION_DOMAIN=PLATFORM_LIBS you'd get your library installing into /usr/lib and so forth. So any GNUSTEP_* spec uses OpenStep domain layout. Any PLATFORM_* spec uses the local platform specifics. Oh ... I see. I looked at that ... but the current idea/trend is rather that, when you use the Unix FHS (for example), the GNUstep dirs are mapped onto local Unix FHS dirs. All access to the dirs goes through the API anyway. So, GNUSTEP_SYSTEM_ROOT/Tools ends up mapped into /usr/bin. GNUSTEP_LOCAL_ROOT/Library/Libraries is mapped to /usr/local/lib, etc. Of course the libs have to do the mapping from the GNUstep API to the native filesystem. This mapping comes from GNUstep.conf (or is hardcoded in the lib). So, rather than have both the GNUstep filesystem and the native filesystem in the same installation, you'd have either the GNUstep one or the native one. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On 13 Oct 2006, at 02:33, Nicola Pero wrote: NB. the system domain for installation purposes would not be the same as the system domain for all other purposes in this case. This is a new, confusing distinction that you are introducing and that would make everything lot more complicated. ;-) You're proposing to introduce 'installation domains' as separated from 'runtime domains', ie, you could have /usr/lib as the runtime System/Libraries dir, while /usr/local/lib is the installation System/Libraries dir. That would be a hell lot of a complication (and there is more complexity for packagers). ;-) When writing the last email I started writing about how the term domain might be confusing ... but then gave up and deleted that paragraph. I'm really don't want complexity. What I want is to make things simple to use, so people don't need to add extra arguments to their make command to say where things should go. Hopefully we can negotiate some other solution, as I don't want to add such complexity. :-/ I agree. I had written more on this, but I don't want to discuss it. Too complex. ;-) I agree ... but who decides what are the system packages ? Not us. :-) It's decided by the packagers. ;-) But we *are* the packagers for the *default* system ... the GNUstep system. We only distribute the source code, not binaries. If we distribute binaries, then yes, we should install the GNUstep ones into System. When we distribute source code, it should install by default into Local. I agree we should have binaries distributions of the default system, and those should install all GNUstep packages into System. In fact, anything that they package should be put into System. That would be great. :-) Only where you are using a system with GNUstep stuff pre-installed. Many (most?) people are not using such a system ... they have installed the 'GNUstep system' on their machine. It's located in /usr/GNUstep. The standard packages are in /usr/GNUstep/System Other stuff is in /usr/GNUstep/Local Core developers (/most people at the moment) that compile and install from scratch are not using a distribution. ;-) (guess I need to clarify that by 'distribution' I mean 'binary distribution'). OK .. I don't hugely object to the principle of installing in Local ... but I mostly haven't seen it clearly argued for/justified. The argument based on installing like general unix packages, in /usr/ local, donesn't make sense to me since /usr/local is not necessarily the same thing as Local. We can easily install in the same place as standard unix packages without installing in Local. The subtly different argument that anything not built as part of a distribution should install in the Local domain rather than the system domain (because only the distributor should touch the System domain) makes much more sense, but is complicated by other factors ... 1. the definition of a distribution ... since the GNUstep project is, in a sense, a distribution 2. inconsistency, since existing practice is to install the core libraries and some other tools in System, and in the file layout document you pointed out that 'official' policy is to store the core libraries in System. 3. historical. we are talking about changing behavior and where things go by default Now, I think we can ignore 1 (now we are clear about it) since that's really just semantics, the only practical reason for considering the GNUstep project like a binary distribution is because some people (well, me at least) happen to have thought of it that way and because it largely fits in with (3) the historical practice of where things are installed. I find 2 a real annoyance ... the idea of putting GNUstep stuff in system was consistent with my understanding of 1, but this (currently documented) notion of putting the core libraries in System and everything else in Local makes no sense. Surely it should be one or the other? I'm happy to put everything in Local (if we define that the GNUstep project is not a distribution) or everything in System (if we define a distribution as a binary distribution), but I very much dislike a mixture. 3. We can probably live with a change i behavior. However ... here we come to a point where maybe I would quite like to see the installation code made more complex. The make package has just been cleaned up a lot to avoid confusion and conflicts between normal,debug, and profile libraries, but now we are likely to get multiple copies of packages installed in different domains. This should not cause horrible crashes and failures to run, but is still likely to cause confusion. How hard would it be for gnustep-make to spot that we are installing a duplicate, tell us which domain the existing version is in, and ask us about it? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org
