kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #43913
Re: How to redefine default system footprint/symbols/packages3d/templates search paths at build time?
(see comments inline).
On Sun, May 24, 2020 at 1:34 PM Johannes Maibaum <jmaibaum@xxxxxxxxx> wrote:
> 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
> CMakeLists.txt:
>
> > 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.
> (from:
> https://gitlab.com/kicad/code/kicad/-/blob/5.1/CMakeLists.txt#L179)
>
> 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.
>
Yes, you should be able to put the 3d models in a directory alongside the
footprints, not inside them, and as long as you set the environment
variable correctly I believe it will work (this is how I have my copy of
the git libraries setup).
> 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.
>
> The templates get a bit difficult. The symbols, footprints and main
application all install things into the templates folder - specifically the
template project, the default symbol library table, and the default
footprint library table. The easiest packaging split would be to just keep
the 3d models separate and leave the templates/symbols/main application all
in one package (that is how Fedora does it). If you want to get more
complicated, you can look at how Debian has structured their packages,
since they split everything into separate packages.
>
> 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 now.
>
> 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.
>
The 3d model search system is a known limitation, and it is on the future
roadmap to switch over to using library tables like the footprint/symbol
libraries instead of the current hard-coded paths - but that won't be for
v6.
>
> 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?
>
>
> Johannes
>
>
Follow ups
References