Updating Cura to 5.2: help needed with CMake and their build system

[Miro Hrončok]

Hello folks,

I'd love to see Cura updated to 5.2 at least in Rawhide.

However, it is a complex stack. Usually the following packages need to be 
updated (in this order):

libsavitar
libarcus
libnest2d
python-pynest2d
python-uranium
CuraEngine
cura
cura-fdm-materials

However in Cura 5, the upstream CMake build system has been completely 
redesigned. Now the instructions are:

https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source

E.g.:

   pip install conan --upgrade
   conan config install https://github.com/ultimaker/conan-config.git
   conan profile new default --detect --force

I have never used conan to build Fedora packages.

When I try to ignore it for a while and try to proceed with libarcus 5.2.2, I 
end up with:

CMake Error at CMakeLists.txt:4 (find_package):
   By not providing "Findstandardprojectsettings.cmake" in CMAKE_MODULE_PATH
   this project has asked CMake to find a package configuration file provided
   by "standardprojectsettings", but CMake did not find one.

   Could not find a package configuration file provided by
   "standardprojectsettings" with any of the following names:

     standardprojectsettingsConfig.cmake
     standardprojectsettings-config.cmake

   Add the installation prefix of "standardprojectsettings" to
   CMAKE_PREFIX_PATH or set "standardprojectsettings_DIR" to a directory
   containing one of the above files.  If "standardprojectsettings" provides a
   separate development package or SDK, be sure it has been installed.


Where do I look for this Findstandardprojectsettings.cmake?

I only found one version bundled in another application:

https://github.com/flameshot-org/flameshot/blob/master/cmake/StandardProj...

Is there somebody who is more used to CMake who would be able to help me with this?

Thanks,
-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Tom Callaway]

This is a hot mess. conan's model is to store prebuilt artifacts on remote
servers, and the new Cura build model is to pull dependencies from that.
This includes any of its own dependencies that you build.

It's possible to ugly hack around a lot of this, but even with doing that,
the result will be super super ugly because:

A) There is no cmake install logic anymore, because it expects you to make
a conan package from your build and shove it into a conan repo.
B) There are no package specific cmake files anymore, because, why do you
need them? Just get the prebuilt bits from their conan repo.

Oh, and this doesn't seem related to conan, though, maybe, but:

C) They no longer apply any soversion on the shared libs. I don't know if
they've just abandoned any sort of API versioning entirely, which would
really suck for us, or if they're just being lazy, or both?

I've spent a few hours banging myself bloody against conan and the
conclusion I have come to is that whoever built this tool actively despises
Linux distributions.

I think if we really want to keep Cura in Fedora packages, we will either
need to work directly with upstream to come up with some other entirely
local (not networked) build/install/dependencies model OR we maintain our
own CMake only setup (which will not be fun to maintain, but is way cleaner
than the hack job that is conan).

*****
Anyway, I made a libsavatar 5.2.2 package as a proof of concept. Comments
all over the spec file. I hope this helps you, Miro.

SPEC: https://spot.fedorapeople.org/libsavitar.spec
SRPM: https://spot.fedorapeople.org/libsavitar-5.2.2-1.fc38.src.rpm

~spot

P.S. While I was poking this, I discovered that conan hardcodes a list of
valid versions for EVERY COMPILER EVER. And of course, it didn't have gcc
13. I would send them a pull request to fix this, but I really don't want
to help them in any way because their tool is bad and it should not be used
by anyone. Maybe that's a bit harsh, but... *sigh* Anyway, I patched it
into the conan package in Fedora rawhide. Best I can tell, nothing in
Fedora BR's conan, and I can guess why, so this might not have been caught
later until someone tried to use conan on F38.

[Miro Hrončok]

On Fri, Jan 20, 2023 at 11:16 PM Tom Callaway <spotrh(a)gmail.com&gt; wrote:
>  This is a hot mess. conan's model is to store prebuilt artifacts on remote servers,
> and the new Cura build model is to pull dependencies from that. This includes any of its
> own dependencies that you build.
>
>  It's possible to ugly hack around a lot of this, but even with doing that, the result
> will be super super ugly because:
>
>  A) There is no cmake install logic anymore, because it expects you to make a conan
> package from your build and shove it into a conan repo.
>  B) There are no package specific cmake files anymore, because, why do you need them? Just
> get the prebuilt bits from their conan repo.
>
>  Oh, and this doesn't seem related to conan, though, maybe, but:
>
>  C) They no longer apply any soversion on the shared libs. I don't know if they've
> just abandoned any sort of API versioning entirely, which would really suck for us, or if
> they're just being lazy, or both?
>
>  I've spent a few hours banging myself bloody against conan and the conclusion I have
> come to is that whoever built this tool actively despises Linux distributions.
>
>  I think if we really want to keep Cura in Fedora packages, we will either need to work
> directly with upstream to come up with some other entirely local (not networked)
> build/install/dependencies model OR we maintain our own CMake only setup (which will not
> be fun to maintain, but is way cleaner than the hack job that is conan).
>
>  *****
>  Anyway, I made a libsavatar 5.2.2 package as a proof of concept. Comments all over the
> spec file. I hope this helps you, Miro.
>
>  SPEC: https://spot.fedorapeople.org/libsavitar.spec
>  SRPM: https://spot.fedorapeople.org/libsavitar-5.2.2-1.fc38.src.rpm
>
>  ~spot
>
>  P.S. While I was poking this, I discovered that conan hardcodes a list of valid versions
> for EVERY COMPILER EVER. And of course, it didn't have gcc 13. I would send them a
> pull request to fix this, but I really don't want to help them in any way because
> their tool is bad and it should not be used by anyone. Maybe that's a bit harsh,
> but... *sigh* Anyway, I patched it into the conan package in Fedora rawhide. Best I can
> tell, nothing in Fedora BR's conan, and I can guess why, so this might not have been
> caught later until someone tried to use conan on F38. 
Thanks. Unfortunately, I wasn't able to dedicate my time to this since
I started this thread.

I was about to suggest retiring Cura and letting our users use the
Flatpak instead, but I found this:

https://github.com/flathub/com.ultimaker.cura/issues/6

Apparently, we are not the only ones struggling with this.

Debian has 5.0: https://packages.debian.org/experimental/cura
https://packages.debian.org/source/experimental/libsavitar

But that still apparently uses cmake.