CMake and Build System Overhaul

[Ocraftyone]

Add the ability to build deps from main CMake file

During the configuration of the main project CMake file, you can specify BUILD_DEPS to have the deps built. After they are built, the current state of the deps folder is saved and building is skipped until the folder is updated or the option FORCE_DEPS is specified. CLEAN_DEPS is also available to remove the deps folder and recompile.

CMake presets

CMake presets include all of the options needed for each OS and build type. This allows the user to select a preset to use and get up and running quicker without having to manually set each option. This is most useful for IDEs that support presets (VS, VSCode with CMake Tools extension, CLion).

Other Changes

• Update the main CMake build file to be more readable (Add compiler flags and LINUX flag plus general organization and pruning)

• Automatic generation of CMAKE_PREFIX_PATH (and CMAKE_INSTALL_RPATH on macOS)

• Change Linux DESTDIR and CMAKE_PREFIX_PATH to OrcaSlicer_dep to follow other platforms

• Automatic BBL_RELEASE_TO_PUBLIC (On when build type is Release, Off on others)

• Stop using BBL_INTERNAL_TESTING in BuildLinux.sh. Most of its functionality is disabled anyway.

• Default to GTK3 on linux

• Fix deps debug build on linux so they only need to be compiled once

• Hide compiler commands during OpenSSL, MPFR and GMP builds

• Re-enable patch test for wxWidgets

• Suppress CMake depreciation warnings

• Update devcontainer.json

• [x] Update linux build script

• [ ] Update Windows build script

• [ ] Update macOS build scrip

[Ocraftyone]

@SoftFever This is just waiting on your approval/denial of the new script format. LMK if you are ok with me going forward with modifying the other platform build scripts.

[Ocraftyone]

@SoftFever the changes to the Linux build script still need your opinion to continue on this

[SoftFever]

Hi @Ocraftyone Thank you so much for you effort. Some thoughts:

1. Add the ability to build deps from main CMake file.

   Frankly, I don't know. Given that the current build process works well and I don't see significant improvements in convenience, I'm inclined not to include these changes as they might introduce issues. Considering we support multiple platforms, it's a huge headache. I prefer to avoid spending more time on testing and troubleshooting the build system itself in the future.

2. CMake presets This is very convenient. I'm all for it!

[Ocraftyone]

1. Frankly, I don't know. Given that the current build process works well and I don't see significant improvements in convenience, I'm inclined to avoid spending more time on potential testing and troubleshooting that these changes might introduce.

There are three main things that I feel are improved by using this system.

1. The ability to avoid the command line when using an IDE.
2. Only one script to update when a change is made
3. It is easier to know when to rebuild deps since it is tracked by the script

This autobuild system is based on what prusaslicer currently uses (reference). I have based my deps/autobuild.cmake on our current build scripts. It just moves building the needed cmake command from all of the separate scripts to a single file.

If you don't feel comfortable using CMake as the primary deps build method yet, it can at least be an option with the possibility of later making it the default.

[SoftFever]

1. Frankly, I don't know. Given that the current build process works well and I don't see significant improvements in convenience, I'm inclined to avoid spending more time on potential testing and troubleshooting that these changes might introduce.

There are three main things that I feel are improved by using this system.

1. The ability to avoid the command line when using an IDE.
2. Only one script to update when a change is made
3. It is easier to know when to rebuild deps since it is tracked by the script

This autobuild system is based on what prusaslicer currently uses (reference). I have based my deps/autobuild.cmake on our current build scripts. It just moves building the needed cmake command from all of the separate scripts to a single file.

If you don't feel comfortable using CMake as the primary deps build method yet, it can at least be an option with the possibility of later making it the default.

I'm not a fan of their build system. But I don't object your idea either.

Currently the CI/CD for deps is broken because of the recent CMake upgrade. Once that is fixed, we can re-test this PR.

[Ocraftyone]

@SoftFever I believe both of the changes mentioned were to get debug builds working properly on Linux. Debug in the current system first builds the release deps, then builds the debug deps on top of them. These changes allow the release build to be skipped. Here is the relevant line in the build script

[SoftFever]

@SoftFever I believe both of the changes mentioned were to get debug builds working properly on Linux. Debug in the current system first builds the release deps, then builds the debug deps on top of them. These changes allow the release build to be skipped. Here is the relevant line in the build script

Sounds good. However, the changes in FindNLopt.cmake still need to be addressed. If I understand correctly, it will link both release and debug libraries for a Release build if a debug build is present on the same machine. Let me know if I've missed something here.

[Ocraftyone]

@SoftFever I believe both of the changes mentioned were to get debug builds working properly on Linux. Debug in the current system first builds the release deps, then builds the debug deps on top of them. These changes allow the release build to be skipped. Here is the relevant line in the build script

Sounds good. However, the changes in FindNLopt.cmake still need to be addressed. If I understand correctly, it will link both release and debug libraries for a Release build if a debug build is present on the same machine. Let me know if I've missed something here.

Sorry it took so long to get around to taking a look at this. The NLopt changes should not cause any issues. That is just telling cmake that nloptd is a valid library name. I would assume if a release version of NLopt is available, it would use that first since it is listed first, but I am not sure about that. Since nloptd is built during debug builds instead of nlopt, without this change cmake does not find the library

[Ocraftyone]

Major updates since last time:

• Hide the installing text for deps
• Improve Win10SDK path generation
• Revert changes to the linux buildscript pertaining to using CMake Presets
• Add new options to linux buildscript: packing deps, building in RelWithDebInfo
• Merge the windows buildscripts (Both files are still there, but the 2019 version just calls the 2022 with an extra flag and passes the rest of the parameters through)
• Update how the arguments are processed in the windows buildscript
• Add "killbuild" option to windows buildscript
• Update how cmake commands are echoed then called in the windows buildscript
• Update the macOS buildscript: check the provided build config type, use different build dirs based on build type, use relative paths, fix single thread build flag, update the if statements
• Remove now unneeded cmake arguments across all build scripts

[Ocraftyone]

@SoftFever I think its ready 😄