eeschema cpp files consume generated header files that have targets in
the common directory, so no dependencies get created from eeschema. We
add the dependencies in common to force the setting through libraries.
Fixes: lp:1831643
* https://bugs.launchpad.net/kicad/+bug/1831643
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
(cherry picked from commit c6af38477d)
Some developer scripts ended up in the demonstration scripts directory
that was bundled with builds. This moves them to the build_tools
directory and updates the associated Documentation
Fixes: lp:1815891
* https://bugs.launchpad.net/kicad/+bug/1815891
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.
Adds a link-time dependency for libngspice, so that other tools may
detect ngspice as a KiCad dependency.
The library is still loaded with dlopen() as it gives a way to reload it
in case of problems. The DLL name is recognized during CMake
configuration and used to load the library at runtime.
The CMake scripts calculate the install path for python scripts by
distutils.sysconfig.get_python_lib(
plat_specific=0,
standard_lib=0,
prefix=''
)
which generates a string in line with
lib/python2.7/site-packages
This string ends up in the CMake variable PYTHON_DEST and is used by the
install step as destination directory for pcbnew.py.
There has been a hard-coded assumption on the content of that string in
PcbNew which is not compatible with FreeBSD 11.1.
This commit eliminates the hard-coded assumption in PcbNew and reuses
the install path as known by CMake.
Fixes: lp:1777921
* https://bugs.launchpad.net/kicad/+bug/1777921
(cherry picked from commit dd3c24faf8)
OpenCascade 7.3 deprecates some TK libraries that were not required by
KiCad, therefore we should not include them in the compile.
Also correct missing compiles for STEP import/export induced by 584409b2e when using OCCT. There is no effect on OCE to this change.
Git is always used to generate the KiCad version string using the
command `git describe --dirty`. This gives a more concise and
accurate version string than the previous method. When git is not
available, the version string defaults to the value defined in
KiCadVersion.cmake. It is imperative that moving forward that the
default version string be updated the commit following a git tag
so that when git is not available, the last known commit following
a git tag will at least give some usable information about which
development branch of KiCad was used for a build.
Both official one and KiCad one version of FindwxWidgets.cmake do not check if
all the required components are part of the wxWidgets build. This couses trouble
on Ubuntu when user misses libwxgtk3.0-dev package - CMake succeeds, build does
not.
This fix was accepted also to the CMake 3.9 upstream
(https://gitlab.kitware.com/cmake/cmake/merge_requests/704).
Fixes: lp:1630020
* https://bugs.launchpad.net/kicad/+bug/1630020