That’s fine, the plugin manager is certainly a higher priority
Just 3. The 0.5 guy died last year…
For most of our projects files are in ../lib or similar. And KiCad uses an absolute path.
Funny(?!) thing is that a loooong time ago I submitted a patch (that was incorporated) to fix this problem. But when KiCad changed to sym-lib-table the dialog changed and the fix went away.
No gain for whom? The development team? So you put the pain in the users. KiCad 5 is very unfriendly for people using any kind of version control, and this is for anybody taking seriously his work. I hope KiCad 6 fixes it. I see an effort in this direction, thanks. But having 4 configuration files instead of 2 isn’t in the right direction.
You must also think about people contributing to make KiCad more usable. We aren’t part of the development team, but we fill a lot of gaps. Having to deal with a plethora of arbitrary file formats (some of them really strange) and tons of atomized configuration files is really dissapointing.
Why? IMO it’s better.
Could you elaborate?
Could you first? …
One example where multiple files are better than a single one is to have visibility options separate from lets say a library setup. The former you probably don’t want in version control while the later will need to be in there. Having the lib tables separate from the project file allows that.
KiCad looks for path substitutions inside of folders that are linked to by a path variable. So if you have a variable that points to whatever “…/” means in that context then it will use it. However you can manually use a setup with ${path variable}/../lib but i suspect doing this automatically would be a bit strange (just imagine how many options kicad would find with just two or three possible path variables)
I’m not asking to remove the kicad_prl. I have my doubts about it, but never asked this.
I’m asking to avoid *-lib-table files.
I didn’t mention, but fp-info-cache is another ridiculous file.
I am highly doubtful that this thread is going to go productive places.
2 Likes
fp-info-cache is there to reduce the loading time when one needs access to footprints (for example when opening the footprint editor). I think there are plans to move it out of the project folder and into a central location but i could misremember it. It is a file that does (or possibly even should not) be included in version control.
(It basically holds info to be able to know what footprints exist without needing to open every footprint file first which takes quite a bit of time especially if you have a slow hard disk or if your file system does not handle access to small files well)
Ok:
- Performance. Opening 100 files instead of 1 is much faster.
- Disk space. Small files takes a disk space unit. Having tons of small file wastes disk space.
- Maintainability of the code. Having tons of functions to deal with tons of files is much more complex than having just one.
- I’m tired of explaining to new users at work which files must be included in a repo and which ones don’t. More files, more problem.
- Simplicity, the KISS principle.
- When you enter a directory and find tons of files you lose time.
I can go on, but this list is enough to illustrate my point of view.
I know what’s the purpose. The location is ridiculous. These files belongs to the directory where all the libs are placed (if you have more than one dir you should have more than one). For Linux this file should in /usr/share/kicad/modules/ and be generated only when /usr/share/kicad/modules/* changes (which is never, just including a pre-computed file with the package should be enough).
Having it at project level is a waste of resources, and doesn’t help much. It gets regenerated for each new project and can grow to a ridiculous size.
There are just 2 useful cases:
- Files that are in the system level library dir: You get it replaced by ${KISYSMOD} or ${KICAD_SYMBOL_DIR}
- Files that are “close” to the project. You get them relative to ${KIPRJMOD}
Absolute paths aren’t are useless in any case. I can imagine an absolute path only used for a Windows system when the library you are adding is in a different drive than the project, basically: when is impossible to create a relative path.
I’m sick of getting .zip files to review with absolute paths that are useless in any machine other than the machine used by the person that created it.
And I trie it with the last nightly before even mentioning the issue here and got a nasty absolute path exposing my directory structure, which could be a potential security issue.
@set your tone in this thread has been pretty negative. Calling things “ridiculous” and “really disappointing” does not really invite a useful discussion.
If KiCad has some fault for you, please consider that:
- There might be reasons or history behind it that you do not know
- Fixing any one particular fault has to be balanced and prioritized with all the other thousands of things to do
- Using such negative language does not encourage other users or developers to work with you.
Ok, sorry. Shouldn’t use the ridiculous word.
For what it’s worth, the fp-info-cache issue is known, there just hasn’t been time to fix it yet.
Thanks. As I said: I see moves in the right direction, just think about the things I see deviating from this direction.
You have information in:
- The schematic/PCB files.
- In the .kicad_pro
- In the .kicad_prl
- In sym-lib-table
- In fp-lib-table
And with each new version the list grows. I’m asking to consolidate 4 and 5 in 1 to 3.
I don’t know if there is an existing issue open for that so I’d encourage you to open one if you’d like (if we ever did get rid of the project-local library tables, we would store the project-local library info in the kicad_pro file)
Ok I added this:
2 Likes