The link maps were actually disabled by default before
912f1d5cec, and required KICAD_MAKE_LINK_MAPS
to be provided to enable them. So switch back to disabling them by
default.
Also, The lld linker is unable to accept a single dash cref option, while
ld and gold can. Instead, use the double dash version that is supported
by all three.
xref: https://github.com/llvm/llvm-project/issues/60932
Co-authored-by: aris-kimi <aris_kimi@hotmail.com>
Co-authored-by: Ian McInerney <ian.s.mcinerney@ieee.org>
Some classes had been originally designed to be usable separate from wx,
but over time our uses of the classes have become entertwined with wx
features (e.g. colors), and various changes have also leaked wx into the
classes unguarded. So just remove the option to hide wx in those classes
to simplify the code.
Organize the build options into various categories to make finding them
in the main file easier.
Other changes:
* Removed KICAD_NETLIST_QA
* Renamed BUILD_SMALL_DEBUG_FILES to KICAD_BUILD_SMALL_DEBUG_FILES
As part of supporting Apple Silicon, we've got to upgrade our embedded
Python to a version that comes with an Apple Silicon build. Python 3.9
suffices. This means we ignore python3.9 while fixing up bundles.
Apple requires all code to be signed on Apple Silicon. We've added signing
to the build. This has to be run after anything that adds to or modifies
the installed files. As of Cmake 3.14 (CMP0082), the install rules are run
in the order declared, so we are able to do this just by adding the
signing subdirectory last in the main CMakeLists.txt. By default, the
build will be signed "ad hoc", which does not require a developer to
create keys or get keys from Apple. We added some CMake variables to
control signing, KICAD_OSX_CODESIGN and KICAD_OSX_SIGNING_*.
In order to better support development, we've added some necessary cleanup
steps to KiCad that were performed externally in the release and nightly
build process, like removing any .pyc files and extra Python symlinks
erroneously introduced by fixup_bundle. We also adjusted "refix_rpaths" to
be more accurate. We should not need "wrangle_bundle" when building and
installing a local development copy of KiCad.
Tested on msys2 which is the only place it would have been buggy
CMake seems to share the gdiplus linkage with the other dependencies automatically now
INSTALL(FILE) does not handle setting linux-specific attributes in the
same way that INSTALL(TARGET) does. This patch is suggested by
StefanBruens
Fixes https://gitlab.com/kicad/code/kicad/issues/9974
Currently, the SpaceNav library is only implemented for MacOS and
Windows. Until this can be correctly implemented for all supported
platforms, we need to make the option default off
ADDED: with cmake KICAD_MACOSX_APP_BUNDLE option the user can disable
the macOS app bundle creation when compiling on macOS. This permit to
use/install KiCad like any other *nix platform (/usr/bin, /usr/share,
ecc.). By default, cmake build the app bundle.
Although pcb_base_frame.cpp is in the pcbnew source tree, it is compiled
and included in pcbcommon.lib. Because pcb_base_frame has a dependency
on pcbnew_navlib, the latter also needs to be included in pcbcommon to
avoid linkage issues.
The superfluous references to pcbnew_navlib in the qa projects have been
removed.
Full support for using a 3Dconnexion device in the 3D viewer has been added. Full 3D navigation is available for both the orthographic and perspective projections. Commands are exported and can be assigned to 3D mouse buttons. Any limitations to the functionality are limitations of the installed 3Dconnexion driver for the device and OS.
ADDED: A build option KICAD_USE_3DCONNEXION (default = ON) has been added to the main CMakeLists.txt. The option controls whether the SpaceMouse support is compiled into the solution.
Found via `codespell -q 3 -S *.po,./thirdparty -L aactual,acount,aline,alocation,alog,anormal,anumber,aother,apoints,aparent,aray,dout,einstance,modul,ot,overide,serie,te,,tesselate,tesselator,tht`
On Linux, the documentation and help files are potentially installed to
a non-standard location (i.e., outside of /usr/share/doc/kicad/). This
can be the case when, e.g., multiple versions of KiCad are installed in
parallel. Making KICAD_DOCS available at run-time is the only viable
solution to allow the applications to find the help files in this case.
Fixes https://gitlab.com/kicad/code/kicad/issues/7874
This is a work-in-progress. It could use testing while I continue to fix
the remaining pieces.
There are some changes that will be needed for signing and notarization.
This currently relies on a Python tool I wrote (dyldstyle) to fixup
KiCad.app correctly. I would like any bundle fixing necessary to use a
built KiCad on macOS to live inside KiCad, rather than in
kicad-mac-builder or elsewhere. While I was experimenting, I found this
worked, however, and I would love to get extra hands testing.
I added a CMake argument, MACOS_EXTRA_BUNDLE_FIX_DIRS, for devs and
packagers who have extra directories they need to add to
fixup_bundle on KiCad.app.
There's an issue about differing behavior when KiCad is opened via
the command line or via Finder/launchd.
Introduce a new advanced config variable `KICAD_LIBRARY_DATA` which can
be used to move templates, symbols, footprints, and 3dmodels out of
`KICAD_DATA`. If not defined, everything is kept as before.
To facilitate this, PATHS::GetStockEDALibraryPath() is added. This
allows to differentiate code paths looking for EDA library data vs. code
paths looking for plugins, demos, and the like.
Thanks to Aimylios for the hints and suggestions with regards to the
stock EDA library data path handling on Windows and MacOS.
Fedora, Flatpak, Debian, and possibly other distributions as well, have
packaging helpers who will strip out debug symbols into separate debug
packages.
Currently, the explicitly added "-s" EXE_LINKER_FLAG renders these
automatically created debug packages completely useless, so this change
removes it.