← Back to team overview

kicad-developers team mailing list archive

Re: Library structure recap.


On 10/03/2010 07:39 PM, Werner Almesberger wrote:
> Dick Hollenbeck wrote:
>> a) the "personal libraries", and hopefully in the future
>> b) the "project specific" library, i.e. the schematic specific "parts list".
> Just curious: why do you consider project specific libraries to be
> "in the future" ? I use them and see others use them all the time,
> and things seem to work rather nicely. 

Well it took a few postings to crystallize, but the term "parts list"
was formally introduced in the posting below.   Parts list support does
not currently exist as defined here:


> "Project" here means things like gta02-core [1], Xue [2], etc. I.e.,
> projects where several people work together and use KiCad on top of
> a revision control system (SVN and git in these cases).
> [1] http://svn.openmoko.org/trunk/gta02-core/
> [2] http://projects.qi-hardware.com/index.php/p/xue/

Thanks to the links to your excellent work.  Please remind the list what
the license is on the schematics and layouts.  I actually need a GSM
interface for an my ARM board currently.

> Regarding the library format, I'd also prefer values tagged with
> names. These files aren't really human-readable anyway, so it
> doesn't matter much if, say, a text diff is more or less compact,
> and the tags make it easier to build parsers. CPU cycles are cheap,
> too :-)
> Something that I think will be important is to have a consistent
> and stable arrangement of whitespace, so that also "quick hack"
> parsers that don't parse the full sexprs but instead look for
> certain patterns won't break too often.

The quick hack parsers are not so important since most languages have
s-expression parsers, but I think the spacing will end up being
consistent any way for things like sed or grep grabs of text fragments
like you allude to.  That is, the whitespace should be consisten unless
the generating tool was also a quick hack variety, such as a text editor
driven by somebody who did not care. 

I however think it is necessary to make white space quantities part of
the s-expression spec.


Follow ups