bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC/make] Extend Framework support II


From: David Ayers
Subject: Re: [RFC/make] Extend Framework support II
Date: Fri, 12 Mar 2004 14:44:10 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

Nicola Pero wrote:
Note that there may be a bit more to take into consideration. For example .../Library/Headers does not seem to be included in standard search directories.


Sure, because Apple doesn't use it.  If you install headers in
.../Library/Headers you're building stuff which you'll never be able to
distribute to pure Apple users.  You must build Apple frameworks and
install them in .../Library/Frameworks instead.

I don't like superimposing GNUstep directory structure to Apple also
because it creates these confusions.  The directories are similar, but
different.

Exactly, that's why I *do* like the fact that I can control the search paths via -make configuration. This gives the flexibility I need to use a consistent (the GNUstep) hierarchy, but I guess we'll have to disagree on what we look at, as the consistent approach. :-/

Also it seems that ~/Frameworks is not a hard coded standard Framework
directory that the loader searches automatically, but relies on the same
set of environment variables that I wish to add support for in -make.


On my Apple, ~/Library/Frameworks is automatically searched.  I've got no
environment variables relating to linking set, yet if I remove my
Renaissance.framework installation, a test application doesn't start, if I
reinstall it in ~/Library/Frameworks, it starts again, so it looks like
it's searched automatically.

Well, it's not working here (or 'there', actually), but I'll keep investigating... *sigh*

The rest is irrelevant, as it's your own gnustep-make installation which
you can put wherever you want, and unless you're compiling stuff from
sources using GNUmakefiles, you don't need gnustep-make at all.

I disagree, please also consider my point of view, that instead of reducing the options we have on apple-apple-apple that we complete the configuration options that we already have wrt -L/LD_LIBRARY_PATH with -F/DYLD_LIBRARY_PATH. We don't need the two extra scripts. It can easily be integrated into the existing infrastructure. It makes the conventional "GNUstep installation" possible on apple-apple-apple and easy to use for someone with GNUstep experience.


A simple arrangement would be that if you have GNUstep libraries which
have not yet been converted/setup to compile as frameworks on Apple (which
I think is the main problem you are having), you could install (for now)
the GNUstep libraries into the gnustep-make installation dirs, while you
install the frameworks in the Apple installation dirs.

(That already demonstrates the main problem - it's not really a native
apple-apple-apple solution, because in apple-apple-apple everything has to
be a framework).

I'd challenge that. I had -baseadd and GDL2 working fine. I was just trying to get an app which uses GSWeb (which must be a set of "frameworks" everywhere) to build within my "GNUstep Installation". Even some of the standard frameworks rely on libraries (see below). None the less it's obvious that the *step like Cocoa file system only wants to support frameworks, so I'll grant you that.

ayers$ otool -L /System/Library/Frameworks/Foundation.framework/Foundation
/System/Library/Frameworks/Foundation.framework/Foundation:

/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation /usr/lib/libicucore.A.dylib
/usr/lib/libobjc.A.dylib
/usr/lib/libSystem.B.dylib

But it should work for you to setup things quickly, and as you
update/modify libraries to build as frameworks on Apple, you start
installing them into the Apple dirs, so you're slowly updating your system
to be Apple native, but you have something non-very-native to start with.

Once you've got everything as a framework in Apple's framework dirs,
you've got a totally native build which you can distribute to
non-gnustep-make users, and which non-gnustep-make users can use with
XCode without having to know anything about gnustep or gnustep-make. Which I assume is the final goal. If you can distribute gsweb in such a
format you might/will get a lot of new users. :-)

This is not about whether it would be better for the common user, not about marketing (we need to do a lot more that this to target real users, I'm targeting developers, developers that can also take non-apple-apple-apple into consideration as much as I consider apple-apple-apple developer needs). This is about consistency wrt a "GNUstep Installation" on any platform, even if you use apple-apple-apple. I'm not arguing that it shouldn't work with installing in the native locations. I'm fine with doing that by default. I just want it to work as a "GNUstep Installation" also. But you seem to be vetoing this.

This arrangement should work with no change -
 * GNUSTEP_*_ROOT are not set to the apple's paths

 * GNUSTEP_INSTALLATION_DIR is / for frameworks, but not for libraries
where it's still GNUSTEP_LOCAL_ROOT (this is the only change required)

* there is no need for -F/DYLD_LIBRARY_PATH because you install in the gnustep-make installation directory only non-frameworks

Copied my typo, should be -F/DYLD_FRAMEWORK_PATH.

Given this discussion, the suggestion seems now to be to change
GNUSTEP_INSTALLATION_DIR to be / by default for frameworks, applications
and bundles, but to remain GNUSTEP_LOCAL_ROOT for libraries.

Of course, GNUmakefiles which hardcode a GNUSTEP_INSTALLATION_DIR wont'
work cleanly.  That's entirely correct because GNUmakefiles should never
hardcode a GNUSTEP_INSTALLATION_DIR :-), unless they are system libraries
like gnustep-base or gnustep-gui (which pose no problem since you can't
have them on apple-apple-apple, that's why they are system libraries after
all, they compose the basic gnu-gnu-gnu library combo).  Software should
install by default in whatever the default installation directory is on
that platform, unless the user decides otherwise on the command line.

I have no issue with GNUSTEP_INSTALLATION_DIR defaulting to '/' on apple-apple-apple. I have no issues with removing the predefined GNUSTEP_INSTALLATION_DIR's in the GDL2, GSWeb and related projects (yet I'd have to coordinate it with Manuel and David W.) But again, please consider granting the right to have a (or even multiple) "GNUstep Installations" on OS X even for apple-apple-apple.

It's not one or the other here. It just makes the "GNUstep Installation" case work consistently with the rest of the GNUstep infrastructure. I know that Foundation and AppKit are not located there. And yes I understand why you view installing it with GNUSTEP_INSTALLATION_DIR=/ as the more consistent approach. I just happen to disagree. It's a great feature that GNUstep can integrate with different OPENSTEP implementations this way. I just don't see the justification of not allowing the alternative configuration, which can integrate just as well and has the option of allowing multiple "GNUstep Installations". (I'd post an updated simplified patch, but I currently can't reach the machine I'd like to test it on first.)

Cheers,
David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]