discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSHomeDirectory() problems on windows


From: S.J.Chun
Subject: Re: NSHomeDirectory() problems on windows
Date: Wed, 23 Jul 2003 19:35:27 +0900 (KST)

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 <address@hidden>
  To: "S.J.Chun" <address@hidden>
  Cc: address@hidden,Roland Schwingel 
<address@hidden>,address@hidden,thisguyisi 
<address@hidden>
  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.
  
  
  




reply via email to

[Prev in Thread] Current Thread [Next in Thread]