Cura: Undefined CuraSDKVersion in CuraVersion.py causes a runtime error

[krop]

Using openSUSE packages tracking the master version.
Cura's CMakeLists.txt contains:

set(CURA_SDK_VERSION "" CACHE STRING "SDK version of Cura")

as a result, CuraVersion.py contains:

CuraSDKVersion = ""

and starting Cura fails to start because its plugins expect the SDK version to be 6.0.0. CuraApplication.py line 132 imports the empty version and the version defined on line 139 is not used.

[MainThread] UM.PluginRegistry.loadPlugin [410]: Plugin [ConsoleLogger] with API version [6.0.0] is incompatible with the current API version [0.0.0].
[MainThread] UM.PluginRegistry.loadPlugin [410]: Plugin [CuraEngineBackend] with API version [6.0.0] is incompatible with the current API version [0.0.0].
[MainThread] UM.PluginRegistry.loadPlugin [410]: Plugin [ConsoleLogger] with API version [6.0.0] is incompatible with the current API version [0.0.0].
[MainThread] UM.PluginRegistry.loadPlugin [410]: Plugin [OBJReader] with API version [6.0.0] is incompatible with the current API version [0.0.0].
[...]

[smartavionics]

I don't know what the Cura devs do but when I build my Cura releases I provide a value for that, currently 6.0.0.

[smartavionics]

I have defined it in projects/Cura.cmake in the cura-build repo.

[krop]

I have defined it in projects/Cura.cmake in the cura-build repo.

cura-build is useless for packagers. uranium, curaengine, cura etc... are different packages in distributions. The version shall be defined where it's needed, ie: in the cura repo

[smartavionics]

Yes, I can understand that.

I use cura-build to build my master branch releases but for myself I just build in the individual repos as required and do a local install into /opt/cura.

[smartavionics]

It does seem weird that the cura repo doesn't define the SDK version.

[adrianschroeter]

JFYI, this is solved in the packages by manually defining it.

But I agree that it is a bit crued that uranium defines a API version and I have to define the same version manually in cura builds. That makes the check actually obsolete ;)

[salfter]

Just ran into this while updating my Gentoo ebuilds. I was already patching CMakeLists.txt to change CURA_VERSION from "master" to the proper value; now it's also setting CURA_SDK_VERSION.

I also had to tweak my curaengine ebuild as the build process for that now tries to download additional code from GitHub while make is running, which seems like a Bad Idea. I patched out that behavior and set the ebuild to grab a particular commit of stb and dump it where it can be found during compilation.

[MathyV]

@salfter there's actually a separate package dev-libs/stb in portage since the last version 3.6 to handle that issue.

[Ghostkeeper]

We set the value in the CMake interface rather than hard-coding it in CMakeLists.txt or the .cmake files. That way we can freely adjust those build settings for different branches or different special-made builds.

The intended workflow is:

• Clone.
• Run CMake.
• Open CMake-GUI or ccmake or whatever you'd prefer.
• Set the Cura version correctly, adjust the SDK version, etc. if you need to.
• Run make install or the equivalent for your generator.

When building a release, we have our build server call CMake with some -D parameters to pre-set them to the desired values.

[MathyV]

Is it documented somewhere what the official build server parameters are?
This way distributions can package their own builds according to your
standards without the need of hunting down these version numbers and
possible other parameters we're missing.

On Wed, Mar 27, 2019, 16:20 Ghostkeeper [e-mail] wrote:

We set the value in the CMake interface rather than hard-coding it in
CMakeLists or the .cmake files. That way we can freely adjust those build
settings for different branches or different special-made builds.

The intended workflow is:

• Clone.
• Run CMake.
• Open CMake-GUI or ccmake or whatever you'd prefer.
• Set the Cura version correctly, adjust the SDK version, etc. if you
  need to.
• Run make install or the equivalent for your generator.

When building a release, we have our build server call CMake with some -D
parameters to pre-set them to the desired values.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/5142#issuecomment-477205555,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGGPA-Fxx1i4js94tcHtEcH4MRX2umd2ks5va4w1gaJpZM4Z4K-F
.

[Ghostkeeper]

No, because we keep changing them and that would again require us to change it in two places. For one, we give a different extra version for every build our automated build system makes so that we can distinguish them.

We should have sane defaults in CMakeLists.txt though that don't need to be adjusted if you want to create a build of your own.

[MathyV]

Can you make the build system output them somewhere in the AppImage where
packagers could fetch them?

Op wo 27 mrt. 2019 om 17:25 schreef Ghostkeeper [e-mail]:

No, because we keep changing them and that would again require us to
change it in two places. For one, we give a different extra version for
every build our automated build system makes so that we can distinguish
them.

We should have sane defaults in CMakeLists.txt though that don't need to
be adjusted if you want to create a build of your own.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/5142#issuecomment-477237807,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGGPA5jJuYpAThLtTsUMc5hZRp9fXKRlks5va5t0gaJpZM4Z4K-F
.

[Ghostkeeper]

Yeah, they are put in CuraVersion.py inside the AppImage. Though the main version number in that file has been "collapsed" to one semantic version number rather than 3 separate variables for major, minor and patch.