Re: Path issues on Win32

[Stephen Brandon]

On Thu, 11 Oct 2001 09:36:56 -0600
 Adam Fedor <fedor@doc.com> wrote:
> Stephen Brandon wrote:
> 
>  
> > Personally I dislike the cygwin style //c/ and /cygwin/
> > paths, because they rely so heavily on cygwin being
> there,
> > and it gets really confusing at times to work out which
> > utilities/apps will interpret them in the intended
> manner.
> > That's why I have moved to using c:/ style paths in my
> > GNUSTEP_*_ROOT env vars.
> > 
> > In any case, I want the apps and programs I am working
> on to
> > work on machines without cygwin - that's why I am using
> > MinGW on top of cygwin, to remove the cygwin
> dependency.
>
> That sounds great and more consistent. However, a lot of
> environment 
> variables are used, for instance, to find/store resources
> - is there a 
> Windows location that those could be stored? All the
> GNUSTEP environment 
> variables are (or could be) available at compile time, so
> perhaps if the 
> env varialbes aren't available at runtime, they could
> default to the 
> compiled in values. Probably this should go in
> NSProcessInfo (i.e. it 
> should have a list of env variables that must be set,
> setting them from 
> compiled in values if necessary).

I think that we can largely standardise the env vars to a
set of hard coded defaults. Of course all versions of
Windows allow env vars to be set for the system too - and in
a multi-user setup on NT/2000 these are stored via the
Windows registry for individual users, and are easily
editable via GUI tools.

Much of the env var use is in compilation of GNUstep rather
than runtime.

What we could do in NSProcessInfo is (if the env vars don't
exist) get hold of $SYSTEMDRIVE and assume that the GNUstep
tree is built as $SYSTEMDRIVE/GNUstep/[System|Local|Network]/.
That takes care of GNUSTEP_ROOT, GNUSTEP_LOCAL_ROOT,
GNUSTEP_NETWORK_ROOT, GNUSTEP_SYSTEM_ROOT, and
GNUSTEP_MAKEFILES (GNUSTEP_SYSTEM_ROOT/Makefiles).

That leaves GNUSTEP_USER_ROOT which is hopefully equivalent
to $USERPROFILE/GNUstep, or $HOMEDRIVE/$HOMEPATH/GNUstep
(can someone with win95/win98/winnt please check the
existence and typical contents of $USERPROFILE, $HOMEDRIVE
and $HOMEPATH?).

The other GNUSTEP env vars are GNUSTEP_FLATTENED (which
doesn't matter too much), GNUSTEP_HOST, GNUSTEP_HOST_CPU,
GNUSTEP_HOST_OS and GNUSTEP_HOST_VENDOR. A quick grep
through make/Source/*.m and gui/Source/*.m does not come up
with much on them except in NSBundle, where it's more
compile-time than runtime related.

I think we can do as you suggest and compile these in as
defaults at compile time. Or at least those which would be
used to create paths into bundles (eg
libgmodel.bundle/ix86/mingw32/gnu-gnu-gnu/libgmodel.dll).

> > (b) that absolute paths without drive letters should be
> made
> > relative to either the current drive (ie look at
> current
> > directory) or $SYSTEMDRIVE. Suggestions please?
> > 
> 
> Probably ok as a default. Although it depends on where
> you are most 
> likely to get absolute paths w/o drive from. I'd imagine
> this is mostly 
> from internal resources and could probably be fixed by
> being more 
> careful about how we handle paths internally.
> 
> Can you tell me how you modified GNUstep.sh to use c:/
> style but still 
> set up the PATH correctly? I think that would help a lot
> if that was 
> straightened out. Also you need to fix the def of
> GNUSTEP_USER_ROOT - I 
> think that would fix the make_services problem you have.

Yes, it would fix that problem. I'll look more closely at
that.

My GNUstep.sh code uses a sed script to convert
^[a-zA-Z]:/.* variables to /cygdrive/ style paths, but a
better way is to use the cygpath tool provided with cygwin,
so I'm going to rewrite my GNUstep.sh.in and I'll send it to
bug-gnustep.

Cheers,
Stephen Brandon
stephen@brandonitconsulting.co.uk