kicad-developers team mailing list archive
Mailing list archive
Re: Atomic Libraries Proposal
KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
Rene Pöschl <poeschlr@xxxxxxxxx>
Thu, 23 May 2019 22:06:21 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
What is the benefit compared to having lets say a more powerful aliasing
system that allows bom specific things to be more easily included in the
kicad internal library without introducing something different?
(especially as i assume the new file format will provide a more powerful
option in this regard anyways.)
On 23/05/19 21:41, Seth Hillbrand wrote:
After some discussion, we are trying to decide whether implementing a
basic atomic library support would be useful during v6 or would cause
more headache than worth while trying to work with the solution.
Background: "Atomic" libraries are ones that have unique names for
symbol+footprint+properties combinations. These are also referred to as
"Fully-specified" libraries or sometimes "house libraries".
The paradigm is outlined in a google document. This is meant to
provide an explicit option for users to create/utilize atomic library
components without affecting the symbol or footprint formats. It is
also meant to be zero impact to the current, official KiCad libraries.
The major limitations of the specification are:
- No editing of the atomic library file within KiCad
- The atomic library does not contain symbol or footprint data
Folks are welcomed to weigh in on whether this approach presents a
viable work flow for them. I'm happy to take suggestions on the
approach, I may ask you offline for some additional details of how you
use KiCad and/or other tools with libraries at the moment.
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