kicad-developers team mailing list archive

[Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>]

Hmm… I may be wrong, but I don’t think that fp-lib-table introduces $KISYSMOD.
Yes, it is used in fp-lib-table, but IMHO it is *not* defined in there.

This is not about discussion pros/cons of environment variables… we had that already.

It is just the question if I should be able to point KiCad to my global fp-lib-table by using $KISYSMOD, $WHATEVER, etc. wherever those data comes from (environment variable, config file, etc.) instead of having a single hard-coded value.

In fact, even if currently environment variables are used… just do not define them.
With the changes Wayne made an initial value is assigned and saved. If you want to change them just edit them in kicad_common in the preferences folder.
That’s really easy (well, no GUI yet as far as I have seen…) and I don’t have to care if KiCad internally uses (local) environment variables for transport of the information.


Regards,
Bernhard


> On 22.02.2015, at 19:59, Simon Richter <Simon.Richter@xxxxxxxxxx> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am 22.02.2015 um 17:40 schrieb Bernhard Stegmaier:
> 
>> Wouldn’t it make more sense or be more consistent to have it in 
>> $KISYSMOD where all models are?
> 
> No, the fp-lib-table introduces $KISYSMOD -- ideally there shouldn't
> be any hard dependencies on it.
> 
> - From a software distribution point of view, environment variables are
> a nightmare:
> 
> There are users who don't know how to manipulate them, which means we
> need a mechanism to set up the environment variable.
> 
> On Windows, there is an API for that, but we need to take into account
> that users could change the variable, which adds complexity into the
> installer.
> 
> On Unix, there is no way to make a variable persistent, so we need a
> wrapper script (and even if there was a way to make the change
> permanent, it would mean that the user would have to log out and back
> in after installing the package).
> 
> In my opinion, we should get rid of the variables sooner than later,
> and provide a mechanism for a system-wide default (that uses an
> absolute path to point to some models that came with the same
> installer), a per-user override (as we have now, but which becomes
> optional then), and a per-project override (currently we can only add
> paths, but not remove them).
> 
> We don't really gain much flexibility from the environment variables
> either. Right now, the Windows installer creates a batch file that
> (incorrectly) sets up the variables and runs the main program, and
> correcting a path (e.g. when something in GitHub changes) still
> requires either user action or an update script (that becomes more
> complicated now, as we've moved from a descriptive configuration
> format to an imperative one, so the updater is faced with the halting
> problem).
> 
>> Using $KISYSMOD as base for the global fp-lib-table would also 
>> allow to switch between different libraries just by changing 
>> $KISYSMOD.
> 
> Ideally, the project's fp-lib-table would be used, and the system
> fp-lib-table is just a reasonable default.
> 
> Simon
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iJwEAQECAAYFAlTqJv4ACgkQ0sfeulffv7s0TgP/b9sbFoHRYeVPOnFjhpyy1unE
> O+IJW9x63UV9zeW/h+u/Z3wCMlmzs7rFoc/hwxqsesg6QtDvsdx/9FC9ZnLWdshi
> 8IPAXANU+PvMJPhYRJj3qGnYaIu9Istck3GVC60zG6Ze9LLP/6xszNGEn2cBAtQ3
> cACyXYhKwlc713fOdzE=
> =lnRf
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp