Re: gworkspace build error

[Matthias Klose]

Nicola Pero writes:
> 
> > > > So it seems that gworkspace tries to write into the gnustep user
> > > > dir during the build. Is this special to gworkspace, or a bug/feature
> > > > in gnustep-make? How can I avoid it?
> > > 
> > > Good question.
> > > 
> > > Maybe you can change the location of the user defaults in the restricted
> > > environment during the build (it should be possible by adding a .GNUsteprc
> > > in the user dir, or if you can't add a file in your home dir, by adding a
> > > .GNUsteprc in the GNUSTEP_SYSTEM_ROOT).
> > 
> > confused. the only place I am able to write is the builddir. So do I
> > have to set GNUSTEP_USER_ROOT to the builddir? GNUSTEP_SYSTEM_ROOT is
> > set, and is read only for me.
> 
> Do you mean you can't write in your own dir ? :-(
> 
> Anyway - here is a short explanation of how the location of the defaults
> is chosen.
> 
> The library will look for a .GNUsteprc file inside GNUSTEP_SYSTEM_ROOT,
> and read that.  A .GNUsteprc file is supposed to contain stuff like 
> 
> GNUSTEP_USER_ROOT=~/GNUstep
> GNUSTEP_DEFAULTS_ROOT=~/GNUstepDefaults
> 
> (the paths on the right hand side must be either absolute, or starting
> with ~, so that they can be expanded for any user easily and uniquely).
> 
> Then, it will read a .GNUsteprc file inside the user's home dir (which
> should override the system one [btw I'm not sure if overriding works in
> the current implementation]); this can contain the same options.
> 
> So, if you want to have your user defaults somewhere else on disk during
> the build (presumably a directory which you can write to), you need to add
> a .GNUsteprc file in your user dir to redirect defaults somewhere you can
> read/write.
> 
> If you can't do this, well we could try to add more flexibility ... such
> as specifying a .GNUsteprc file to use for that run in an environment
> variable, or a command line option ... but we need to think a bit to make
> sure we understand what your needs are, and that we are not adding
> ill-defined options.

hmm, a working workaround for now seems to set HOME to the builddir ...

        Matthias