Maybe it can be implemented as not a new library format, but through enhancements to the existing workflow and new symbol format.
If there was an ability to a) filter symbols in eeschema that have a valid footprint that can be found in the footprint library. b) run a dfm check that flags symbols being used that aren't fully defined. Another idea i can think of is using hashes to link footprints and symbols. Each symbol alias could have a linked footprint and a hash to verify that the footprint is correct. Cheers Russ On Fri, 24 May 2019, 9:29 am Seth Hillbrand, <[email protected]> wrote: > Hi Rene- > > That's a fair critique. The main benefits are ones that could be > incorporated as separate tools (import/export, ability to switch between > atomic and not, etc) once the new format is implemented. In my use > case, it is useful to separate the definitions from the libraries and > switch between atomic libraries, but that might not be sufficiently > common as to require an extra format. Hence the request for feedback on > the workflow. > > -Seth > > Am 2019-05-23 16:06, schrieb Rene Pöschl: > > Hi Seth > > > > 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: > >> Hi All- > >> > >> 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[1]. 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. > >> > >> Best- > >> Seth > >> > >> > >> [1] > >> > https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing > >> > >> _______________________________________________ > >> Mailing list: https://launchpad.net/~kicad-developers > >> Post to : [email protected] > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > > > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
