* Changed the KICAD_SCRIPTING flag to be a global disable, so it
will disable all other scripting flags when set to OFF
* Added version testing with the wxPython flags to ensure the
proper version is found for the flags provided
These options were used to support the legacy canvas when drawing on
MacOS and GTK3. With the move to 100% GAL, they are extraneous. This
moves all DC over to "COPY" as we only use this for printing support in
Eeschema at the moment, so there is a single draw command (no erasing)
for the canvas.
Change the default option setting for the Python scripting action menu
support.
Add notes that the KiCad scripting support is forcefully enable when the
Python scripting module support or the Python scripting action menu
support are enabled.
This adds a few tests on:
* LIB_PART
* SCH_PIN
* SCH_SHEET
* SCH_SHEET_PATH
These tests exercise some of the basic code paths in these classes
and show some of the expected behaviours.
None of these tests are particularly ground-breaking, but they
provide a starting point to build out further tests, and to ensure
the already-covered behaviour is stable.
It does expose some places where SCH_SHEET could probably use const.
Remove version 5 road map since version 5 has been released.
Update version 6 road map to reflect current development goals.
Cleaned out old goals from generic road map in preparation for version
7 development.
Add note to compiling document about building with Boost 1.70 on Windows.
Fix link to Linux coding style policy in KiCad Coding Style Guide.
Update tool framework documentation to reflect changes in the tool
framework code.
Currently, the format enforces single lines when possible, but does
not enforce readable column-based alignment (and, moreover, *removes*
such manually added alignment:
switch( m_orientation )
{
case PIN_RIGHT: m_orientation = PIN_UP; break;
case PIN_UP: m_orientation = PIN_LEFT; break;
}
Change this to multi-line by default:
switch( m_orientation )
{
case PIN_RIGHT:
m_orientation = PIN_UP;
break;
case PIN_UP:
m_orientation = PIN_LEFT;
break;
}
If the developer wishes for column-aligned single-line cases, this
is permitted, but much be done manually:
switch( m_orientation )
{
case PIN_RIGHT: m_orientation = PIN_DOWN; break;
case PIN_UP: m_orientation = PIN_RIGHT; break;
}
CHANGE: the _clang-format file to reflect this, and add note about
manual override in the dev docs.
Provides a place to record work that is pending due to
library, compiler or language restrictions.
Because some of this work will be pending for several years
until supported distros support the relevant versions, having
this centrally documented prevents it being forgotten.
Also includes current distro versions for extant "LTS"
distros that are likely to be the distros holding back
library versions.
Only includes things we currently actually do work around
in the code, or things that are direct C++ replacements
(e.g. Boost libraries being adopted to C++).
This is as opposed to more opinion-based "we should
do it this way, it's better" things, which should be
proposed for discussion first.
This allows CI tools to get machine-readable test reports.
By default, this is off - when you test normally, you probably
want the regular console spew.
Boost tests use the in-built Boost test command line options.
The Python tests take an --xml parameter and output the tests
there.
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 setting the config dir at build time, providing packagers a
method of controlling where the configuration files are placed.
Fixes: lp:1780601
* https://bugs.launchpad.net/kicad/+bug/1780601
The keeps all the formatting config together in the Git ecosystem
and keeps the config on a per-repo basis, unless the user explicitly
sets it --global.
Keep the old env var behaviour for now for backwards compatibility.
Add a .gitattributes files to provide a place to store file
attributes. Add a custom attribute for files that should be under
KiCad style guidelines.
Exclude generated files from the style enforcement. So far:
* bitmap .cpp files
* wxFormBuilder base classes
* Lemon grammars
It's now trivial to add the 'generated' attribute to any such
file.
Putting this into .gitattributes also means it can be retreived
programmatically, by other scripts, git alaises or on the command
line.
Use the attributes to provide a utility script to show or apply
formatting to controlled files (plain git clang-format won't
pick up our custom git attributes). Add details for the script in
the dev docs.
Also modiify the check-format hook to follow the .gitattributes
and only apply to cached (staged for commit) changes. Then you
won't be stopped committing because of bad formatting in unstaged
changed, or uncontrolled files.
Concept and some aspects of the implementation inspired by
CMake commit d5f39a56 [1].
[1]: d5f39a56a4
tool
Apparently curly brace escaping in a list does not work with Doxygen's
markdown support which caused everything after the windows install path
to be removed from the output build. I just fell back to the windows
environment variable expansion character (%) and that resolved the issue.
This can be used for "advanced" options which are for developers
to use for feature-flags and other configuration. Run time config
has some advantages over preprocessor defines:
* Can be changed without recompilation
* Sensitive to XDG_CONFIG_DIR, so flipping configs is easy
* Better compiler coverage (less conditionally compiled code means
less chance to break a different configuration). Also better
analysis coverage.
* Type safe config params
* Centralised documentation: it's in doxygen, in one place
No advanced config should be required by a general users. If a general
user does use one of these configs, it's probably because:
* There is a bug and one of these configs is a workaround
* A config in here is generally useful and should be moved into the
relevant application config and given UI.
For now, the config is read-only, and is read from the
"kicad_advanced" config file in the normal config dir.
This is done to avoid a big chunk of conditionally-compiled code
in the middle of the event function.
Also separates the zoom logic from the WX_VIEW_CONTROLS object
and isolates it in a separate class behind a clearer interface.
Add some simple tests for sane steps on GTK+3-sized scroll
steps.
This includes:
* Linkage against the Boost unit test libs
* Configuration of the Boost libs
* A place for common generics "extras" for unit test harnesses
including
* A simple way to allow "expected-failure" tests (without
breaking Boost < 1.58, e.g. Ubuntu LTS)
* Moving some simple numeric predicates from the geom tests
to the utils library.
Expand unit test docs to describe the expected failures macro.
Add a few COLOR4D tests, including one with expected failures due
to a pre-existing bug. This will be fixed in a follow-up commit.
This adds a pre-commit hook to warn of any style errors.
Also adds a 'hook-chain' script to simplify future hooks.
Add dev-doc note about how to use the formatter.
This adds a test program which can be used to test the
parsing of a given KiCad PCB file. This interface is
useful for both manual or automated debugging of given
files, as well as providing an interface suitable for
fuzz-testing tools.
Also adds to the testing docs to detail how fuzzing can
be used.
Also moves some useful re-usable code from io-benchmark
to a new library qa_utils, which can contain code that
isn't need in the actual KiCad libs.
This adds a small KiCad logo in the top left of the Doxygen pages.
54px used as 55px is maximum recommended height for Doxygen logos.
For the main docs and the dev docs, this is easily done in the Doxyfile,
for the Python docs, as that is run from the binary dir, the source dir
is passed as an Environment variable.