-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CMake: Bringing back ArcusConfig.cmake generation #138
Conversation
I don't see why it has been removed, but I need it to build Cura myself.
Just noticed I need to put more time into bringing this back.. |
That looks better for me now.. 😇 |
@thopiekar can you explain why you need it. And I want to keep the CMake logic for to a bare minimum. We will be using Conan to consume this package. Otherwise we will have to maintain multiple methods. Imo CMake is great for compiling and linking, but not so much for dependencies and installing. Conan handles those much better. I have a feeling that Conan could serve you as well. So if you could explain what your workflow is maybe I can accommodate that in our new workflow as well. |
For an example in a consumer side look at the workflow in Curaengine https://github.com/Ultimaker/CuraEngine/blob/CURA-9177_Fix_CI_CT/.github/workflows/conan-package.yml It is now possible to install the (specific/latest) Arcus package with a single comand and consume it downstream. conan install arcus/latest@ultimaker/stable -pr:b cura_build.jinja -pr:h cura_release.jinja --build=missing Should take care of installing Arcus, Protobuf and zlib and generate the cake find packages and modules. Keep in mind that linking is now done with |
Check the readme of that Curaengine branch for more information |
Well, letting conan generate stuff that is missing in our CMake projects is something is really dislike. So would prefer to either let CMake do the job and let it generate the files needed for further development or call conan to generate them for us during target Don't get me wrong it is really great that someone is reviewing all the build scripts after years and I saw good improvements e.g. installing libArcus (or other projects - I might mix things up here) to an prefix, but having these Find*.cmake or *Config.cmake files missing is a real pain. |
Additionally: Same applies for PPA builds, which I plan to drop to support in any way.. During builds via launchpad.net your build is disconnected from the internet. |
@thopiekar good points. I am wondering if CMake and the compiler also build from source and all the python dependencies are also build from source. Or that you build the Cura C++ dependencies from source to ensure binary compatibility? I don't know how much you known about Conan so I might be explaining stuff you already know. But the way it works is that it looks in the requirements specified in conanfile.txt or conanfile.py (in our case). It then checks the local package repository (usually found in ~/.conan/data) for a conan package which correspondence with the names and versions specified by our project. If it can't be found locally it can look online for the recipes. But this can be disabled if required/wanted. If will then generate a unique hash, depending on the OS, Architecture, Compiler and package options. and it will look if the package was previously build locally, if not it can look online in the above mentioned remotes. If it finds the binaries there it can download them, if not these dependencies will be build locally. To make sure they have the specified OS, Architecture, Compiler and options. But if they are online you can download them if you want to. This is the reason for a huge speed up in our build setup. It will only build if required, if they are build we'll upload them to our Artifactory such that they can be used by others or subsequent runs. When Conan build the binaries it acts as nothing more than a wrapper. A CMake project such as arcus will just call the CMake configure and CMake build commands. Build artifacts, source files and resources are then packaged by Conan. With Additional information about the Compiler flags, environmental settings used and the used dependencies. That package information is used by Conan to generate the information for the build systems in consuming packages. Such as But it can also auto generate a virtual environment such as the one below
I'm not that familiar with flatpack generation or building for PPA. Since I run on an Arch-based distro.
Is the reason that you want to build everything from source because you want to ensure binary compatibility? If so Conan takes care of that. It offers solution for generating a Flat Package https://docs.conan.io/en/latest/integrations/deployment/flatpak.html#deployment-flatpak Once I got it up and running for Cura (and therefore all of her dependencies)
this will create a json file with all the relative information which can then be used to collect and package everything And Yes, you can do the above command in such away that every Conan managed dependency is build from source each time I want to stretch that I'm not opposed to bringing back the old ArcusConfig, but I want to guard against us having to support multiple ways of installing and managing dependencies. This is in my opinion the reason why we had such trouble (3 months) of upgrading to PyQt6 on our build server. While I got it almost up and running in less in a couple of days when I switch to a complete Conan set-up. |
That's very interesting! I'll definitely look into how the flatpak generation works. Many thanks for keeping in touch on this and for your interest! |
PS: I noticed for clipper and stb, that conan is providing these cmake files I mentioned before. As previously said, I would prefer to use whatever works with the original project, since these files are injected by conan and thus building the whole thing will only work with conan this way, which I don't think is wise. |
@nallath fyi We should also discuss maintaining multiple installation methods next Monday. |
The most pragmatic solution for now is to merge this PR, since that would allow you to keep your current way of working and once everything is finished you could check if Conan and it's deploy generator could also serve you. Which I believe it will, because I'm planning to create an AppImage generator, NSIS and DMG generator. But keep in mind that you probably need to patch things up downstream, such as Curaengine. Since we change the CMake targets and namespace there to all lowercase. |
But I will discuss things with @nallath next Monday and I will come back to you |
The clipper recipe shows indeed that it uses a CMakeLists.txt, but this is nothing more then making sure the settings provided by Conan can be used. The add_subdirectory still includes the original CMakeLists.txt in the source_folder for the cop module. https://github.com/conan-io/conan-center-index/blob/master/recipes/clipper/all/conanfile.py |
Sure, but give me some time to complete my Flatpak PoC. Doesn't make sense if I don't get my work done, you merge my stuff and mess up your workflow (eventually) for no good reason. |
Thanks for this PR, it made me gain some time for my libArcus package. A couple more things are needed to still have a working build system when conan is useless
and fix the versioning which got broken by the recent changes:
|
I don't see why it has been removed, but I need it to build Cura myself.