Re: reorganizing bundles ... killing the symlink

[Nicola Pero]

Thanks for your comments!

I thought quite a bit about it, and I've now done it.

I'd say that this problem has nothing to do with OSX compatibility.  You
put resource files in bundles by listing them in a GNUmakefile (or the
Apple equivalent), or in ProjectCenter (or the Apple equivalent); they are
automatically installed in the right place (whatever that is).  You find
resource files at runtime using the gnustep-base API (or the Apple
equivalent), which automatically looks for them in the right place
(whatever that is).

The actual location of resource files is not relevant for the programmer,
nor for portability.

But we definitely *don't* want to change the location of the resource
files often, because each time we do, we introduce a compatibility problem
between gnustep-make/gnustep-base/libFoundation releases ... older
gnustep-base/libFoundation releases will look for resources in the old
place, while newer gnustep-make releases will install them in the new
place.  Each time we change the location, we need to modify
gnustep-base/libFoundation in sync (in particular I find it cumbersome to
have to contact Helge telling him that he has to change libFoundation),
and then force everyone to upgrade ordinately.

So unless there is an overwhelming reason to change the location of the
resources inside the bundle (basically because a new, technically better,
solution is available) I wouldn't change them.

In particular, the fact that Apple has changed the location of the
resources inside their bundles (going from the NeXTstep/OpenStep bundles,
which have resources in the same place as GNUstep, to a new setup where
resources are in a different directory) should make no difference to us.  
We don't want to have to mess up all our internals each time they change
some of their internals.  Who cares anyway.

So, I've opted for the easiest solution - I left GNUstep resources where
they are, exactly as they were before, to avoid any incompatible change.  
We now build the OSX bundle in the OSX way only when compiling on OSX for
OSX using Apple frameworks (in which case, we don't build the GNUstep
bundle).  That makes sure we can update the OSX bundle code to be
up-to-date with Apple last quirks about their internals, while keeping the
GNUstep bundle code stable and unchanged in saecula.

Adam's comment is very appropriate - with this setup building a fat binary
bundle which can be used both on GNUstep using GNUstep's free frameworks,
and on Apple using Apple's proprietary frameworks is not as efficient as
before.  You can still - very easily - build it: you just compile the
bundle twice with two different LIBRARY_COMBOs (and probably different
architectures as well); the main disadvantage is that the Resources would
be duplicated, and copied twice, in two different places, in the bundle.  
I guess it's a very rare thing at the moment (I doubt anyone is doing it
... Hmmm ... maybe Helge is ?), and you can still add custom code to your
GNUmakefiles to manually use a symlink instead of duplicating the
resources in the bundle (but I need to try that out).

Anyway ... finally we no longer have symlinks in our bundles, and the road
to further gnustep-make features is open! :-)

Sorry for my usual over verbose email