kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/4/2014 7:34 AM, yann jautard wrote:
> 
> Le 04/08/2014 10:57, Nick Østergaard a écrit :
>> 2014-08-04 10:00 GMT+02:00 yann jautard <bricofoy@xxxxxxx>:
>>
>>> And also what about the path to the 3D models directory that cannot be
>>> edited ? Is there a place where we can edit it ?
>> That is a bug I believe, it is supposed to be set with an environment
>> variable, but I guess it is just not catched anywhere.
> 
> I noticed also we can't edit the KIPRJMOD and KISYSMOD variables related
> to the library table. I'm not sure that this should me environnement

You can edit KIPRJMOD, KISYSMOD, AND KISYS3DMOD.  They are environment
variables so you have to edit them either system wide or user specific
depending on your needs using your preferred method for editing
environment variables on your system.  You are not obligated to use any
of these variables.  You can specify the full path and/or file name
(depending on the library type) for each library.

> settings. In my opinion they should be project-specific, and stored in
> the project file.  ( Like it was before the fp-lib table, I think. )

You can use project specific footprint library tables if you prefer
rather than using the global footprint table.  This is fairly well
documented in both the CvPcb and Pcbnew reference manuals.

> Maybe the KISYS3DMOD variable should also be added to the library table
> window, and can be edited there ?

KISYS3DMOD does not impact the loading of footprint libraries so has no
context in the footprint library table.  It is only used for loading 3D
models.  Putting it in the footprint library table editor would be
confusing.

> 
> Also I don't feel right about those variables relative to library tables
> : why only two variables ? I think there should be the same buttons
> under the variables list than under the libraries list, so we can add

You are not limited to these 3 variables.  You are free to define as
many environment variables as you like or until you system runs out of
memory.  I use KILCLMOD to point to all my custom libraries.

> other research pathes. Like in eeschema.
> 

This will not happen.  The path look up method is so broken that it's
hard to know where to begin to explain it.  There have been at least a
dozen bug reports due to wrong footprints and components being loaded
due to path search order issues.  This has been discussed many times and
the issue still exists in Eeschema.  You can search the bug and mailing
lists and find plenty of discussion about this issue.