Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows))

[Richard Frith-Macdonald]

On 6 Dec 2005, at 07:33, Sheldon Gill wrote:

> Richard Frith-Macdonald wrote:
> > On 6 Dec 2005, at 05:33, Richard Frith-Macdonald wrote:
> > > On 5 Dec 2005, at 23:07, Lloyd Dupont wrote:
> > >
> > > > > > Actually, I thought it was needed for deployment (esp. for  
> > > > > > MS-  Windows).
> > > > > >  If an was build with C:/GNUstep/System but has to be  
> > > > > > installed in
> > > >
> > > > it would be VERY nice indeed if you could simply put the   
> > > > GNUstep.conf file in the same directory as the dll to be found   
> > > > automatically.
> > >
> > >
> > > You can ... thats' the way (well, a major one of the ways) the  
> > > new  config file system is intended to be used on windows  
> > > (configure -- with-config-file=./GNUstep.conf).
> > >
> > > I've added some documentation for this in the filesystem  
> > > document  in the make package ... needs to be more extensive and  
> > > polished,  but it's a start.
> > > I'm also going to try to improve the configure scripts in make  
> > > and  base to try and get them to make better choices about where  
> > > to put  things on windows when you don't explicitly give them  
> > > instructions  with the various options like --with-config-file=
> > What IS the appropriate directory layout for distributing a  
> > gnustep  application along with all resources on windows?
>
> I think the answer is different for the two cases:
>
> 1) Stand-alone application
>
>   Program Files\NSoft\Amazing.app
>     \Resources
>     \Library
>
>   All executables in top layer. Current CVS doesn't support this.

Well, the make system doesn't install them in the top layer, but they  
can easily be moved (I suggested adding a trivial script to do it).   
The only real problem is if one executable wants to use  
NSSearchPathForDirectoriesInDomains() to find another executable.   
That's pretty rare though, so while it's something that needs to be  
addressed, I don't think it's a big issue.

> > Any better ideas?
>
> Yes, registry support.

When we were discussing this on the mailing list, we suggested/ 
queried the use of the rtegistry for the basic config, and someone  
said that the Microsoft recommendation was to use a config file  
rather than the registry for this kind of thing... so we opted for  
simplicity/consistency for now.

> For the stand-alone situation
>  - build base with configure --registry-key="Software\NSoft\Amazing"
>
>    The values in the key control things.
>
> This way we can have the executables and libraries in different  
> directories but not break anything.

?? I don't understand that.  How does using the registry make any  
difference? Does windows check a location in the registry based on  
the program name when launching a program, and look up the location  
of any DLLs to use with the program?

> There are also security and system administration benefits.

You mean that users can be prevented from modifying config stored in  
the registry, but can't be prevented from modifying files?