Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upIntroduce CMake (and removing all other project-related code) #7270
Conversation
|
If CMake becomes the only (meta) build system, wouldn't it make sense to scrap the source.list file as well, and define that data via CMake syntax instead? |
|
For MinGW directmusic and xaudio2 needs to be detected. MinGW has directmusic headers, but doesn't have xaudio2. |
Just to clarify, if you manually copy over an xaudio2 header file then mingw should be happy with it - I did test that when I wrote it. |
|
I kept the manifest in projects, but it should probably move somewhere else |
|
For now we rely on cmake default CMAKE_CONFIGURATION_TYPES and CMAKE_XXXXX_FLAGS_<CONFIG>, but it should be better to manage that by ourselves |
I disagree. The closer we stay to CMake, the easier our life will be. Let's try to do this, and only add exceptions if we really need to (and mark them as such). Otherwise we will have a config.lib in no time :D |
|
Indeed something is wrong in the generated project file for lzo and lzma AdditionalDependencies for Debug: |
|
hmm that's weird, OSX cmake step now pass, lzo is found, compilation fails because it doesn't find an lzo header |
|
Ok there's an issue with lzo detection, I can compile with MinGW by luck, as the detected
is covered by H:/msys64/mingw64/include from other libs.
is alone |
TrueBrain
force-pushed the
TrueBrain:cmake
branch
2 times, most recently
from
6164e63
to
a25c911
|
Stupid me failing in the commit message. BTW I think test task for MacOS should probably be "make -C build test". |
TrueBrain
force-pushed the
TrueBrain:cmake
branch
3 times, most recently
from
e5b7c05
to
d71ac0a
|
regression works with MinGW without converting the exe, but it fails with many I guess the lovely regex was needed :) |
|
Yeah, but I refused to do that unreadable regex; so now I am just adding them one case at the time :D |
TrueBrain
force-pushed the
TrueBrain:cmake
branch
5 times, most recently
from
823f76d
to
027a5b3
glx22
force-pushed the
TrueBrain:cmake
branch
2 times, most recently
from
123c004
to
4f2c6c4
|
Conflicts still need to be resolved ( |
|
The Temp commit is here for a reason, and the conflict will go with the next rebase. |
|
Hi, please check out TrueBrain#11 before you merge this PR. |
|
@fsimonis I implemented your PR when you first mentioned it :) |
|
I'm going to be radical and say we should get this merged :) Iron out the final kinks after we see it in production. Make sure we don't get any more PRs wanting to change things about the build system whose work would just have to be duplicated. Well, of course there's a bunch of formal errors from the commit checker that need to be fixed, and some "conflicts". |
This prepares for the switch to CMake, which takes over all current exisiting forms of project files.
… script The tst_stationlist savegame had to be changed to start the correct AI. In the old setup, all regression AIs had the same name, which made it impossible to run both regressions in parallel. With the new setup this is possible. Although all files are available to run the regression, it won't really work till CMake is introduced (which will happen in a few commits from here)
For grfs, it now uses CMake scripts to do its job, and both grf files are split into their own folder to make more clear what is going on. Additionally, it no longer builds in-source (although the resulting grf is copied back in the source folder). For ob[msg] it now uses CMake scripts to generate the translation files; the result is no longer stored in-source (but in the build folder). Although all files are available to create the GRFs and basesets, it won't really work till CMake is introduced (which will happen in a few commits from here)
CMake works on all our supported platforms, like MSVC, Mingw, GCC, Clang, and many more. It allows for a single way of doing things, so no longer we need shell scripts and vbs scripts to work on all our supported platforms. Additionally, CMake allows to generate project files for like MSVC, KDevelop, etc. This heavily reduces the lines of code we need to support multiple platforms from a project perspective. Addtiionally, this heavily improves our detection of libraries, etc.
CPack works closely together with CMake to do the right thing in terms of bundling (called 'package'). This generates all the packaging we need, and some more.
This also means dropping Debian/jessie, as it has a CMake that is too old (3.0), with no real path to upgrade.
With CMake, these files are simply not compiled to start with.
|
Fixed conflicts, removed temp commit, and squashed |
|
Let's do this! |
|
Screw it. |
TrueBrain commentedFeb 23, 2019
•
edited
Fixes #6884
Fixes #7470
Stable release build
Nightly release build
This removes:
It replaces them all with a single method: cmake. This should also remove any awk/vbs scripts we have around, meaning we will get a single method of doing stuff.
Currently tested with these 'IDEs':
This is pretty much a Work In Progress, but I wanted to show others how it would look etc, so they can also test already a bit. Any feedback is welcome.
To test it out:
Or open the CMakeLists.txt in VS2017 / VS2019.
Things still to do:
autodetect TiMiditity(libtimidity is no longer available on most OSes)Currently it is calling
findversion.sh, which only works on non-Windows. Porting it to CMake makes more sense (one single way of doing stuff).add static builds(no static builds for now; we might reconsider later)(I am sure I am missing stuff .. but this is something to work on at least :D)