aboutsummaryrefslogtreecommitdiff
path: root/cmake.deps/cmake/BuildUnibilium.cmake
Commit message (Collapse)AuthorAge
* fixup: quick update, squash laterdundargoc2023-11-20
|
* build: unset variables ending with "URL" if USE_EXISTING_SRC_DIR is ONdundargoc2023-03-04
| | | | | | | | | | This will reduce required boilerplate, but more importantly it will automatically unset variables ending on URL. This will help people needing to avoid to unset the URL variable each time a new dependency is added. It is possible that this may remove a non-download variable ending on "URL" in the future, however, the risk of this is likely much lower than the risk of someone forgetting to unset the variable.
* build: build all dependencies in parallel (#22329)dundargoc2023-02-19
| | | | | | | Previously, all targets were connected in one main target called third-party in order to remove any potentially conflicting shared library. We can make each dependency target independent of each other by only removing shared libraries from luajit and msgpack in their own targets, as only these has unwanted shared libraries.
* build: introduce default build variables (#21991)dundargoc2023-01-25
| | | | | | | | | | There are a number of cmake variables and cache variables that need to be passed to all dependencies. This is not only cumbersome, but also fragile as it's easy to miss adding or removing a flag from a dependency by accident. Introducing a global variable that controls all builds makes it much easier to handle our dependencies. Also fixes the currently broken release workflow as we need to pass the CMAKE_OSX_ARCHITECTURES variable to all dependencies built with cmake.
* build: use upstream CMakeLists.txt for unibilium (#21976)dundargoc2023-01-24
| | | Also remove UnibiliumCMakeLists.txt as it's not necessary anymore.
* build: use cmake for all platforms for unibilium and libtermkey (#21926)dundargoc2023-01-24
| | | | It's simpler to rely on the same build file, especially if there aren't any platform-specific workarounds like in this case.
* build(deps): restore support for USE_EXISTING_SRC_DIR (#20491)James McCoy2022-10-06
| | | | | | | | | | | | | | | 59d5f692f removed cmake.deps/cmake/DownloadAndExtractFile.cmake and support for USE_EXISTING_SRC_DIR. The Ubuntu nightly PPA still relies on USE_EXISTING_SRC_DIR functionality since it can't access the network during the build. Supplying an empty value for ExternalProject_Add()'s URL value appears to provide the needed mechanism to avoid re-downloading when the sources are already present. This is undocumented behavior, though, so it may break in the future. Now, if USE_EXISTING_SRC_DIR is set, the ExternalProject's URL variable is unset, preventing the download and erroring out if the source doesn't actually exist.
* build: define EP_PREFIX propertydundargoc2022-10-02
| | | | | This is just to avoid the boilerplate of definining PREFIX for each dependency.
* build: rely on builtin cmake downloading rather than custom scriptdundargoc2022-10-02
| | | | | | | DownloadAndExtractFile.cmake was initially introduced as a workaround to avoid the massive amounts of logs generated by the download progress. This is not a problem anymore as ExternalProject_Add has had the DOWNLOAD_NO_PROGRESS option since cmake version 3.1.
* build: remove code for cross-compilationdundargoc2022-10-02
| | | | | We don't support cross-compilation at the moment, so these can be safely removed.
* build: remove unnecessary build functionsdundargoc2022-09-08
| | | | | These functions serve no purpose if they're only used as intermediary functions that passes on arguments to ExternalProject_Add.
* build: consistently set build type regardless of generator or platform #19760dundargoc2022-09-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the default build type to always be Debug, and allow only four predefined build types: Debug, Release, RelWithDebInfo and MinRelSize. Furthermore, flags meant for single-configuration generator (make, ninja) will not be used for multi-configuration generators (visual studio, Xcode), and flags meant for multi-configuration generators will not be used for single-configuration generators. This will allow Debug builds to be built with MSVC which requires that all dependencies are also built with the Debug build type to avoid runtime library mismatch. The correct way to specify build type (for example Release) for single-configuration generators (Make and Ninja) is to run cmake -B build -D CMAKE_BUILD_TYPE=Release cmake --build build while for multi-configuration generators (Visual Studio, Xcode and Ninja Multi-Config) is to run cmake -B build cmake --build build --config Release Passing CMAKE_BUILD_TYPE for multi-config generators will now not only not be used, but also generate a warning for the user. Co-authored-by: dundargoc <gocundar@gmail.com>
* build: only use CMAKE_BUILD_TYPE for single-config generatorsdundargoc2022-08-13
| | | | | CMAKE_BUILD_TYPE is ignored for multi-config generators and creates a warning that it's unused.
* build: rename build-related dirsJustin M. Keyes2022-06-28
Problem: Dirs "config", "packaging", and "third-party" are all closely related but this is not obvious from the layout. This adds friction for new contributors. Solution: - rename config/ to cmake.config/ - rename test/config/ to test/cmakeconfig/ because it is used in Lua tests: require('test.cmakeconfig.paths'). - rename packaging/ to cmake.packaging/ - rename third-party/ to cmake.deps/ (parallel with .deps/)