← Back to team overview

kicad-developers team mailing list archive

Re: 3D modules path strange behaviour

 

On 8/4/2014 12:02 PM, Nick Østergaard wrote:
> 2014-08-04 16:00 GMT+02:00 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.
> 
> Well, that is the thing... it does not work for me to define a
> KISYS3DMOD environment variable. I does not seem to be defined anywere
> already on my sytem, when I echo $KISYS3DMOD it is empty. But if I try
> to export it in a new terminal session as "export KISYS3DMOD=foo", I
> do get foo when I echo it -- as expected, but kicad do not catch this.
> I open pcbnew from the same terminal as I set the env var in, then add
> a random footprint to the canvas, open the properties for it, then I
> go to the 3D settings tab, here the path is still listed as
> "/usr/share/kicad/modules/packages3d", which I expected to be "foo". I
> am on Archlinux, with 5041.

Environment variable defined in a shell session are only visible to
applications launched from within that shell session.  It has to be
defined before or when you log in as a user to always be visible.
Typically you would define it in ~/.profile or for all users in one of
the scripts or your own custom script in /etc/profile.d.  Although this
can vary from distro to distro.

> 
> Also in that regard I cannot use custom enviroment variables in the
> "3D Shape Name" list IIRC. (at least last time I tested, I did not
> test this now, I can do that if requested)

This may be a limitation of the 3D software design.  I didn't write any
of this so I cannot say one way or another if 3D model file paths accept
the %ENV_VAR%/rest/of/path notation.  The footprint library table will
accept any environment variable.

> 
>>> 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.
>>
>>
>>
>> _______________________________________________
>> 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
> 




Follow ups

References