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.
There is no CMake target property PRIVATE_INCLUDE_DIRECTORIES, just
INCLUDE_DIRECTORIES (PRIVATE and PUBLIC directories) and
INTERFACE_INCLUDE_DIRECTORIES (PUBLIC and INTERFACE directories).
Building on Linux with -DKICAD_USE_EGL=ON but without a system-wide GLEW
fails without this change.
wxWidgets 3.1.5+ on Linux will compile with the Wayland EGL
canvas as the backend instead of the X11 backend. This requires a
version of GLEW compiled with the proper EGL defines and a different
header/code for certain parts that are X11 GLEW specific.
This introduces an in-tree version of GLEW that will be built with the
GLEW_EGL flag then statically linked into the KiCad executables when
EGL support is needed.
We want to be somewhat standards compliant if we can.
There is a small complication, which we work around:
gcc sets __STRICT_ANSI__ in "c++11" mode (the non-strict mode would be
"gnu++11"), which causes the "strdup" definition to go away. If wx < 3.1 is
compiled with GNU extensions, it just forwards the wxCRT strdup function to
system strdup and doesn't create a definition for the wxCRT function, and
when a program is then compiled in strict mode against that, the wxCRT
function is missing.
From 3.1 onwards, the function is provided unconditionally in wx, so the
workaround is no longer needed there.
This moves the generated files out of the source tree and into
the build directory. They are now regenerated each time they are
needed, based on the timestamp of the generated file compared to
the timestamp of the lemon file.
To do this, we also bundle lemon into the thirdparty directory
and build it for ourselves since it is a very tiny program and
not all platforms seem to distribute it in a consistent manner.
Fixes https://gitlab.com/kicad/code/kicad/issues/5013
jean-pierre charras
Seth Hillbrand
Marek Roszko
Marcus A. Romer
Adam Wolf
Ian McInerney
Johannes Maibaum
Jon Evans
Simon Richter
Michael Kavanagh
Ian McKellar