non-flattened filesystem layout

[Richard Frith-Macdonald]

I finally got round to committing the changes to the non-flattened directory 
layout that I emailed about a few weeks ago.

The move to seamless Debian multi-arch compatibility is very much a work in 
progress, but even so I'd be grateful if people who habitually hack on gnustep 
would switch to using the non-flattened layout and provide bug reports.

Many years ago, the non-flattened layout was the only option, but we moved away 
from it because we thought the added complexity was discouraging people from 
using GNUstep.  That was probably true, but now that 64bit machines are 
commonplace, its a lot more usual to see different library directories etc, and 
maybe we could aim to switch the default back to non-flattened at some point.

If we do, then we will want to make things easier than they used to be:
When flattened mode was introduced, for a flattened build we started putting 
uninstalled binaries in a 'obj' subdirectory, instead of the 
cpu/os/library-combo subdirectory.
I think we should maintain that convenience by still having 'obj' on a 
non-flattened build, but making it a symbolic link to the actual architecture 
subdirectory, and having it removed and recreated on every invocation of make,. 
so that it always refers to the most recently built binaries.  That way, when 
we've just built foo, we know we can debug it with 'gdb obj/foo' etc.

But symbolic links don't work on windows XP (except NTFS with an add-on tool 
apparently) or FAT filesystems at all.  Could we drop support for XP and for 
building/installing on the old filesystem?  Or would we want to do something 
like copy all the binaries?

Apart from the 'obj' subdirectory issue, I see two remaining issues;

One relatively minor one, would be to figure out how to ensure that our 
sanitised cpu-os-abi triples are the same as debian ones ... maybe they already 
are for common platforms, but we need to check and figure out the best way to 
make sure they are kept in sync.

The major one is 'unbundling' for installation in the Debian interpretation of 
FHS.

The GNUstep/Cocoa/OpenStep APIs are built around installation of bundles where 
everything for an app/framework/bundle is collected in one directory hierarchy;
eg.
fhs-path-to-apps/foo.app/architecture/library-combo/binary
fhs-path-to-apps/foo.app/Resources/architecture-independent

The Debian FHS installation expects something more like this (rough idea);

fhs-path-to-apps/architecture/foo.app/library-combo/binary
hfs-path-to-arch-independent/foo.app/Resources/architecture-independent

NB. actually I read that the current Debian multi-arch doesn't handle 
executables yet (though they might in future) .. but this already applies to 
bundles and frameworks.

That means we need a way to do an unbundled install which will move the 
'architecture' part of the whole path, breaking up the bundle into separate 
parts of the filesystem, rather than simply unpacking the bundle into a 
directory.
The uninstall would have to remove from separate parts of the filesystem, 
rather than simply removing the bundle directory.
At runtime, the implementation of the path utility APIa and bundle APIs for 
accessing resources would need to somehow transparently retrieve resources from 
the different palaces they are installed.

We may also need a few new options in gnustep-make to more clearly 
differentiate between types of resources.  On the other hand, perhaps we can 
just put architecture dependent resources in an appropriate subdirectory in the 
source tree and build in some intelligence to gnustep-make to have it 
understand what they are and how they should be installed.