← Back to team overview

kicad-developers team mailing list archive

Re: fp_lib_table

 

On 12/08/2012 11:37 PM, Dick Hollenbeck wrote:
> Wayne,
>
> I got some hours in on the fp-lib-table branch today.  I added the
> FP_LIB_TABLE::ROW::description field, and made the parser handle some elements in any
> order, with the capability of having optional table columns, i.e. s-expression elements. 
> The (options) are now optional.
>
> I've got a better idea for presenting platform independent (uri LIBPATH)s, for the case
> where LIBPATH is local (local = not on the internet).
>
> I'm thinking we should movefrom the %P path substitution to a full environment variable
> capability, in the (uri LIBPATH).
>
> e.g.
>
> (uri ${KISYSMODS}/passives.mod)
>
> This might be embedded in a row like this:
>
> (lib (name passives)(descr "R/C Lib")(type KiCad)(uri ${KISYSMODS}/passives.pretty))
>
>
> When loading the library by nickName, i.e. (name), we'd simply do environment variable
> substitution on whatever we find in (uri), no limitsas to which environment variables or
> how many.   However for the system library table, the one distributed with pcbnewand
> reflecting the kicad supplied libs, we'd have a special environment variable, say KISYSMODS.
>
> The purpose of something like KISYSMODS is to achieve a platform independent (cross
> platform) system library table that comes with the kicad package, since it can be used to
> abstract the "system standard library location"across platforms.  Think of it as a leading
> path fragment.
>
>
>
> In said bzr branch, see:
>
>
> 1))))
> pcbnew_config.cpp, line 97.  This code is scaffolding, to be tossed in the future, but
> shows that the parser is working on these tables.
> Also notice the prj table uses a custom environment variable that would never be mentioned
> in kicad documentation, KIUSRMODS, since this was put in there
> by someone who runs kicad on both Windows and Linux and wants not to have to futz with his
> project specific fp_lib_table.
>
>
>
> 2))))
> const wxString FP_LIB_TABLE::ExpandSubtitutions( const wxString aString )
> {
>     // We reserve the right to do this another way, by providing our own member
>     // function.
>     return wxExpandEnvVars( aString );
> }
>
>
> But what about the guy who did not set his KISYSMODS environment variable?
> At program startup, we can do:
>
> --- If KISYSMOD is not in the evironment, then push it into the environment with a value
> according to old school platform specific path fragment.  On linux that would be
> /usr/local/share/kicad/modules/, and similar for Windows.  This is just a safety net in
> the case where KISYSMODS has not been set.
>
>
> I am still struggling with the number of tables to have, 2 or 3.  And I can even make an
> argument for 4in the future.
>
> Here are my arguments, and the order of search precedence:
>
>
> 1) "project specific" table,which is tied to a projectonly.
>
> 2) "personal" table, which is cross project.  (This is the one I would use mostly.)



Woke up this morning with a reversal back to my original thinking, which is that 2 tables
are enough for the moment to moment search stack.

The "project specific" and the "personal" (= global) seem to be enough for me.   This
gives a better handle on policy enforcement, namely the ability to exclude libraries by
simply leaving them out of both tables.

There will be a project specific table for each project, with only one in play at any time
(since only one project is in play), and then the personal-global table is always in play.

I will try and make it easy to import another table into the current one in the UI.  This
addresses the need to stay in tune with the distributed standard libraries, if someone so
chooses.
The tables should also be easy to edit with a text editor, and they should be stored in
obvious places, so this can be done.


To summarize my thinking and intentions at this time:


1) The search stack is to have two tables, and they are searched in this sequence: a)
project then b) personal-global, for library nicknames and footprints.
Library nicknames must be unique within a single table.  If a nickname occurs in multiple
tables, and it can, the top most table masks out the bottom table's row with the same
nickname, and it is as if it was not present in the lower table.  The full set of
libraries after this masking operation "defines" those libraries in play at any time. 
Footprint searches never reach masked out libraries.


2) Any environment variables can be used in the (uri LIBPATH) element of any table.


3) Environment variable KISYSMODS is special, and will be injected into the environment if
not present at program startup.


=================================================

Achievable Objectives of this Strategy:


a) Two personal work modes are addressed:

  i) the designer who likes to use personal libraries accross projects can now start a new
     project and not mess with library setup, simply by pre-establishing a single
     personal-global table.

  ii) the designer who likes to use project specific libraries for each project.


b) The full abstraction of the PLUGIN API is brought in.


c) It becomes possible, now or in the future, to mate a lib nickname with a footprint
name, yielding a full individual footprint specification that is unambiguous in the
context of a known set of library tables.





Follow ups

References