kicad-developers team mailing list archive
Mailing list archive
Re: How to redefine default system footprint/symbols/packages3d/templates search paths at build time?
Hi Ian and Nick,
Am Sonntag, den 24.05.2020, 10:59 +0200 schrieb Nick Østergaard:
> Maybe some of thar stuff depends on CMAKE_INSTALL_PREFIX in some
> unexpected way?
It seems indeed that on Linux, setting DEFAULT_INSTALL_PATH doesn't have
the effect you would be expecting from reading the comment in
> The value of DEFAULT_INSTALL_PATH is expanded in config.h and used in
> the source code to define the base path for kicad search paths and
> environment variables.
Should I open a ticket for this?
> lør. 23. maj 2020 22.38 skrev Ian McInerney <Ian.S.McInerney@xxxxxxxx>
> > Have you tried redefining the environment variables to point to the
> > correct system libraries? Specifically I believe the 4 you need are:
> > KICAD_TEMPLATE_DIR (the templates)
> > KICAD_SYMBOL_DIR (the eeschema symbols)
> > KISYSMOD (the modules)
> > KISYS3DMOD (the 3d models)
I have tried that just now. It seems to work on the KiCad side, i.e.
setting those environment variables makes the paths show up as defined
in Preferences -> Configure paths.
OTOH, flatpak doesn't seem to like the fact that the packages3d
directory by default resides inside the modules directory. This doesn't
seem to work, but it's not primarily KiCad's fault and I think I can
work around this limitation by simply putting those two libraries to two
completely separate paths.
Yet, there seems to be another issue with the templates path at the
moment, which does not only get stuff installed from the kicad-templates
package, but there is also a "kicad.pro" (default?) project file coming
from the main application.
So far, thanks for the hints, guys! I will keep experimenting with the
different variables and see if I can come up with a solution that works
For the not-too-distant future (a.k.a. KiCad 6): Are there plans to
revamp the default library search paths? In general it seems to be a
quite thought through system, but then there are some rough edges here
and there, like the packages3d being inside the modules directory, plus
the templates coming from two different source packages.
And it would be great to know if the comment regarding
DEFAULT_INSTALL_PATH is simply not up to date on Linux, or if it is
indeed a bug that should be fixed?