kicad-developers team mailing list archive

[Moses McKnight <moses@xxxxxxxxxxx>]

Hi Lorenzo,

I'm not sure I understand your objections.  The proposal as I understand it is 
not to eliminate environment variables, but to *add* the ability to set 
variables from the GUI that would be stored in the 'kicad_common' config file. 
I had even thought of possibly setting them as environment variables using 
setenv() or the wx equivalent.  That is how the 'project directory' variable is 
set as you mention, and may be the easiest way to implement this.  AFAIK env 
vars set that way are only valid for that process (and maybe the instance of the 
shell it was called from?).

I'm particularly thinking of the variables used in the fp-lib-table.  The user 
may want to create multiple new ones for footprint libraries in different 
places.  And the main goal is better usability.

I don't think those articles were against *all* env vars either, although the 
first one doesn't make that real clear.  They are basically arguing against 
using environment variables for application settings.

Moses

On 09/03/2014 02:27 PM, Lorenzo Marcantonio wrote:
> On Wed, Sep 03, 2014 at 02:01:06PM -0400, Wayne Stambaugh wrote:
> > http://peterlyons.com/problog/2010/02/environment-variables-considered-harmful
> >
> > http://www.insectnation.org/howto/environment-variables-considered-harmful
>
> I fully disagree with both of them :D (except for the bit about the
> security issues, but that's applies only for badly written software)
>
> When you have multiple environments on the same system, do chroot
> jailing or simply need to have compatibility libraries you *need*
> environment variables. Multiple version of the same program often can
> cohexist using variables (like the JRE, everyone seems to be shipping
> his own...)
>
> If only to find the configuration file/directory to use this time :D
>
> And doing like python does looking from the executable and chasing the
> filesystem structure is hell when you have symlinked directories: but
> just set PYTHONHOME and everything works fine...
>
> Other example: TMPDIR. These days /tmp is usually a tmpfs (a kind of
> ramdisk). What would you do for a process needing, like, a huge
> temporary file? run it with TMPDIR pointing somewhere else (probably
> /var/tmp or $HOME/tmp, depending on how you are partitioned)
>
> Back to kicad: AFAIK the env vars are used to make possible moving from
> a machine to another one, since the project is *not* self contained.
> While libraries could be usually found on /usr/share/kicad (I think),
> that's not necessarily true. On Windows, for starts, conventions are
> differents. I, for example, have libs on $HOME/cvswork/kicad-libs.
> That's the reason for having them. IIRC there is another expansion set
> to the 'project directory' to allow pointing to project-local resources.
>
> It's true that you *could* set all these paths in a config file (and
> wouldn't be a bad idea, either). But at the end you'll need something
> like KICAD_CONFIG (defaulted to something like
> $HOME/.config/kicad/env-config) to supply the path of the config file to
> use :D I have both stock subversion kicad and my customized build, so
> settings and directories are different. How would you handle this
> without at least one variable?