Where goes stacks, included stacks and externals? (was Dialogs inlibrary organization)

[Dar Scott]

On Wednesday, February 4, 2004, at 08:42 PM, Monte Goulding wrote:

> Not if you think of the MacOS folder as the application directory. 
> Don't
> forget the application bundle is just a set of folders.

I don't think most users would think of it that way.  It is really 
handy for me, of course.

>> I don't think Revers tend to think of their stacks in OS X apps as
>> necessarily MacOS specific.
>
> That's not what I meant.

My goof.  Besides being the place for executables, MacOS is the folder 
for OS X specific executables.

>
>> So on Windows or OS X or traditional Mac OS or even Linux, where do
>> stacks for development, applications, or part of applications go?
>> Where do externals?  I mean by this, where do folks currently put them
>> and where should they go.
>
> I'm not sure what you mean here.

OK, let me describe the direction I'm going.  Folks can then put me 
right as to the right way to do this.

I'll ignore externals for now, but this is not resolved in my mind 
until externals are integrated into this.

When a standalone starts running its mainstack or I open stack in the 
IDE, it must be able to find supporting library and other design stacks 
(as oppose to preferences and data stacks) and open or start using 
them.  Those in turn might at times need to find stacks for opening and 
start using.

For the application support stacks, there are two levels.  The is the 
shallow user-can-find-and-change-easily level, and there is the more 
embedded level intended to be invisible to the user.  For example, on 
OS X, the first might be peer to (in the same folder as) the .app and 
the latter is down in the bundle.

One might use a splash stack to set up some globala that are used by 
all other stacks (and itself) in creating the path for opening and 
start-using stacks.

Another scheme would be to have all stacks find (create paths for) 
needed stacks based on a location relative to that stack.  That is 
independent and depends only on the path for the stack creating the 
path.  (Stacks might have externals, so there are constraints in 
opening and start-using methods to allow for that.)

Now maybe someone will ask "Why don't you just do it the usual way?" to 
which I respond that I know of no usual way and I make up my own.

So a path is created to find stacks.  It is based on these:
IDE or application?
Platform?  (This might be under "if app")
If app
   Am I app main stack?
   Is desired stack shallow or deep?

Here is an arbitrary layout:

Development:

stacks
    stackFamily
        stack
        stack
    stackFamily
        stack
        stack

In this setup the relative path form one stack to another is 
../stackFamily/stack.

OS X Application:

appfolder
    shallowStack
    myapp.app
       Contents
           MacOs
              myapp
           Resources
              Stacks (?)
                 stackFamily
                    stack
                    stack

So the relative path from the app stack to a shallow stack is 
../../../shalowPath
The relative path from the app stack to a deep stack is 
../Resources/Stacks/stackFamily/stack
The relative path from a deep stack to a deep stack is 
../stackFamily/stack
The relative path form a deep stack to a shallow stack is ... (and so 
on).

On Windows:

appfolder
    shallowStack
    myapp.exe
    Components
      stacks
         stackFamily
             stack
             stack

In the same way there is a path from any stack to another stack.

In this scheme, the relative path from any stack not the app stack to 
any stack not shallow is always ../stackFamily/stack, so that is a 
reasonable default for libraries.

The details are somewhat arbitrary to clarify my question.

This may have to be adjusted to accommodate externals, too.

Dar Scott