Dialogs in library organization

[Monte Goulding]

> It seems that _in general_ the Distribution Builder cannot create a
> single monolithic application.  It can take only one stack file and
> create an application.  However, it can move over the other stack files
> and set some properties appropriately.  Fortunately, on OS X, the
> stacks are put down inside the application bundle, so the result looks
> effectively monolithic.  (I don't understand the rationale for the
> particular folder, but that is a separate issue.)  However, on Windows,
> all stack files other than that of the primary stack file are outside
> the application.

This is a correct assesment of the situation. I'm not sure how you could
create a single executable file from multiple stack files and retain your
original message path. Perhaps if a standalone had it's own emulated
directory structure but I doubt that would ever happen. One way might be to
store stackFiles in custom properties, write them out at startup and delete
them at shutdown.
>
> Now, it could be I'm using the DB wrong.

I don't think so...
>
> So how does one make a monolithic application on Windows?  The best I
> can tell, in the direct way one has to move all the stacks and their
> substacks over to be substacks of the application stack.  Now, my
> message path has changed.  Typically this does not make a difference as
> name conflicts are unlikely, but I might make mistakes (theoretically).

On windows applications rarely need to be monolithic single file
executables. This is because the application directory is abstracted fom the
user if the application is installed properly. The user only needs to see an
icon for the application.
>
> (I was a little confused about this, since the DB, that is, the
> Distribution Builder, seems to use the word "stack" for "stack file" in
> some places.  In another place it listed the stacks and it included the
> main stacks of listed stack files and the substacks of the main stack
> file, but not the substacks of the stack files not main.)

There's some confusion over the term mainstack meaning mainstack of a
stackFile and Main Stack meaning the stackFile the engine is merged with to
create the standalone.
>
> Now that I think about it, my message path is changed anyway.  I
> remember something about the main stack of the executable main stack
> file being inserted into the message path after the main stack for a
> stack.  Maybe in IDE testing this can be emulated by putting it at the
> front of the libraries or something.

It's inserted into the same place as the Home stack currently is. Just
before the engine.
>
> (BTW, I noticed that when building an OS X standalone the DB used the
> OS X I was running as a model instead of one in the engines folder.
> This carries over all the tweaking I've done to the original, such as
> placing externals inside.  I'm not sure whether this is a feature I
> like or not.  It has both advantages and disadvantages.  There is no OS
> X in the engines folder, so maybe if I put one there, it would take
> that one, instead.)

Yep... The distribution builder will always use the running engine for that
platform and engines in the engines folder for other platforms.
>
> So the issues:
> For other than OS X, the result is not monolithic, in general.
> If forced to be, the path is not what it was in most debugging and
> testing.

The application bundle format is a great way to contain applications. If all
platforms had such a method it would be good. The method to achieve this
level of abstraction on Windows doesn't help if you can't install the
application for some reason.

> Oh, the application main stack is moved in the message path anyway.

This is one good reason to use a trivial splash screen to attach the engine
to.

Cheers

Monte