kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

> I built KiCad a few times on Ubuntu and Arch, but never with python scripting.
> 
> I will give this a try, ask if I have questions, and keep you updated of my progress.

Thanks again.  To get kicad scripting build, here are some things from memory:

install:
  python-dev
  swig
  [maybe others]


use "ccmake ." (sic) in out of tree build directory to select

KICAD_SCRIPTING ON
KICAD_SCRIPTING_MODULE ON  (probably not mandatory)
KICAD_SCRIPTING_WXPYTHON (mine is OFF, yours can be ON or OFF)


There is a script in <kicad_src>/scripts/make_global_table.sh

This can be used as an example on how to automate the whole shebang.

In fact, you can even have it generate your

   ~/fp-lib-table

file by adjusting it to use "KiCad" plugin type, not "Legacy" and to teach it where your
*.pretty dirs are in the uri slots.

Your *.sh script can call the python script with consistent arguments, and save you some
grief.  Then you can be a hero and we'd probably take your script into the project under
scripts/*.

Thanks,

Dick




> 
> 
> On Thu, Sep 26, 2013 at 12:25 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
> <mailto:dick@xxxxxxxxxxx>> wrote:
> 
>     On 09/26/2013 11:14 AM, Dick Hollenbeck wrote:
>     > On 09/26/2013 10:52 AM, Carl Poirier wrote:
>     >> Hi Dick,
>     >>
>     >> I neither read the whole thread nor played with pretty yet, but if the steps to convert
>     >> the libraries are fairly straightforward, I can volunteer to do it. I did however
>     create
>     >> many libraries in the old format so if needed, I will be able to validate the
>     conversion.
>     >>
>     >> If you agree, please write down the steps required for the conversion and I will do it.
>     >
>     > Please tell me about your kicad environment:
>     >
>     > a) are you buiding your own?
>     >
>     > b) platform?
>     >
>     > c) have you built with python scripting yet?
>     >
>     > If c) is yes,
> 
> 
>     bzr co bzr+ssh://bazaar.launchpad.net/~kicad-lib-committers/kicad/library/
>     <http://bazaar.launchpad.net/~kicad-lib-committers/kicad/library/>  legacy
> 
>     To get all the libraries *as of today*, buy you maybe have already done this.
> 
>     If so, then it is simply
> 
>     $ cd legacy
>     $ bzr up
> 
>     to get today's libraries.
> 
> 
>     > then try reading the instructions at the top of
>     >
>     >    <kicad_src>/scripts/lib_convert.py
>     >
>     > Me no python guru.
>     >
>     > Step 3) is the actual conversion.  The smd_dil would be replaced for each library.  In
>     > this example there, smd_dil.pretty is actually a subdirectory.  The *.kicad_mods will go
>     > into that directory.
>     >
>     > This suggests having a master directory above that, say called pretty_footprints
>     somewhere
>     > to stage this work.  In there you would generate a series of *.pretty dirs, one for each
>     > library.
>     >
>     > Then build kicad with FP_LIB_TABLE support.  Create table rows in
>     >
>     >    pcbnew -> Preferences -> Library Tables.
>     >
>     > One row for each *.pretty directory.  This table can be copied to and from a spreadsheet
>     > for editing.  Select a region, righ mouse click, paste into a spreadsheet.  Get it
>     right,
>     > copy it back.  The type should be "Kicad" for pretty libraries.  The Nickname can be
>     > anything, typically the directory name without .pretty extension.
>     >
>     > Go into the module viewer, do some sampling, see your pretty footprints.  Establish
>     > confidence or talk of problems.
>     >
>     > Thank you.
>     >
>     >
>     >>
>     >> Carl Poirier
>     >>
>     >>
>     >> On Thu, Sep 26, 2013 at 10:39 AM, Dick Hollenbeck <dick@xxxxxxxxxxx
>     <mailto:dick@xxxxxxxxxxx>
>     >> <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>> wrote:
>     >>
>     >>     I checked the size of our largest footprint library and when zipped it scrunches to
>     >>     70kbytes.
>     >>
>     >>     This was not pretty, but legacy.  But I don't anticipate a noteworthy
>     difference in size.
>     >>
>     >>     Therefore the concept of getting 70kbytes in one https://github.com hit seems
>     reasonable
>     >>     even with country folks like me with slow internet access.  My internet speed
>     is only
>     >>     160bytes / second.  So the download time of this 70kbytes file, after it is
>     zipped and the
>     >>     https session is established, will be less than a second.  Maybe 1-3 seconds
>     total with
>     >>     SSL session establishment overhead, depending on github load and internet whims.
>     >>
>     >>
>     >>     I am encouraged, and I think I will end up using this plugin as my main means
>     of getting
>     >>     footprints, period.
>     >>
>     >>
>     >>     If no one volunteers, I have it on my to do list to convert what we have to
>     pretty, then
>     >>     push it to github.  I would use lib_convert.py to do this, for each library.
>     >>
>     >>     If someone else wants to do it, that would be helpful.  I certainly understand
>     the "show
>     >>     me" mentality.  If you've yet to see the GITHUB_PLUGIN work, then why would you
>     invest
>     >>     time in this?  I understand that.  But I've also seen it work, so I am
>     confident that
>     >>     somebody will probably step up in the near future.
>     >>
>     >>     Just yesterday I made a tweak to the pretty output which tries to put pads on
>     one line if
>     >>     they are not tricked out with optional attributes.  That would be the format to
>     use, from
>     >>     a build at least that new I suppose.
>     >>
>     >>     Also, note that a library repo can be pushed with a README.md file, and in that
>     file you
>     >>     could elaborate on and include an index of all footprints in the library in
>     freeform text.
>     >>      This way a person could web-browse there and read about footprint choices
>     first, in
>     >>     potentially great detail.
>     >>
>     >>     Note that although subdirectories can be used in the repo, this view is
>     flattened as the
>     >>     plugin unzips the footprints into its cache.  So if you use subdirectories,
>     make sure you
>     >>     have unique footprint names.  With the upcoming options support, it will be
>     possible to
>     >>     build in directory filters or other tricks into the plugin.  But that will be
>     for some
>     >>     other developer to do.  I will provide the options support to all plugins.
>     >>
>     >>     Beyond that, there is also the ability to comment each footprint in the
>     *.kicad_mod file,
>     >>     manually using a text editor for now.  The *first* lines of
>     >>
>     >>     # ... anything
>     >>
>     >>     are ignored by pcbnew.  This may not be as helpful as the table of contents in the
>     >>     README.md file.
>     >>
>     >>     You can sort of tell that this infrastructure is screaming for leadership.  I
>     don't see
>     >>     where that leadership needs to come from a programmer/developer.  It is simple
>     >>     administration and guideline establishment.
>     >>
>     >>     But yes, it is still a little early, we've got to get it running on all the
>     platforms
>     >>     first.  Our thanks go to Brian, Miguel and anyone else helping with that.
>     >>
>     >>
>     >>     Dick
>     >>
>     >>
>     >>
>     >>     _______________________________________________
>     >>     Mailing list: https://launchpad.net/~kicad-developers
>     >>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>     >>     Unsubscribe : https://launchpad.net/~kicad-developers
>     >>     More help   : https://help.launchpad.net/ListHelp
>     >>
>     >>
>     >
> 
>