kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Blog on Sweet parser:

I am as excited as ever about this work.  The next two weekends I will be
mostly tied up and you will not see a lot of progress.

Roadmap:

I am toying with the idea of keeping the Sweet foundations, up through
LIB_TABLE and LIB interfaces, as a separate DLL/DSO.  And then later
building on top of that with a new EESCHEMA.  This is just a possibility,
not a commitment.  The motivation for this design would be to:

1) allow the interface to be tool agnostic.

2) allow the interface to be clearly defined enough to allow it to also be
language agnostic.  In this regard, we have C++ inherently, but I also am
playing with the idea of tying in Python at this point before going much
higher up in the architecture.


The Sweet foundations would give you the ability to both Parse() and
Format(), do round tripping, do inheritance, remote part retrieval, saving,
on top of the LIB and LIB_TABLE interfaces.  Then by bringing Python in at
this point, it becomes possible to script the generation of PARTs.  Or to do
a Python graphical editor that knows about inheritance and remote part
retrieval.  I have no intentions of doing such an editor in Python, only
enabling it, by coining a clearly defined API and foundation.

Of course the LIB interface then allows *saving* of PARTs for cases where
there are LIB_SINKs, or a Python program could simply do its own storage
management of the Sweet strings.  But in this way the inheritance mechanism
is brought into Python through the common C++ work that is already done.

This may slow things down a little, but it gives us a better base moving
forward, and enhances the likelihood that Sweet will have legs.

Dick