[Bf-committers] relocatable blender on linux

Campbell Barton cbarton at metavr.com
Tue Jul 24 16:12:52 CEST 2007


Campbell Barton wrote:
> GSR wrote:
>> Hi,
>> cbarton at metavr.com (2007-07-22 at 0721.38 +1000):
>>> GSR wrote:
>>>> Hi,
>>>> cbarton at metavr.com (2007-07-22 at 0128.04 +1000):
>>>>> At the moment blender on linux always points to ~/.blender/
>>>> Notice that it also points to ~/.B.blend and other files in ~/. There
>>>> is no unified dir and some other data is not truly compatible (quick
>>>> example is .B.blend). IMHO one of the first things to do would be to
>>>> unify all conf inside a dir and clean up the hidden issue (hidden
>>>> files inside it, does anybody has a good explanation?).
>>> Im not against relocating .B.blend etc but I think its a separate issue, 
>>> and no reason to do it first.
>> OTOH, I think it is pretty much related to the issue, as you want to
>> know what binary is really running to do things accordingly. It is not
>> a small issue, it needs to cover the issues of multiuser, portability
>> and versioning, to just mention the three that quickly come to mind,
>> instead of go with no plan and change and back step when issues pupop,
>> even if they were there from start.
>>
>> Sometimes the data is compatible, sometimes not. Aside from ~/.B.blend
>> (already problematic, even if just when you want to run a really old
>> version), there are ~/.Bfs, ~/.Blog and ~/.Bfont, and inside $config
>> there are things like locale/ or scripts/ which have problems with
>> different releases. Currently things get spill over or duplicated in
>> ~/, ~/.blender/ and $package/.blender/ (and $package/plugins/, but
>> those are just source, even if they could be provided ready to run).
>>
>> For example, what to do if you have no write access to
>> $package/$config/bpydata/ because $package was unpacked by other user?
>> Or is system wide install (no write access and maybe even path is
>> unrelated to $binary)? Or what policy is taken for locale/?
>>
>> The issue is not just relocating some inside, it is also relocating
>> things outside as needed and figure what is version dependant and what
>> not (and handling what was not but at some point became). In
>> conclusion, it is cleaning the problems for once, not just for
>> scripts/.
>>
>> GSR
> 
> IMHO all data can be relocated (as it works in windows)
> 
> on initialization there can be a 'use_home_dir' bool thats set based on 
> looking at the files where the blender binary is, if they dont exist 
> then use the home dir.
> 
> 
> A rework of where ~/.Bfs, ~/.Blog and ~/.Bfont are stored is ok but Id 
> prefer to do this incrementally/
> 
> We can make sure binary relocate ability works on all platforms as a 
> first step,
> then re-arrange the files as a second.
> 
> Of course its fine if somebody wants do go and write proposals for a new 
> way of working and implement it all in one go, but I think thats less 
> likely to be completed since it includes a fair bit of OS specific 
> functionality from BSD, Solaris irix etc.

If all we need is to run blender from an extracted tar.gz with its own 
files, maybe we could just do what firefox does and have a shell script 
which sets up the BLENDERHOME and blender-bin as the binary,
The advantage with this is its very little effort and it will work in 
all unix's.


More information about the Bf-committers mailing list