[Bf-committers] Accessing Files (new config locations, fopen wrapper, etc)

[GSR]

Hi,
brecht at blender.org (2010-04-02 at 1317.21 +0200):
> Also, resolving a file path with // in it depends on which .blend file
> the datablock is linked from, I don't think the proposed API takes
> this into account.

Thanks for pointing that, I will have to see how to handle that case.

> > The functions getSystemDir and getUserDir are added to GHOST, which adds
> > a pretty nasty dependency to BLI_blenlib - have you any idea on how to
> > solve this?
> 
> I also don't really see the reason to do this, there is already
> platform abstraction code in blenlib. If mac needs an objective-c .m
> file in blenlib I don't see why that wouldn't work. I'm not against
> GHOST becoming a platform abstraction library but this seems like a
> strange exception.

GHOST looked like the place where to put it, probably because it has
plataform dependant things like clipboard or timer code, so calls to
user info looked natural when Plisson suggested it (& I agreed).

> > There are quite a few functions that need consulidation: BLI_where_am_i,
> > BLI_where_is_temp, get_install_dir,  BLI_gethome_folder,
> > BLI_gethome_system, BLI_gethome_user and for Windows there's also
> > BLI_getInstallationDir...
[...]
> Agreed, probably BLI_bfile_fopen makes most of the calls to these
> obsolete, but e.g. scanning a directory for python scripts should use
> consistent functions.

Python should, no doubt, get access to the system, but first the base
has to get rolling.

> * I don't really see the point of the "environment" file. In order to
> install blender in a custom location you would already need to set
> BLENDER_SHARE as an environment variable, why not simple set all of
> them then? In other cases it could just use defaults hardcoded in the
> executable. Another thing is that this file is platform dependent, so
> having the defaults hardcoded means we don't have to set up all the
> build system to copy the right files. It also means we can run the
> blender executable by itself, which is a feature I would like to keep.

Changes to build system is a small problem in the whole thing, it
should be easy to fix. The user file would make it possible to run the
executable by itself, as well as if you say you would prefer to set
them differently (script, I guess, instead of a config file), the
thing just moved from one place to another.

> Basically I think this gives you two ways to do the same thing, and it
> may be more confusing than helpful, actual environment variables work
> well enough, we don't need to add a configuration file?

The idea was that people would not had to mess with launchers or
scripts in most common cases. Editing a file that is part of Blender,
with a simple syntax that could even be rewritten from inside Blender,
looked easy compared to the nightmares I remember every time you tell
someone to set envs in MSWindows (go somewhere unrelated, add one by
one, forget where it was in a week...) or even Unix (launching from
different shells and then things failing...), for example.

Let me explain how the system reached the current state: first it was
going to be C strings, then someone asked for env var support, so
instead of having to keep things in sync (merge vars values into
whatever was used to store the C strings, then export them before
forking childs), all became envvars. This keeps one syntax for all
things, easy copy and paste from config and into scripts (but not
forcing people to edit and maybe break the launcher script), and
simplifies C code.

> * It is not clear to me what the point is of having BLENDER_VERSION as
> an environment variable (or Blender setting any environment variable
> when it starts up). It would be set only while Blender is running, and
> for e.g. python scripts it's accessible in other ways already. Just
> store it as a variable somewhere in the code or use the internal
> #define?

If you fork a child process, that process knows what Blender version
launched it. It will get the full set of BLENDER_* vars, to be exact,
for full pipeline integration.

> * I can see wrapping file open/close is useful but I don't see the
> purpose of wrapping read/write if you provide access to the FILE
> pointer anyway. Otherwise you end up with inconsistent code or
> wrapping all the functions, like fseek, fprintf, ferror, feof, fputs,
> .., better to not try this in my opinion.

Wrapping writes means we can check for errors and act accordingly,
because people sometimes forget to do it. And even if they do, then
some kind of abort call would be needed so, on close, the data is
discarded. Giving access to FILE* is an extra, not the norm (and as
such, whoever plays with it, keeps the parts if something breaks).

> * Do we have a good reason to support both BLI_bfile_fopen and
> BLI_bfile_open syntax? Might just be historical reasons and we can use
> fopen syntax everywhere?

We could go with fopen only if you want, open calls would need to be
translated, but IIRC they sometimes differ, so the translation would
go with less features (O_NOFOLLOW, S_IRWXU, etc). So that is why I put
both.

GSR