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`
This is a bit of a hacky solution but in theory should work ok.
There was discussion of bringing in FindPython3 from upstream
CMake, which we could also do if someone is motivated...
Fixes https://gitlab.com/kicad/code/kicad/-/issues/8553
The goal of this work is to let developers run Python things
on macOS on their builds without generating a full
relocatable and redistributable build.
This is a WIP.
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
macOS bundling needs executable scripts to be handled
better by CMake than they were in the past.
Until we require 3.14 or newer, bring in the modules from
45ed314bff.
* Switch to using org.kicad.kicad as the main app ID
* Move the appstream file to a metainfo file
* Rename all metadata files to use the reverse DNS scheme
* Add header matching to mime type files where possible
* Add a mime type for gerber job files
* Add a QA test that verifies all the linux metadata files and
run it in CI
* Update the visible names in the launcher entries to be more
consistent with the internal visible names
* Update various strings and items in the metainfo file so they
are more descriptive and easier to read
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.
Bitmaps are now identified by an enum class instead of by pointers.
Bitmap loading and caching is now handled by a class in common, and
we no longer compile most bitmaps into the binary, so there is no
longer a bitmaps static library.
Instead, bitmaps are archived to a .tar.gz file which is installed
in ${KICAD_DATA}/resources/images.tar.gz
The source PNGs are checked in to Git as the original CPP files were,
so that people can build without the required dependencies to convert
SVGs to PNGs.
Initial support is also added for dark theme icons, although this
is not yet exposed in the GUI.
Stubs are present for multi-resolution image resources, but this is
not fully-baked yet and could use some refinement.
This will gracefully handle errors that prevent the file translation
by simply copying the file if they occur. This allows the build to
proceed and the logs to contain the error.
The BuildSteps folder now contains the CMake scripts that are
called during the build process as individual stages, while
the root CMakeModules directory contains the CMake files used
during the configuration phase.
There was an ABI change for 64 bit aligned vectors between gcc 5 and gcc 6
on a few 64 bit platforms, and gcc 10 reports "note" level warnings for
each affected access, which is very noisy and hides more important
information.
These notes are issued because there is no reliable diagnostic for actual
problems.
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
The config.h header for ngspice is not packaged with all platforms so
use pkg-config to fetch the version information when available. When
pkg-config is not available, check if the ngspice/config.h file is
installed on the system before including it to build the ngspice version
string. If neither pkg-config or ngspice/config.h is available set the
version string to "unknown".
Fixes https://gitlab.com/kicad/code/kicad/issues/4851
luz paz
Jon Evans
luz paz
Seth Hillbrand
Adam Wolf
Marek Roszko
Ian McInerney
Marcus A. Romer
Johannes Maibaum
Steven Falco
Simon Richter
Jeff Young
Wayne Stambaugh