mirror of
https://github.com/torvalds/GuitarPedal.git
synced 2025-12-19 15:42:19 +00:00
0461cdf391
I'm not loving how KiCad does 'projects', but I made it worse by just
dealing with this all wrong.
To me, a "project" is the whole thing, so when I've split things up into
multiple pieces, they are all part of one big project. But that's not
how KiCad thinks of things.
To KiCad, a project is just a single PCB, and while there are plugins to
deal with that (from a quick look, KiKit would be a great idea), I'm not
quite ready go there.
So my "project" is a collection of several KiCad projects, and then I
used global symbol and footprint libraries that I just pointed at the
directory they all share. That seemed like the simplest solution to the
disconnect in what "project" means.
But simple or not, it turns out to be a horrible model because the
disconnect means that now your (to you) project-specific libraries end
up being in the global KiCad setup, and makes it all painful to move
between machines etc.
It's also nasty because KiCad only understands about it's own local
project root ("${KIPRJMOD}"), and to get to the "real" project root I
then had to use "../symbol" to go up to the top-level symbol.
And that then causes more problems if you want to have a different
directory hierarchy and have sub-projects that are deeper in the
hierarchy.
In other words, there's just a bad impedance match between the KiCad
notion of "project" and the actual real project notion.
This improves on the situation by making the libraries local to the
KiCad project, and then just pointing them at the global project
libraries individually.
Sadly, while that takes care of loading symbols and footprints - because
they have their per-project path configuration, it doesn't solve the
simulation file paths. I can't find any per-project path for loading
simulation files, and the whole "${KIPRJMOD}/.." approach has the same
issue with nested hierarchies.
The best I could do is to introduce a per-project 'TOPLEVEL' text
schematic variable, which then does work in simulation path, and I can
use "$(TOPLEVEL}/symbol" for those.
There might be better ways to do this, but this seems to work for now.
Now you have to make each subproject have those pointers, but it should
mean that I can have hierarchical projects, and this "my project" vs
"kicad project" thing is at least a bit more explicit and should travel
between machines as part of the whole git tree better.
Maybe some day kicad will support this kind of higher-level project view
natively (while googling this I found that I'm definitely not the first
person to have wanted kicad to better support multiple pcb's), but for
now I think this is at least better than my previous (dis)organization.
Also make the pointer to external spice library directory be a symlink
rather than more explicit ".." hackery.
I wish I could just put those external spice files all directly in the
git tree, but for some unfathomable reasons some manufacturers limit
sharing of their spice files even when they are public and used to
support the hardware they sell. Cray-cray, but I suspect some people
were dropped on their head a few too many times as babies. Maybe they
were too ugly and their mothers recoiled in horror?
Anti-moral of the story: don't be ugly.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
5 lines
124 B
Plaintext
5 lines
124 B
Plaintext
(fp_lib_table
|
|
(version 7)
|
|
(lib (name "Mylib")(type "KiCad")(uri "${KIPRJMOD}/../Mylib.pretty")(options "")(descr ""))
|
|
)
|