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

[Sheldon Gill]

Richard Frith-Macdonald wrote:
> 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).   

Actually, I'm thinking it may be better and easier to have -make only handle 
the normal shared runtime case. We then have a 'build stand-alone' script which 
will package the application appropriately.

I did that a while ago with a post-amble. Worked well and made it easy to build 
an installer.

> The only real problem is if one executable wants to use  
> NSSearchPathForDirectoriesInDomains() to find another executable.   

Yes, but you'd normally rely on bundles.

> That's pretty rare though, so while it's something that needs to be  
> addressed, I don't think it's a big issue.

Not that big IMHO either. I can think of a number of ways to handle it.

> > > 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.

I'm not advocating dropping the conf file on windows but rather adding back the 
registry support. Yes, I should have applied the updates but was focusing on 
other issues. I knew the registry support was working...

Anyway, MS recommendations change depending on which documentation you're 
reading. There are differing strategies available so it gets somewhat 
confusing. Different issues also get confused in this. (like DLL versioning)

> > 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?

I meant that we can have different directories without a pre-determined 
relative relationship. It'd support installations spanning drives.

There is a mechanism to change DLL use per application BTW.

> > 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?

Users can be prevented from modifying specific *values* stored in the registry. 
More of a benefit for defaults than conf.

Multiple machines can more easily be centrally administered.

The application directory and all files can be made effectively 0555 on 
install. (with SYSTEM having wrx)


Regards,
Sheldon