Added support for Conan as a dependency manager

[jellespijker]

This PR is part of the following PRs:

• libSavitar -> Added support for Conan as a dependency manager libSavitar#36
• libCharon -> Added support for Conan as a dependency manager libCharon#33
• libnest2d -> Added support for Conan as a dependency manager libnest2d#2
• pynest2d -> Added support for Conan as a dependency manager pynest2d#11
• Uranium -> Added support for Conan as a dependency manager Uranium#720
• CuraEngine -> Added support for Conan as a dependency manager CuraEngine#1479
• Cura -> Added support for Conan as a dependency manager Cura#10535

The purpose of these changes is to set up a dependency manager for Cura and here repositories. Cura uses both third-party and Ultimaker maintained dependencies, written in both Python and C++ (or mixtures of both). Not all of these dependencies can be downloaded with the help of a dependency manager such as pip. This makes setting up Cura from source, a pain in the $%^#$$%^. See the graph below for the current dependencies. Adding to the complexity is the way how we're currently consuming third-party dependencies; Some have to be present on the system/provided by the user, some are shipped within the repo, while others are downloaded by CMake.

All of the above-mentioned PRs and this one, add a conanfile.py to the root of this project. This is a recipe written in Python which instructs Conan (https://docs.conan.io/en/latest/) how to build and package the repository in such a way that it can be reused by other dependencies. If a required dependency has no binary for your OS and compiler it will build that dependency from scratch and store it in the cache. Making installing Cura from source as simple as:

conan install Cura/4.10.0@ultimaker/testing --build=missing

For a more detailed description see the README.md in this repository https://github.com/jellespijker/conan-um

For testing purposes, I have set up a small home server that can be used by Ultimaker employees. Other developers can test this by cloning the above-mentioned repositories and performing a conan export . ultimaker/testing in each root. That only leaves the SIP package, if you execute a conan export . riverbankingcomputing/testing in this folder https://github.com/jellespijker/conan-um/tree/main/recipes/sip it creates a Conan package for SIP 4.19.25

You can use your own profiles for this, but I have personally tested and developed them with my own jinja template profiles on Linux Manjaro with a GCC compiler, Mac OS Big Sur with a Clang compiler and Windows 11 with a Visual Studio 2019 compiler.
These profiles can be installed with the conan config install https://github.com/jellespijker/conan-config. Make sure you add -pr:b cura_release.jinja -pr:h cura_release.jinja to your install instructions

Conan allows for multiple ways of working. Either the exiting package can be used from the cache, or if you want to work on multiple repositories you can put that repo in editable mode such that the xxx-config.cmake in the project that is depending on the other, will point to the paths of your repo, see https://docs.conan.io/en/latest/developing_packages/editable_packages.html

Because the best practice method to use Conan, which is also the preferred way in Conan 2.0, is to use ( https://docs.conan.io/en/latest/reference/conanfile/tools/cmake.html ) With the tools CMakeDeps, CMakeToolchain, and CMake. The CMakeDeps class will generate xxx-config.cmake files per dependency, while the CMakeToolchain will generate a toolchain to be passed to CMake -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake These two prepare the way for CMake to actually build the project such that it won't need to change the CMakeLists.txt. Allowing Conan to be optional and not mandatory. Unfortunately, our repositories have organically grown CMakeLists.txt mixing old and modern syntax and a build system that uses CMake 3.13.

This PR should also (partial) fix a lot of SIP issues which I'm seeing in this repository.

I currently fail to create DLL libraries on windows, although the export-header is generated correctly and included. It still throws a lot of: unresolved external symbol __declspec(dllimport) as a workaround I now build it statically on that platform. Maybe @konskarm or @rburema can take a closer look. To be honest I don't think we actually need to export the DLL on Windows but I'm far from a Windows exp(o/e)rt ;-)

add_sip_python_module(Savitar python/ThreeMFParser.sip Savitar)

set_project_standards(python_module_Savitar)
set_project_warnings(python_module_Savitar)
use_python(python_module_Savitar Interpreter Development)

target_link_libraries(python_module_Savitar PRIVATE SIP::SIP Savitar)

I decided to harmonize our CMakeLists.txt because often they were inconsistent, for instance how we set the fPIC or MD/MDd and MT/MTd flags. Often I had to changes these methods in one repo, while it already worked in another repo. Getting stuff to work on three different OSs in three different languages is a bit time-consuming, to say the least. These uniform methods of preparing CMake instructions can be found in cmake/StandardProjectSettings.cmake. These are tried and tested methods that we already use in our Spatial plugin and are used by Json Turner in this https://github.com/lefticus/cpp_starter_project and are based on the best practices described here: https://github.com/lefticus/cppbestpractices

The changes in CMake basically boil down to:

• StandardProjectsSettings.cmake
  • Set all compiler warnings known to mankind.
  • Prefer BUILD_SHARED_LIBS over BUILD_STATIC but no change in the interface so no change is needed on
    the build servers.
  • Set build_type to Release if not specified
  • Export compile commands to a json for easier debugging
  • Use position-independent code if applicable (-fPIC)
  • Switch between MT/MTd of MD/MDd for Visual Studio using text generators
  • Set C++17 standard
  • Set stdlib=libc++ for clang-apple
  • Add option ENABLE_BUILD_WITH_TIME_TRACE for generating time tracing json on Clang compilers
  • Created a uniform method of using threading which prefers pthread if the platform supports it and has multiple
    threading libraries installed.
  • ENABLE_CPPCHECK "Enable static analysis with cppcheck" default OFF
  • ENABLE_CLANG_TIDY "Enable static analysis with clang-tidy" default OFF
  • ENABLE_INCLUDE_WHAT_YOU_USE "Enable static analysis with include-what-you-use" default OFF
  • ENABLE_COVERAGE "Enable coverage reporting for gcc/clang" default OFF
  • ENABLE_SANITIZER_ADDRESS "Enable address sanitizer" default OFF
  • ENABLE_SANITIZER_LEAK "Enable leak sanitizer" default OFF
  • ENABLE_SANITIZER_UNDEFINED_BEHAVIOR "Enable undefined behavior sanitizer" default OFF
  • ENABLE_SANITIZER_THREAD "Enable thread sanitizer" default OFF
  • ENABLE_SANITIZER_MEMORY "Enable memory sanitizer" default OFF
  • Disallow in-source builds by default but added the option ALLOW_IN_SOURCE_BUILD, some build systems such as
    Conan copies the source and builds from there.
  • Enable IPO/LTO https://en.wikipedia.org/wiki/Interprocedural_optimization
  • Use a modern way of finding Python if you want to link to a specific version pass -DPython_version=3.9 now it will link to 3.8
    by default.
• Use targets in CMake consistently
• Added targets to the shipped Find-modules CMake
• Moved shipped Clipper and RapidJSON a directory up so they include behave the same as when they are imported from
  the system.
• Created a static library from the shipped Clipper which links to _CuraEngine and the relevant tests.
• updated .gitignore with cmake-build-* and tmp
• Added clang-tidy and clang-format (which can be used by CMake or most IDE's. Same ones that are used for the
  SpatialBackend these are probably still a bit incomplete at the moment. But if we update them after each comment
  during a review, it will get more and more helpful.
• Moved CMake testing logic to it's own folder

The above-mentioned CMake changes should keep the build interface the same for existing environments (only add extra options) Now you guys might get a bit discouraged when you see all of those warnings scroll up when building CuraEngine. We can opt to disable it. But I personally am strongly in favor of keeping these visible as a motivation to clean up our codebase each time we're working in a certain section.

Still, WIP at the moment, since I'm finalizing some last changes across all repos.