kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 01/05/2011 11:23 AM, Marco Mattila wrote:
> If you think that the plotting requirements vary from one project to
> another (the number of needed technical layers maybe?), saving them
> outside the config system makes sense. Since there can be multiple
> boards in a project, maybe the SETUP section of a board file is the
> correct place for this. I wonder if all plot settings should be saved
> in the board file. For example, it would be nice if the output
> directory was saved, too.
>
> marco


If you were to write a Parse() and Format() function for your PLOT settings
object, similar to those in new/sch_lib_table.cpp or class
TEMPLATE_FIELD_NAMES, then you could stuff or retrieve the data almost
anywhere, and it would be re-usable moving forward.  This includes the
ability to:

1) save it in the current board file, all on one line.
2) read it from the current board file format, all from one line.

3) save it to any new S-EXPRESSION based board file in the future.
4) read it from any new S-EXPRESSION based board file in the future.

5) Save/read it to the clipboard.


For 1) and 2) you would need an "old school" prefix on the BOARD file line,
such as:

// for current board file format, all on one LONG line:
PlotConfigs:  (plot_conf () () ())


For an example, see what I did for eeschema, TEMPLATE_FIELD_NAMES:

*) eeschema_config.cpp, line 711, where I save the s-expression.

*) eeschema_config.cpp, line 628, where I read the s-expression.


If any new data structure were to have these Parse() and Format() functions,
it becomes really pretty easy to serialize these things almost anywhere,
including to the clipboard, or nested in side another S-EXPRESSION.

This would give you an intro to the make_lexer support in the CMake files.

If you were going to parse everything off of a single line, then probably
the STRING_LINE_READER constructor of the DSNLEXER derivative is what could
be used for stuffing this stuff all on one line in a current board file. 
This is what I did for TEMPLATE_FIELD_NAMES.

The storage location is almost a separate discussion from the storage
format.   I like the s-expression direction we have, obviously, and I don't
see any big problems putting it into a BOARD file, but I could be wrong. 
The only concern is maximum line length, but if the BOARD reader were to use
a FILE_LINE_READER, then that concern goes away, since FILE_LINE_READER will
read single lines of up to 100,000 bytes.

Or you can simply not inject FILE_LINE_READER into the BOARD loader, but
verify that its fgets() buffer is big enough to handle your new long single
line.

Jean-Pierre, what do you think of this as a migration path, or even as a
middle term destination?

Dick