This implements all existing symbol library object support and the ability
to save and load symbol library files between file formats for round robin
testing.
CHANGES: Symbol library file format has been converted to s-expressions.
Add support code for picking apart symbols at some future junction that
will allow full inheritance conversion of existing symbol libraries. For
now, symbols arranged by unit and body style numbers are nested for round
robin testing of symbol libraries once the parser is complete.
CHANGED: Settings are now stored in versioned sub-directories
ADDED: First-run dialog for migrating settings from a previous version
CHANGED: Settings are now stored as JSON files instead of wxConfig-style INI files
CHANGED: Color settings are now all stored in a separate settings file
CHANGED: The symbol editor and footprint editor now have their own settings files
CHANGED: Color settings are no longer exposed through BOARD object
CHANGED: Page layout editor now uses Eeschema's color scheme
Settings are now managed through a central SETTINGS_MANAGER held by PGM_BASE.
Existing settings will be migrated from the wxConfig format on first run of each application.
Per-application settings are now stored in one class for each application.
ADDED: Back annotation algorithm,
eeschema back annotation dialog
CHANGED: added some minor helper methods to SCH_REFERENCE_LIST and SCH_REFERENCE,
split SCH_REFERENCE_LIST::CheckAnnotation on 2 parts to reuse code
The previous converter (maddy) is still available, during some time.
We therefore have the time to choose between them.
sundown is better to convert a md text, but is written to C
maddy has a few issues to convert a md text, but is written to C++
Both have no dependency.
They're now used for bus definition control characters.
Also fixes the sheet pin edit dialog to correctly escape/unescape
netnames.
Fixes: lp:1840834
* https://bugs.launchpad.net/kicad/+bug/1840834
This changes make_lexer() so that it no longer generates a custom target
but instead attaches the generated files to an existing one (so the first
argument now is the name of an existing library or executable, and it needs
to come after the add_library/add_executable call).
The generated source is no longer listed in the project sources, as it is
added by the function. The files are generated in the build tree rather
than the source tree, and the directory is added to the include path for
the respective project as well as exported to projects linking against it.
Generated files in subdirectories are somewhat supported, but need to be
referenced with the same name as they were generated (i.e. including the
subdirectory name).
Fixes: lp:1831643
* https://bugs.launchpad.net/kicad/+bug/1831643
Fixes: lp:1832357
* https://bugs.launchpad.net/kicad/+bug/1832357
Fixes: lp:1833851
* https://bugs.launchpad.net/kicad/+bug/1833851
It's a bit of a hack because they're statically initialized and
so we can't make use of the _() macro. We do still want it in the
code, however, because the string harvesting is based off of it.
Fixes: lp:1833000
* https://bugs.launchpad.net/kicad/+bug/1833000
Return the EDA_DRAW_FRAME class back to common, whence it came (before it was
duplicated into legacy_wx and legacy_gal). Now there is only one
implementation (the GAL one), it doesn't need to be in a separate library.
This simplifies the dependencies for common lib users.
Building custom targets that depend on custom commands such as our
keyword lexer requires two layers of indirection to pick up changes
properly and not overwrite the same file in parallel builds.
Fixes: lp:1831643
* https://bugs.launchpad.net/kicad/+bug/1831643
This is done to allow access to the eeschema library
internals for purposes of test and script access, as the
DLL library has highly restrictive -fvisibility settings
that otherwise prevent the tests being able to access 99.9%
of the eeschema library functions (only a single function
is APIEXPORT'ed, therefore that's the only test we can do).
Using object libraries is a bit of a hack, and makes for
a slower link when done for multiple targets, but with the currently
supported CMake versions, it's about as good as we can get.
A better solution in the longer term may be to break eeschema_kiface(_objects)
into many smaller libraries, each of which has a much more defined scope,
rather than one big interlinked amorphous lump. This has the advantage that
each module is testable in isolation, and we get better organisation of
inter-dependencies in the codebase.
Then, the kiface DLL will gather these sub-libs and present what
is needed on the visible DLL API. Thus, we get both a testable
suite of library functions, and a restricted kiface DLL interface.
Jon Evans
Jeff Young
Wayne Stambaugh
Alexander Shuklin
Ian McInerney
jean-pierre charras
Simon Richter
Seppe Stas
John Beard
Seth Hillbrand