Re: Flattened GNUstep structure?

[Richard Frith-Macdonald]

On Thursday, January 11, 2001, at 07:20 AM, Pascal J. Bourguignon wrote:

> Avoiding the  "deep" directory  structure will not  simplify anything. 
> It's never seen by the user.  It's rarely seen by the developer or the 
> administrator.  Most of these ${CPU}/${OS}/${LIBCOMBO} are hidden deep 
> in .app, .gdladaptor, .framework, or  other file packages, or in *_obj 
> directories,  all of  which are  managed  by the  Makefiles. The  only 
> others are encountered in  developer directories such as Libraries and 
> Headers, where it would be difficult to flatten them anyway. 

I think there's a misunderstanding about the point of this ...

The deep/flattened structure should be irrelevant to the end user anyway,
and binaries built for either structure should (as long as we get it
right ... and that is probably not yet the case) work irrespective of the
layout of the installed system components (libraries) - certainly the
code built into gstep-base for locating binaries should work for both
structures.  I mean that you should be able to install deep and shallow
apps on the same system and both should work.

So - the issue is/should-be relevant only to developers/power-users who
are interested in looking at the internals of apps/bundles and the
library directory trees.

Last time this issue was raised, it seemed to me that the thought was
that new developers would be/are bugged/intimidated by the hierarchy and
would like to be able to find the binaries that they just made at/near
the top level.
Personally, I've never understood that attitude, but as it was raised
quite vocally, I have to accept that it exists.


New suggestion, that might be sufficient for both groups
(probably not, but I can hope can't I?)...

Use the deep structure, but add top-level symbolic links to the most
recently built version of any software - that way, you would have a
shortcut to whatever you are working on ...
In the source directory, obj would be a symbolic link to the directory
containing the most recently compiled .o files, and there would be a
symbolic link to each executable built.

The downside of this of course is that it wouldn't work on windoze.