← Back to team overview

kicad-developers team mailing list archive

Re: Sweet parser


> When it comes to coding, we should be careful not to allow the schematic
> editor to go beyond the bounds of the public Sweet API.  This should be
> possible to enforce by keeping the sweet stuff as a separate DLL.

I still think the best way forward will be to have a LIB_SOURCE that simply
reads old lib files and provides PARTs through the LIB_SOURCE API, which
inherently means generating a sweet string for each part, on the fly.  This
provides a good model for any other type of library conversion facility.

As soon as I am done with the sweet parser, I will be doing all the Format()
functions which is the reverse of the Parse() operation, and from this code,
given that we can Format() into a STRING_FORMATTER, means we can generate
Sweet strings from the C++ structures.  These building blocks can be put
into any "converting" type of LIB_SOURCE.


Follow ups