Re: NSHomeDirectory() problems on windows

[S.J.Chun]

I also encountered the build problem. My solution is that form building I just 
set GNUSTEP_USER_ROOT to proper
one.

  ----- Original Message -----
  From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
  To: "S.J.Chun" <chunsj@embian.com>
  Cc: gnustep-dev@gnu.org,Roland Schwingel 
<Roland.Schwingel@onevision.de>,discuss-gnustep@gnu.org,thisguyisi 
<thisguyisi@earthlink.net>
  Sent: Wed, 23 Jul 2003 08:58:30 +0100
  Subject: Re: NSHomeDirectory() problems on windows

  
  On Wednesday, July 23, 2003, at 08:51 AM, S.J.Chun wrote:
  
  > But the problem is that in Windows XP, %HOMEPATH% also contains 
  > spaces, for my case, %HOMEPATH% is
  > \Documents and Settings\NeXT, so %USERPROFILE% or %HOMEDRIVE% 
  > %HOMEPATH% are equal and I
  > think this is valid result(why two should have different value?). I 
  > think we have two kind of choices, one is using
  > operating systems native home directory mechanism or create our own 
  > mechanism which should be platform
  > independent.
  >
  > PS)
  > My opion is using OS's native mechanism. Why GNUstep should not work 
  > on space contained directory or path?
  > Also, I can just create directory or path which contains spaces. So, 
  > supporting is more appropriate choice than
  > giving up.
  
  It seems that it's impossible to support it for building software 
  because
  the make program is designed on the assumption that spaces do not
  appear in paths.
  
  I guess we could remove the check from the base library, so a home
  directory containing a space would work at runtime, even though any
  attempt to build software with that setting would bomb.  Perhaps that
  was what Nicola meant to imply when he said
  
  > Make (not gnustep-make, I'm talking of make itself) has been designed
  > thinking that filenames would never contain spaces.  It's an implicit
  > design assumption which can't be fixed.
  >
  > On the other hand, this issue should only arise when compiling, not 
  > when
  > using the software.