Re: [RFC/make] Extend Framework support II

[Nicola Pero]

> > What I meant was much more radical than this though. :-)
> > 
> > I don't think GNUSTEP_SYSTEM_ROOT, GNUSTEP_NETWORK_ROOT, 
> > GNUSTEP_LOCAL_ROOT make any sense on apple-apple-apple.
> > 
> > On apple-apple-apple, you just use your Apple.  You have no GNUstep
> > installed.  There is no GNUstep installation.
> > 
> > If you are a developer, you might have installed gnustep-make somewhere on
> > your harddisk, presumably in your home directory.  That is a "gnustep-make
> > installation", not a "GNUstep installation", even if the directory
> > structure might be similar.
> >
> > The stuff installed, frameworks and applications, should be native Apple 
> > stuff.
> >
> > When you build stuff using your gnustep-make installation, then you 
> > set GNUSTEP_INSTALLATION_DIR to be '/' (or '~').  Then the GNUmakefiles will
> > install stuff in '/' or '~', that is on the Apple directories.  You 
> > don't  install anything in your gnustep-make installation.

> 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.


> 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.


> > Of course the catch is that you shouldn't compile anything as a library,
> > everything should be an apple framework, even stuff which would be a
> > library normally on GNUstep.  For example, -baseadd should be a framework.
> > The natural thing to do this is to use native-library.make btw.
> > 
> > So the only default I would change is GNUSTEP_INSTALLATION_DIR, which I'd 
> > point to '/' on apple-apple-apple.
> 
> I'm fine with changing that default.  I'm even fine with considering 
> switching to native-library.make which would impact -baseadd -> 
> GNUstepBase.framework , GDL2 (-db2control -> EOControl, -db2 -> 
> EOAccess, -db2modeler -> EOModeler), -gsantlr -> GSANTLR, and gsgd.  As 
> you know I'm exploring that now.
> 
> The -baseadd->GNUstepBase.framework change would probably only impact 
> apple-apple-apple, the other projects will also be impacted for 
> gnu-gnu-gnu.  But we could add symlinks to support the old names for a 
> bit.  Yet that switch really has to be considered and tested carefully, 
> yet I it may be a good idea.

Maybe a gradual approach could be taken, as explained below

 
> > 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).

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 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

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.