Let me present the result of almost one year work: project QEDA.
Briefly this is the a tool for easy creating libraries of electronic components for KiCad EDA.
Documentation section is under construction yet, but the utility itself is quite ready for using.
Any feedback would be much appreciated.
We had QEDA appear here for a brief discussion:
Nice of you to show up personally and make it known! 
Looks very promising and when I find the time I’ll surely make use of it.
Is there any information about how to make a footprint (or ‘housing’) from a set of pads? I want to make the SMD footprint for an ESP8266 module like the ESP-12 but can’t see how.
Also, can you define footprints independently of schematic symbols?
There is a custom pattern which allows generate arbitrary footprints. Each pad may be set by its position (padPosition field, see example).
I have idea to add scripting ability to YAML-description in future.
ESP-12 seems to be similar to SON package. Please refer to ESP-07 I guess it is quite resembling.
Footprint can not be defined without schematic symbol. Is there need of such option?
Thanks, I saw that. I guess I’ll have to experiment with it.
Yes, that’s true. But some of the ESP8266 modules have pins along the top or bottom as well as the sides. I just don’t understand what the package keyword does, what its possible values are, and whether it has other specific fields that control it.
The space of all possible parts is much larger than the space of all possible footprints (e.g., there are hundreds of microcontrollers but they all use a much smaller set of packages). So I’d like to define the footprints separately and then associate them to the appropriate symbol when necessary.
Of course, this is just a suggestion and it may not fit with your design philosophy. Either way, thanks for your efforts and for bringing this tool to the KiCad community.
Sorry for that, I guess documentation will shed light on these details when it will be complete.
Any YAML-description (abstract or not) may be included in component’s YAML. Thus one may describe housing in separate file then just include it using base keyword (doc).
It appears that footprint specification is quite high level, so you can do ( https://github.com/qeda/library/blob/master/atmel/atmega128.yaml#L86 )
housing@TQFP:
suffix: -16AU
outline: JEDEC MS-026 AEB
The package specs appear to be hard coded inside qeda code, so that is powerful but not very flexible for the user if custom design is needed.
I guess QEDA is Linux only? Otherwise the part database is lot like one I had envisaged. I think I would also include 3D models in the database. Also, I have come to the conclusion that version control and support for an engineering change process is essential.
Yes, this is the second (and better) way to describe common component packages. It is not hard coded at all. JEDEC MS-026 AEB is translated to outline/jedec/ms-026.yaml, section AEB: see share/outline/jedec/ms-026.yaml
As you can see, sections support even regular expressions.
In theory one may also describe his own outlines and place them near to PCB-project. But custom outlines are not supported at the moment.
No, QEDA is cross-platform (as Node.js). I have tested it against Windows and OS X some time ago. But Ubuntu support in prioritized due to the Linux being my preferred OS.
3D models are planned to be supported after QEDA becomes web-service (details).
Thank you for feedback. Please feel free to open issues on Github with feature requests.
Now I spend my free time to make documentation more complete in order to facilitate using of QEDA.
That is a matter of opinion.
A small part is parametised, but it is still part of the code base, inaccessible to user. Most of the package generation is done by code, see https://github.com/qeda/qeda/tree/master/src/pattern/default
It is difficult enough having to rely on third-party to update parts, even harder having to rely on third parties to maintain code. To be useful, I think you need to put package generation into user space.
The pattern generation script is specified in housing.pattern parameter and may be overridden by user.
The directory you mentioned contains standard pattern generators but one is allowed to create his own.
Cool, do you have any examples?
For example R0603:
housing:
pattern: chip
will call pattern/default/chip.coffee script for pattern generation.
If you specify ‘pattern: mygenerator’ then utility will not find it in its own pattern/default/ nor in pattern/<style>/ (if style is specified). Last searching place is ./pattern/ subdirectory (relatively to current directory). If you place your mygenerator.coffee or mygenerator.js in this subdirectory then it will be called for pattern generation.
If you specify outline actually it contains pattern reference (for example JEDEC MS-026 contains ‘pattern: QFP’ line that cause run pattern/default/qfp.coffee).