Commit Graph

16 Commits

Author SHA1 Message Date
Ian McInerney 5c0656d97f Move potrace and libcontext into thirdparty directory
Part of the cleanup in #3637
2019-12-28 18:17:55 +00:00
John Beard 1b1e514544 QA: Move to a self-registering plugin system for QA utils
This means that utility programs no longer have to be manually
added to the COMBINED_UTILITY, they self-register their
information at static init time. This is basically the same concept
as the Boost test registration.

All utilities need to do now is register their UTILITY_PROGRAM info
struct with the UTILITY_REGISTRY::Register method. No headers required.
2019-11-25 15:38:21 +08:00
John Beard 781c5f7e1d Remove SCOPED_TIMER, use PROF_COUNTER
SCOPED_TIMER is a QA-only simpler version of PROF_COUNTER.

Extend PROF_COUNTER to allow access to the std::chrono::duration
for more flexibility.

Wrap PROF_COUNTER in SCOPED_PROF_COUNTER for RAII duration
output (for the same effect as SCOPED_TIMER).
2019-06-12 14:16:47 +01:00
John Beard 7ebda0247f Common: Remove legacy_gal library, fold into common
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.
2019-06-10 18:56:57 +01:00
John Beard 45aa514591 QA: Allow to build tests manually if disabled
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
2019-04-17 18:00:40 +01:00
John Beard 427f0aed78 QA sexpr: add a common_tool to parse sexpr files
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).
2019-04-17 10:52:56 +01:00
John Beard e6a6266f3d Build: libpolygon provides its own includes
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.
2019-02-04 19:29:31 -08:00
John Beard bb2ae8e13b Bitmaps: move bitmap defs to bitmaps library
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.
2019-02-04 19:29:31 -08:00
John Beard 33bc74a4a2 QA: Tidy qa_utils headers
Move into own include directory for clarity. Also allows qa_utils
to use its own private headers in qa/qa_utils without exposing them
through the target_include_directories directive.
2019-01-29 18:16:00 -05:00
John Beard e4b4230bcf QA: Put UTILITY_PROGRAM in KI_TEST
Also expand some documentation of some other KI_TEST functions.
2019-01-29 08:15:37 -05:00
John Beard b690658972 QA: Add coroutine unit test
This adds a simple unit test to qa_common to check coroutines
produce expected events in the right order.

This is an automated analogue to the user-facing tool in
qa/common_tools.
2019-01-24 13:01:44 -05:00
John Beard d7563c55c4 QA: Pcbnew utility tools: DRC tool
Add a tool that allows a user to run DRC functions
on a given KiCad PCB file.

The first available functions are the courtyard functions.

Also move most of the utility program logic into qa_util for
better reusability.
2019-01-23 13:27:52 -05:00
John Beard bb2e402bc7 QA: Move io_benchmark into common_tools 2019-01-22 09:04:38 -05:00
John Beard 267e17d539 QA: Add a generic utility tool executable.
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.
2019-01-22 09:04:38 -05:00
Seth Hillbrand 8f11a2133e Revert "QA: Add a generic utility tool executable."
This reverts commit 502306314e.
2019-01-06 16:17:44 -08:00
John Beard 502306314e QA: Add a generic utility tool executable.
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.
2019-01-06 07:51:23 -08:00