← Back to team overview

kicad-developers team mailing list archive

Re: Global Search Paths and fp-lib-table Entries?

 

On Mon, Nov 3, 2014 at 8:25 AM, Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>
wrote:

> Hi all,
>
> I am still trying to find out/optimize where what is being loaded from
> (especially for OS X).
> In common/kiface_i.cpp the global search stack for pcbnew is initialized
> with
>   …/modules
>   …/modules/packages3d
> with “…” being some OS specific base paths.
>
>
What you see there is basically legacy code which needs some careful
thought and eventual cleaning up. Once upon a time KiCad by default
searched for schematic symbol compilations in SOMEDIR/library, footprint
compilations in SOMEDIR/modules, and 3D models  in
SOMEDIR/modules/packages3d. Since Dick committed his work on the 'pretty'
footprints and later on the github plugin, the scheme for finding
footprints had changed dramatically. For various reasons people still set
'KISYSMOD' to point to the old 'SOMEDIR/modules' directory as if we're
living in the past, but the reality is that the footprint management scheme
has moved into the future and the behavior of the library symbol management
and 3D model management needs to be analyzed and cleaned up. There have
been many discussions on this in the past but no one has put any time into
it yet.


> The global search stack seems to be used for eeschema libraries and I also
> found a piece of code which made me think that it is also used for loading
> 3D-models.
>

That would only be an illusion; the symbol library code and 3D model
loading code are not coupled - at least not intentionally - and in
principle they should be completely independent even if they shared the
same framework for file management.


> However, fp-lib-table doesn’t seem to use it but only the path given for a
> library in fp-lib-table itself (maybe with some environment variables).
>
>
Yes - see the note above about changes since Dick introduced the pretty
format, fp-libtable, and github plugin.


> Am I missing something or does loading of modules currently ignore the
> global search paths?
> If I have something like
>     (lib (name Conn)(type Legacy)(uri Connectors.mod)(options "")(descr
> "Connectors"))
> in my fp-lib-table and Connectors.mod is in my
>  …/modules
> folder it doesn’t get loaded...
>
>
What you describe there is legacy behavior, not at all the behavior of
fp-libtable. In fp-libtable it is best to provide the full path. In
examples of legacy support, 'KISYSMOD' (it can be any environment var.
though) is used and table entries look something like this:

    (lib (name Conn)(type Legacy)(uri ${KISYSMOD}/Connectors.mod)(options
"")(descr "Connectors"))

In that case 'KISYSMOD' would be set to point to your SOMEDIR/modules
directory.

- Cirilo


> Regards,
> Bernhard
>

References