← Back to team overview

kicad-developers team mailing list archive

Re: library structure


Le 26/09/2010 19:28, Dick Hollenbeck a écrit :

On 09/26/2010 11:04 AM, Wayne Stambaugh wrote:
On 9/25/2010 1:01 AM, Dick Hollenbeck wrote:

On 09/24/2010 01:14 PM, Wayne Stambaugh wrote:

On 9/24/2010 10:35 AM, Dick Hollenbeck wrote:

On 09/24/2010 08:59 AM, Dick Hollenbeck wrote:

On 09/24/2010 03:41 AM, Lorenzo Marcantonio wrote:

On Fri, 24 Sep 2010, Martijn Kuipers wrote:

I would be very happy with an export function, doing: Export all used components into a project library.
This way I can send the schematics on to the next person and (s)he can adjust where needed, without having to look for some components/footprint differences.
Of course, its export, so the component would still live in the system library to be re-used.

<<<  snipped>>>

Then if you give EESCHEMA the ability to treat any previously designed
schematic as a library source for a new schematic (remembering that a
parts list is a library that exists within a schematic), you can pull
from one parts list into a new one, using drag and drop also.  If you
want to extend this to the extreme, you can eventually do away with
library files in total and only have one file format, schematics.  This
extension is a separate optional design decision obviously.  You could
also do this and hide it by giving the libraries a different file
extention, but the formats could be identical.  Library files would not
need to have any component instantiations or wires.

This is an interesting concept.  I was thinking about embedding the library in
the schematic instead of a separate library file when you suggested a separate
project library file.  I actually like this concept better.  The only down side
I see is that it requires implementing the schematic structure to support this
at the same time which may be too big of a change to implement in a reasonable
time frame.  We could implement the component library first and design in the
capability to embed libraries into other files as part of the library
structure.  Then we could repeat this same exercise for the schematic structure
and make the library to schematic transition then.


If we're basing the new library file on s-expression (aka DSN like) and
using richio concepts, I don't think it is hard to assume that that
makes loading and saving pretty much context free and relocatable, i.e.
nestable.  It should be easy to extend the library file to include
sheets, wires, instantiated components, and desired parts list columns,
and after all that, call it a new schematic format.

I was planning on making the library file an s-expression using richio.
  I didn't even consider anything else.

And if need be a new branch can be started to do any of this work, to
avoid exposing folks to a phase where the program is not usable.  As
always, I see the rate limiting problem being one of qualified
man-hours, and who gets to donate them.

Once this discussion dies down, I'll put together a bullet list summary
and publish the new file format document.  Once that is fleshed out,
I'll start working on it.  I am more than happy to push my dev branch to
launchpad if anyone else is interested in helping.  I was thinking of
using using conditional compilation to enable/disable reading and
writing the new file format until the code is to keep the code base in a
reasonably usable state.

Conditional compilation sounds like a reasonable migration path for the
library work.

I was mentioning the separate branch in respect to a new schematic
format and parts-list based UI, but it will take a few more emails later
in the game to solidify that path and those concepts.  Then we'd have to
find the qualified man-hours to complete the unified goals.


I also like the idea of conditional compilation.

Jean-Pierre CHARRAS