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.
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.
Add a new CMake target, qa_all, which builds all
tests, tools and their deps.
Then, when KICAD_BUILD_QA_TESTS is set OFF, remove tests
and tools from the ALL target, so `make all` doesn't include
these builds.
This means even when you turn the KICAD_BUILD_QA_TESTS option
off, you still have the option to:
* Build individual tests: `make qa_pcbnew`
* Build all tests: `make qa_all_tests`
* Build all tools: `make qa_all_tools`
* Build all QA executables: `make qa_all`
This also will provide a place to hang extra logic for test routine
wrangling (e.g. by CI tools)
Update the "Compiling KiCad" dev docs.
Also, CMakeModules .cmake files should not be excluded from git
This allows to feed any data directly into the sexpr parser. This can be
used for:
* Benchmarking, profiling and optimisation
* Fuzz testing
* Debugging
As an example, it demonstrates that a 15MB kicad PCB file (the CIAA
motherboard project) takes 1.5s to parse, and uses 140MB of heap
allocation within the Parse() method (using Valgrind massif).
Libpolygon can provide its own includes via target_include_dirs PUBLIC.
This means any linking targets do not need to specifiy them manually.
As common requires polygon, the polygon dep is also now no longer
required downstream of libcommon, as it's transisitvely implied
by libcommon's target_link_libraries.
This resolves a circular dependency previously detected and also
simplifies CMakeLists.
The bitmap definitions (BITMAP_DEF and so on) do not
have any dependencies on other libs, including WX. This
means the bitmaps library can be isolated from the other
dependencies.
Common now depends on bitmaps, and libraries that depend
on common can pick it up from the common target_link_libraries,
as it is PUBLIC. This means a lot of targets no longer
need manual bitmap linkage.
This avoids a circular dependency that was previously reported
by static analysis.
Avoiding pulling in WX and other headers into the include
tree of each bitmap .cpp is a huge speed up (around 10x) in
compilation, and the generated static library is also 10x
smaller (20MB vs 200MB)
Add common as a link library to pnsrouter,connectivity.
THese library do still use common code (including bitmaps,
via base_screen.h) and this allows them to pick up the libcommon
includes correctly.
The intention here is to make it possible to wrap up many of the
KiCad utility tools into a single executable. This reduces link times
as well as the duplication of CMake files needed to build very
similar tools.
This particular tool should be suitable for any code in common,
code in pcbnew and other end-executables probalby will need an
analagous version linked to the relevant kiface.
The first tool is the coroutine_example.cpp test case, which
can be useful when learning, debugging or porting the coroutine
infrastructure.
The intention here is to make it possible to wrap up many of the
KiCad utility tools into a single executable. This reduces link times
as well as the duplication of CMake files needed to build very
similar tools.
This particular tool should be suitable for any code in common,
code in pcbnew and other end-executables probalby will need an
analagous version linked to the relevant kiface.
The first tool is the coroutine_example.cpp test case, which
can be useful when learning, debugging or porting the coroutine
infrastructure.
Jon Evans
Ian McInerney
John Beard
Seth Hillbrand