5.99 Content Manager

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?

1 Like

linkage issue here due to nlohmann::json_uri::update must be an ABI mismatch somewhere

You don’t need to copy anything, they are picked up automatically. Only libraries need to be manually added to lib tables for now.

Can you post full error?

It will be switched to default ON when it’s more polished. Right now there isn’t even a proper repository setup, just a testing one.

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.

3 Likes

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.

2 Likes

I tested before writing that, but I have to try again.

EDIT: it seems to work now. The plugin is loaded automatically and the color themes are visible in the list. Great!

here you go: https://gist.github.com/eeyrjmr/4756835f11e7052a10b43b80cd416255

For some reason your cmake config makes clang build libnlohmann_json_schema_validator.so instead of just an archive that I get on my gcc build.

That lib then gets linked to kicad executable

/usr/lib/llvm/12/bin/clang++ -O3 -pipe -march=native -mtune=native -pthread -Wall -Wsuggest-override -Winconsistent-missing-override -Werror=vla -Wimplicit-fallthrough -Werror=return-type -Wshadow -Wsign-compare -Wmissing-field-initializers -Wempty-body -Wreorder -Wmismatched-tags -Wno-psabi -Wl,-O3 -Wl,--as-needed kicad/CMakeFiles/kicad.dir/dialogs/dialog_template_selector_base.cpp.o kicad/CMakeFiles/kicad.dir/dialogs/dialog_template_selector.cpp.o kicad/CMakeFiles/kicad.dir/dialogs/panel_kicad_launcher_base.cpp.o kicad/CMakeFiles/kicad.dir/dialogs/panel_kicad_launcher.cpp.o kicad/CMakeFiles/kicad.dir/files-io.cpp.o kicad/CMakeFiles/kicad.dir/import_project.cpp.o kicad/CMakeFiles/kicad.dir/kicad.cpp.o kicad/CMakeFiles/kicad.dir/kicad_manager_frame.cpp.o kicad/CMakeFiles/kicad.dir/kicad_settings.cpp.o kicad/CMakeFiles/kicad.dir/menubar.cpp.o kicad/CMakeFiles/kicad.dir/project_template.cpp.o kicad/CMakeFiles/kicad.dir/project_tree_pane.cpp.o kicad/CMakeFiles/kicad.dir/project_tree.cpp.o kicad/CMakeFiles/kicad.dir/project_tree_item.cpp.o kicad/CMakeFiles/kicad.dir/tools/kicad_manager_actions.cpp.o kicad/CMakeFiles/kicad.dir/tools/kicad_manager_control.cpp.o -o kicad/kicad  common/libcommon.a  common/libgal.a  common/libcommon.a  -L/usr/lib64  -pthread  -lwx_gtk3u_gl-3.0-gtk3  -lwx_gtk3u_aui-3.0-gtk3  -lwx_gtk3u_adv-3.0-gtk3  -lwx_gtk3u_html-3.0-gtk3  -lwx_gtk3u_core-3.0-gtk3  -lwx_baseu_net-3.0-gtk3  -lwx_baseu-3.0-gtk3  -lwx_gtk3u_propgrid-3.0-gtk3  -lwx_baseu_xml-3.0-gtk3  -lwx_gtk3u_stc-3.0-gtk3  -lwx_gtk3u_richtext-3.0-gtk3  kicad/pcm/libpcm.a  common/libcommon.a  common/libgal.a  scripting/libscripting.a  common/libcommon.a  common/libgal.a  scripting/libscripting.a  libs/kiplatform/libkiplatform.a  -lgtk-3  -lgdk-3  -lpangocairo-1.0  -lpango-1.0  -lharfbuzz  -latk-1.0  -lcairo-gobject  -lcairo  -lgdk_pixbuf-2.0  -lgio-2.0  -lgobject-2.0  -lglib-2.0  /usr/lib64/libcurl.so  libs/kimath/libkimath.a  /usr/lib64/libGLEW.so  /usr/lib64/libcairo.so  /usr/lib64/libpixman-1.so  /usr/lib64/libGL.so  /usr/lib64/libGLU.so  /usr/lib64/libpython3.9.so  -L/usr/lib64  -pthread  -lwx_gtk3u_gl-3.0-gtk3  -lwx_gtk3u_aui-3.0-gtk3  -lwx_gtk3u_adv-3.0-gtk3  -lwx_gtk3u_html-3.0-gtk3  -lwx_gtk3u_core-3.0-gtk3  -lwx_baseu_net-3.0-gtk3  -lwx_baseu-3.0-gtk3  -lwx_gtk3u_propgrid-3.0-gtk3  -lwx_baseu_xml-3.0-gtk3  -lwx_gtk3u_stc-3.0-gtk3  -lwx_gtk3u_richtext-3.0-gtk3  thirdparty/json_schema_validator/libnlohmann_json_schema_validator.so

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:

add_library( nlohmann_json_schema_validator
    json-schema-draft7.json.cpp
    json-uri.cpp
    json-validator.cpp
    json-patch.cpp
    string-format-check.cpp
)

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 :slight_smile: 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.

There’s silence because work on official repository is stalled, I’m waiting for code reviews for weeks: https://gitlab.com/kicad/code/kicad/-/issues/9046#note_666806207

Without a repository this feature will not be enabled by default.

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.

As soon as repository is setup I’ll start on that. Short version is that for a repository you only need 2 json files: repository metadata and package metadata.
Examples are here https://gitlab.com/qu1ck/kicad-pcm-repository
Schema is here https://gitlab.com/kicad/code/kicad/-/blob/master/kicad/pcm/schemas/pcm.v1.schema.json

That’s exactly where we are. There is a redirect to my test repository at the moment, if you compile the feature you will see that.

keep trying to :slight_smile: its not a clang and/or lto issue :slight_smile: it won’t compile with gcc, at least 2 weeks ago. i might try now to see

Share your compile log with gcc