Porting cmake-based core18-snap to core20-snap fails


i’m trying to port my snap from core18 to core20 and i can’t get it compiling completely.

These are the two parts which are working with core18 but not with core20:

    plugin: cmake
    source-type: tar
    source: https://github.com/Ultimaker/libArcus/archive/4.6.1.tar.gz
      - libprotobuf10
      - libpython3.6
      - libpolyclipping22
    plugin: cmake
    source-type: tar
    source: https://github.com/Ultimaker/CuraEngine/archive/4.6.1.tar.gz
      - libgomp1
    after: [libsavitar, libarcus]

CMake Error at CMakeLists.txt:23 (find_package):
By not providing “FindArcus.cmake” in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by “Arcus”, but
CMake did not find one.

Could not find a package configuration file provided by “Arcus” with any of
the following names:


Add the installation prefix of “Arcus” to CMAKE_PREFIX_PATH or set
“Arcus_DIR” to a directory containing one of the above files. If “Arcus”
provides a separate development package or SDK, be sure it has been

With the core18-based snapcraft.yaml the snap is generated perfectly, with core20 it always puts out the above error.

Here is the link to my core18-based YAML-file:

i assume this is similar to

Sorry, that doesn’t help. Strange thing:

When i’m setting “Arcus_DIR” to “$SNAPCRAFT_PART_INSTALL/usr/lib/… (and so on)”, the cmake-file is found but the so-library cannot be accessed.

Maybe the plugin does not correctly handle the SNAPCRAFT-paths?

when i said “similar” and pointed to it i meant you should indeed adapt it to your problem and experiment with setting

cmake-parameters: ["-DCMAKE_PREFIX_PATH="]

to be empty or to point to the correct place … my suspicion is that the cmake plugin simply dropped a lot more defaults it had in former versions …

1 Like

That looks to be the case. The v1 cmake plugin (used for core and core18 sets CMAKE_PREFIX_PATH to include the stage directory, where it’d pick up the cmake config from the previous part. The v2 plugin doesn’t.

Given that things like PKG_CONFIG_PATH are still being set in the v2 plugins world, this seems like something the v2 cmake plugin should still do.


That seems appropriate, thanks for looking into the root cause.