reorganizing bundles ... killing the symlink

[Nicola Pero]

I'd like to remove the symlink which we build inside a bundle directory.

It's making things too complicated.

Currently, the structure of a gnustep bundle is 

xxx.bundle/ix86/linux-gnu/gnu-gnu-gnu/<bundle_object>
xxx.bundle/Resources/Info-gnustep.plist
xxx.bundle/Resources/<any resource here>

For compatibility with NeXTstep (so that you can use gnustep-make on
NeXTstep to build pure <non-gnustep> NeXTstep bundles) we also generate

xxx.bundle/Resources/Info.plist

For compatibility with OS X (so that you can use gnustep-make on OSX to
build pure <non-gnustep> OSX bundles) we also generate

xxx.bundle/Contents/Info.plist
xxx.bundle/Contents/Resources --> ../Resources

==

I'm planning powerful extensions for bundling etc, and this symlink is
making them much more complex - it's also difficult to port, and since
gnustep-back uses bundles, I'd like to remove this portability problem
completely.  

(Ok - truth is, it has never be really portable, and even forgetting
portability I want to support arbitrary nesting of bundle-enabled project
types [bundle-enabled project types will basically be all four basic
project types, apps bundles tools libraries]; for example putting a bundle
inside an application when you compile them.  Now if I copy the bundle
inside the app, then yes I can manually preserve the symlink when copying
the bundle inside the app.  But then, when you install the app, that
copies the .app directory into the installation directory, including the
bundle which is inside it, and the symlink is no longer preserved!  
Unless I write unmaintainable code which remembers all symlinks which were
create inside the app dir, and tries to preserve all of them when
installing the app ... since I want to allow arbitrary nesting of
bundle-enabled projects (say you could put a bundle inside a bundle inside
a tool inside an application), keeping track of the symlinks would be a
nightmare.  Btw preserving just a single symlink is already horrible, and
also somewhat destroys the whole purpose of a xxx.bundle, which is that
you can just copy it around and no matter how you do it, it works.  If I
could drop the symlink, all this advanced nesting could instead be reality
in a short time).

==

An obvious suggestion would be to change the directory structure of
GNUstep bundles to be more similar to OSX -

xxx.bundle/[ix86/linux-gnu/gnu-gnu-gnu/]<bundle_object>
xxx.bundle/Contents/Info-gnustep.plist
xxx.bundle/Contents/Resources/<any resource here>

For compatibility with OSX (so that you can use gnustep-make on OSX to
build pure <non-gnustep> OSX bundles) we'd also generate 

xxx.bundle/Contents/Info.plist

No symlinks would be required.  That would imply dropping the NeXTstep
compatibility - but is anyone still using a NeXTstep and wishing to use
gnustep-make on NeXTstep to build pure <non-gnustep> NeXTstep bundles ?  
I somewhat doubt it :-)

Of course, it would require myself to update gnustep-base to look for
Info-gnustep.plist and resources in a different place, and might
potentially break something (but I doubt it, nothing using only the
'official API's can be broken).

Problem is, then applications and bundles would have a different structure
... <applications still being like the original gnustep bundles>
... unless we want to change applications as well to be as in

MyApp.app/MyApp
MyApp.app/[ix86/linux-gnu/gnu-gnu-gnu/]MyApp
MyApp.app/[ix86/linux-gnu/gnu-gnu-gnu/]library_paths.openapp
MyApp.app/Contents/Info-gnustep.plist
MyApp.app/Contents/Resources/<any resource here>

then I need to update the application code as well, and the change is
somewhere more extensive.  But it can easily be done.

==

Another solution would be to build bundles in the GNUstep way when running
on gnustep, and build bundles in the OSX way when running on OSX.

So, on gnustep:

xxx.bundle/Resources/Info-gnustep.plist
xxx.bundle/Resources/<any resource in here>

while on OSX (if building for OSX native <non-gnustep> platform)

xxx.bundle/Contents/Info.plist
xxx.bundle/Contents/Resources/<any resource in here>

Again, no symlinks ever.

{Maybe then, we could actually do on GNUstep as in -

xxx.bundle/Info-gnustep.plist
xxx.bundle/Resources/<any resource in here>

because, after all, it makes some sense to have Info-gnustep.plist outside
the Resources/ dir, and also to have it top-level, since it contains
information about what you can find inside the bundle, and where.

Then GNUstep and OSX just different on the 'top-dir' in which they place
Info[-gnustep].plist and Resources/, so I could have a variable keeping
that dir, and set it differently in the two cases.}

But I'm not sure how to determine when I should build bundles in one way,
and when in the other. (Helge ?)

==

Comments ?  Preferences ?  Suggestions ?