complicated conan compiling

[yonihik]

hi :)
I have tried compiling CuraEngine on my machine today and went through some trouble, and i am not sure if it is since i'm a beginner or that this is something that could be improved(up until this morning i have never heard of conan)

First issue was that not all packages required were on the ultimaker remote.

I think a good solution may be adding 'conan-center' to the remote list in the config

Second and most major issue relates to Ultimaker/libSavitar#42, basically i didn't have sip installed.
if you just pip install sip the linking of pyArcus fails.

The solution is to pip install sip==6.5.1, maybe it's a good idea to add this to the documentation, since is required to conan install.

Another thing i realised is that conan build . works surprisingly well, maybe we could update the documentation to reflect that .e.g

To build CuraEngine you setup conan and then run:
pip install sip==6.5.1
conan install . -pr:b cura_build.jinja -pr:h cura_release.jinja --build=missing
conan build .

[yonihik]

@jellespijker i noticed you were active about recent conan related changed, and building issues, i would love for your opinion on this :)

[jellespijker]

Hi @yonihik

Thank you for your feedback. I'm sad to hear you had some troubles with compiling CuraEngine from source. We're in the progress of switching to a different approach for building Cura (and all of her dependencies). These will be build with GitHub actions, using Conan and pip as dependency managers. But due to our busy schedule these changes are a bit stretched out at the moment. Bare with us please because once these changes are actually implemented, build Cura and compiling CuraEngine should be greatly simplified. It was not uncommon for a developer (even full-time Cura devs such as myself) to require a day or two to get our machine in such a state that we could work on Cura, Uranium, CuraEngine etc.

We came from a place where we had (still have actually) one repo called cura-build-environment with a big sequential build script. This resulted in a very fragile build process, with time consuming debugging steps.

We will build all our repo's on a push/pr event for that specific repo and upload the conan recipe and build artifacts to a JFrog Artifactory server. If a project such as CuraEngine requires a Arcus it will get the recipe of Arcus from that Artifactory server and either download a pre-build binary or build it locally if there are no pre-build binaries for that dependency. The graph below is an example for Savitar but it applies to all our repos.

To put it short we fully place the responsibility of how a project/dependency should be build in the conan recipe and cmake files of that specific repository. This is why I am a bit reluctant to add the sip requirement in this repository, because technically sip is a requirement needed to build pyArcus (a component of Arcus). It would make more sense imo to add sip as a build requirement for our projects which require sip to be installed as an build tool (such as Arcus). Conan has tools for this in place and I was in the process of creating such a recipe https://github.com/Ultimaker/conan-ultimaker-index/tree/main/recipes/sip which could then be used by Arcus if it needs to build from source locally. But we're pressed for time at the moment and finishing that recipe with the sip build tool will in all likelihood be done in a month or two (I might make those changes this weekend in my own time though, because I find it annoying as well)

You're right that the conan-center should be added as a remote. The current Artifactory server, hosting the recipes and Artifacts, was my own personal free-tier subscription for trying out this workflow, and we exceeded the maximum allotted bandwidth for this month. I updated the readme yesterday with instructions how to pull in a branch with the conan-center remote https://github.com/Ultimaker/CuraEngine#how-to-install . This should install the following remotes https://github.com/Ultimaker/conan-config/blob/CURA-9177_Fix_CI_CD/remotes.txt

The conan build can indeed be part of a workflow, but that doesn't integrate well with IDE's. I personally use Clion, which has a Conan plugin ( https://docs.conan.io/en/latest/integrations/ides.html ) This will automatically perform the conan install steps before a CMake refresh.

Since this issue gave us an opportunity to add a bit of a backstory I will leave this issue open and pin it, such that it can be found easier, until we have switched over completely.

[Dogm]

where i can get cura_release.jinja or cura_debug.jinja ???

[Piezoid]

@Dogm

where i can get cura_release.jinja or cura_debug.jinja ???

conan config install https://github.com/ultimaker/conan-config.git should install them for you under your conan profile directory.

[Dogm]

https://github.com/Ultimaker/conan-config/tree/master/profiles

[Dogm]

cura.jinja
cura_build.jinja

only this files contains

[Dogm]

documentation missmatch

[Dogm]

conan install . -pr:b cura_build.jinja -pr:h cura_release.jinja --build=missing

cause errors

[Dogm]

i found similar on this repo but it have some differences

https://github.com/jellespijker/conan-config/tree/main/profiles

[jellespijker]

Readme is out of date for CuraEngine see Wiki in Cura repository about running from source

See also this issue #1703