Re: [RFC/make] Extend Framework support II

[David Ayers]

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