As was announced in the development news thread, the new content manager has now been merged to master.
At the moment it’s behind a config flag because it’s not fully featured yet, so if you compile, run cmake first and enable KICAD_PCM. You will also see KICAD6_3RD_PARTY environment variable in the Configure Paths dialog, the packages which can now be tested will be installed there. The footprint library must be added to a library table manually, the color themes and action plugins must be copied manually to their real destinations. As was said, it’s not ready yet for full user experience.
Some screenshots and instructions (in its current state) can be found in the original merge request.
I do not really understand why it’s hidden behind a config flag.
It is an extra hurdle for the people who have made plugins and want to integrate them in KiCad V6.
KiCad-nightly V5.99 is in nightly status, which means to me that not everything is expected to work perfectly.
I also understand that a half working Plugin & Content manager can lead to confused users. How about enabling it, but adding “experimental” to the menu entry?
Another possibility discussed in the merge request is to hide it behind an advanced config runtime option. that way it could be compiled by default for nightly builds but enabled by those users who are dedicated to test it. IMO that would be good.
Indeed. in Preferences / Preferences there is plenty of room to also tell something about the status of such features, and the intended audience. This, combined with action needed from a user to even see it in the menu will greatly reduce the amount questions about known limitations and not (yet) implemented features.
The same probably for the Altium importer. That one has been (partially?) working for a year or so.
But the PCM itself would be a better place. It already has the mechanisms for adding a description and version info and making things visible by installing them.
@qu1ck
Ah, that too. It has to have enough functionality to be useful. I was maybe a bit too enthusiastic by looking at some fancy screenshots. I’ll trust that you guys know what you’re doing.
But for some reason symbols defined in it are not found.
I am not an expert on cmake or clang vs gcc differences but I can’t really replicate your issue either. See if anything in your toolchain config or cmake config makes clang generate .so instead of an archive.
The lib is defined like any other in cmake itself:
I do use clang+lto almost everywhere so this might be an lto issue as oppose to a clang issue.
ill push kicad into clang_nolto build group and see what happens. LTO is well… funky and it would point to something.
Now if it doesn’t compile with just clang soemthing has gone wrong in kicad codebase
It’s also possible that I didn’t get the cmake config right as frankly I was just throwing things at it until it worked and then trimmed all the junk that wasn’t needed for it to work through trial and error.
If you still get an error with clang nolto please open a gitlab issue and attach your logs.
There has been total silence about this. I assume the end users who would be willing to test this aren’t compiling, and the development team don’t seem to do anything about this, either. It would really be better to compile this automatically and possibly add an advanced config flag.
It’s not clear to me how this official/unofficial division works. Are there any step by step instructions how to set up a repository and create packages? I could, for example, test my own test scripts. Anyway, I’m suspicious about having an official repository hardcoded (is it hardcoded?). At the moment it should be enough to build the feature by default, make it to be used by an advanced config flag and not have a default repository. IMO such a feature should never have a hardcoded default repository anyway.
some form of “hard-coded” default repository is required so that a new install is at least functional by default without having the user hunt some mailing list, forum etc… to find what it is.
However, having it as a configurable provides flexibility if there is a private source that has to be used, maybe pulling from multiple sources if all have a common structure
Why not hard-code a personal gitlab repository for now to ask as a sandbox to figure out all the nitty gritty before flipping (at v6 release) to an “official” kicad namespace location. it has to be in the kicad namespace at release to provide a degree of trust
Why not? A collection of plugins and libraries with KiCad team’s stamp of approval available for download right out of the box is the whole motivation behind this feature. If user has to google for repositories and manually add them before they can do anything it doesn’t really provide much value.
Official one will be hardcoded (i.e. preconfigured by default, you can remove it and/or add as many others as you want). It will also have some quality checks as well as code reviews for included packages.