Re: Symlinks from Tools to Applications

[Christopher Armstrong]

Hi

On Thu, 8 Mar 2007 16:00:24 +0100 (CET), "Nicola Pero"
<nicola.pero@meta-innovation.com> said:
> > On Windows for example, I think that we should create a simple loader 
> > application that sets up the environment to locate the various framework 
> > and tool paths to locate relevant DLL's using registry settings for the 
> > GNUstep location, and then spawn the application. Much like a binary or 
> > script form of openapp. We could then create shortcuts to these and put 
> > them in the start menu. An alternative approach is a full-blown Explorer 
> > shell addin (caution needed as it requires COM and a MS compiler).
>
> I've been working on Windows in the past weeks ... and we're now far more
> advanced 
> than that ... ie once you have all your stuff compiled inside MinGW, you
> can take it 
> out of MinGW and use it directly as Windows native binaries (see the end
> of the 
> new README.MinGW).
>
> In particular, I just double-click on the .exe and it works. :-)
>
> And we use no registry, which is great as there are no conflicts if you
> have multiple
> installations.
>
> So, we don't need any shell scripts or wrappers or anything.

Okay I looked at the updated README.MinGW file. I never really gave
consideration for this approach as I was looking for something that
would allow multiple GNUstep applications on the one computer without
multiple copies of GNUstep. I guess this approach is pretty solid for
most standalone application developers, although we probably should look
at something a little more flexible for later on.

> PS: We still need lots of thoughts on how to best package things for
> end-users ... 
> eg, I'd personally like to have a 'binary/end-user' GNUstep installer
> that installs
> gnustep-base.dll, gnustep-gui.dll, etc in the standard Windows DLL
> locations ...
> (and no MinGW and no development environment) so that if I want to
> distribute 
> binaries of Gomoku.app for Windows (for example) I just need to compile
> it under 
> MinGW and then I can just distribute the resulting Gomoku.app binary
> folder as 
> a .zip file, without having to include all the gnustep libraries that
> will be 
> provided by the GNUstep installer. (and still, people would be able to
> start 
> Gomoku.app by just double-clicking on Gomoku.exe).

Another approach that I didn't mention in that email, that may
"simplify" things somewhat is to use the Windows resource compiler to
include simple resources such as .gorm files and icons and write them
directly into a dll. NSBundle would obviously be modified to load
resources in this manner, especially if the "bundle" it is handed is a
.dll file. Only disadvantage is that every update to the bundle requires
a reship of all the images, so this approach is really only useful in
*very* controlled environments.

Yet another, but more disturbing ;-) approach for applications is to
compile each application into a .dll, and shove a small executable in
the .app wrapper to dynamically locate all the appropriate .dll paths,
add them to the dynamic search path (windows LD_LIBRARY_PATH
equivalent), and then load the application .dll. Gaim on Windows uses
this approach; the only disadvantage is that it is more of a nusiance
with GDB, but I guess we just make it optional if people want to use
this approach. The obvious advantage is that an application can be moved
around, and just locate any information it needs from the registry and
GNUstep.conf file (an .exe can do anything we really want it to do). It
could even link against frameworks without having to copy the files into
the Library/Tools directory for each framework, as we just insert the
correct framework version into the dll search path.

Regards
Chris

--
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au