[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG prob
From: |
Sheldon Gill |
Subject: |
Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)) |
Date: |
Wed, 07 Dec 2005 09:15:50 +0800 |
User-agent: |
Mozilla Thunderbird 1.0.6 (Windows/20050716) |
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
- Re: GNUSTEP_USER_CONFIG problem (Windows), (continued)
- Re: GNUSTEP_USER_CONFIG problem (Windows), Lloyd Dupont, 2005/12/05
- Re: GNUSTEP_USER_CONFIG problem (Windows), Richard Frith-Macdonald, 2005/12/06
- Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Richard Frith-Macdonald, 2005/12/06
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Lloyd Dupont, 2005/12/06
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Richard Frith-Macdonald, 2005/12/06
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Lloyd Dupont, 2005/12/06
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Richard Frith-Macdonald, 2005/12/06
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Lloyd Dupont, 2005/12/06
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Sheldon Gill, 2005/12/06
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Richard Frith-Macdonald, 2005/12/06
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)),
Sheldon Gill <=
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Lloyd Dupont, 2005/12/06
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Sheldon Gill, 2005/12/06
- Re: Best distribution layout on mingw? (was Re: GNUSTEP_USER_CONFIG problem (Windows)), Lloyd Dupont, 2005/12/06
Re: GNUSTEP_USER_CONFIG problem (Windows), Lloyd Dupont, 2005/12/05