CMake Buildsystem Basics

[tdev]

Basics for the CMake buildsystem. Building completely, not interfering with default buildsystem.

[dottools]

Please don't pollute the engine sources with compiler specific files. That's why Templates/<template>/buildFiles/<buildSpecifcDir> exist in the first place.

[DavidWyand]

I agree with @dottools that these changes belong under the Templates. Making build files part of the engine means that if I don't want to include a subsystem (such as Xaudio) then I'm changing the engine across all of my projects to do so.

[crabmusket]

To clarify, CMake files are not build files like VS solutions, nor are they project- or compiler-specific. They replace the project generator .inc and .conf files. However, I'm not familiar enough with CMake in large projects to know what the process of including/excluding modules per-project would be.

EDIT: The other consideration is, can a CMake configuration be stored in some version-control-friendly format for a specific script project? Similar to how we currently have a projectCode.conf in the project directory. I'm trying to find the answer to that now.

[DavidWyand]

Also, don't forget that making manual changes to any of the directories under Engine/lib means that you've now made a custom version of that library that you need to keep track of if you ever want to update that library. We currently have that issue with the Collada library, which is why it hasn't been updated to the latest available (someone needs to determine how to carry over the changes or find another way to work around them).

It would be best to not modify the library files themselves (such as lpng) and put T3D specific build instructions into the Templates.

[crabmusket]

I agree with @DavidWyand that we should keep our own code out of the library directories. EDIT: And if possible, I would even recommend removing the code from lib/x where possible, and replacing it with a submodule pointing to an external git repo. Though that has its own disadvantages.

[DavidWyand]

@eightyeight I agree that CMake files are not equivalent to VS solutions and that they work like the Project Generator. In both cases they produce the compiler specific files based on your project's settings. So just as the Project Generator is outside of the Engine source, shouldn't CMake be? Otherwise, any changes I make to modify the produced compiler specific files (such as which libraries to include or defines to add) will occur across all projects.

[crabmusket]

Right, but any changes you make to the project generator occur across all projects, too. Same situation. But I do agree that these files should probably live in Tools/cmake or something like that. EDIT: Of course, there needs to be some way to make project-specific changes, like projectCode.conf does. But I suspect all that means is having a CMake file in buildFiles as well, which we have no example of so far.

Also @tdev can we have a new branch for this if we're going to go in the cmake direction? There's really no point PRing partial code to development - just put it in a working branch and PR it when it's finished.

EDIT: @DavidWyand I'm glad to see you here and voicing your opinion! Also sorry for all these edits. I like them better than double-posting :P.

[DavidWyand]

@eightyeight Hmm, you're correct in that if you change the core Project Generator files that it would occur across multiple projects. I was thinking of the project specific files, which as you pointed out, are not here. I guess it was the idea of having any build specific information along side the source that threw me off, but perhaps that is just how you do it for CMake.

Then I would just caution about making changes to the /libs directories, and also suggest that the additions to Engine/source/main in this Pull Request are project specific and don't belong here.

[crabmusket]

@DavidWyand CMake convention seems to be that CMakeLists.txt files live alongside the source code, but I'm not sure if I like that convention. I'm also not sure if it's just a convention or if there are technical reasons for it. More research is required.

Okay, I do agree that the changes in main are suspicious.

[tdev]

sorry for the lack of communication, was busy getting this working :)

The idea is to use CMake to generate a buildsystem into some other folder. It currently looks like this:

Pressing configure, selecting VS2012 and then 'generate' will create a folder for you that looks like this:

And the solution inside VS:

Notice the source folder vs the build folder. I added some options to it already which will change some things in it.

CMake supports quite some generators to work with: http://www.cmake.org/cmake/help/v2.8.12/cmake.html#section_Generators

About the main/*.rc: it is the resource which is used for the executable icon. It should move somewhere else i guess.

[LuisAntonRebollo]

@tdev , It looks pretty good :D

I only have experience as a user of CMake so I can not help much.

All the projects I've seen have the CMakeList.txt along with the source. But I understand that you may not like.

If possible, maybe it is not, what you think this directory tree:

• T3D/engine/CMake/ <- all CMakeList.txt files
• T3D/Templates/ * /buildFiles/CMake/CMakeList.txt <- used as root.

Template root CMakeList:

• Generate project files in ../GeneratorName <- VisualStudio 2010, XCode...
• Set dirs for build files.
• Move exec to ../../game/

[estama]

I also think using CMake is a good idea. Using standard tools reduces the maintenance cost (by not having to also care about the tool), and increases the amount of people having pre-existing experience with the tool.

[DavidWyand]

@tdev Some questions from someone that isn't familiar with CMake:

1. main/Torque.rc and main/torque.ico are Windows specific. Do you plan on moving these into a platform specific directory, or are all support files like this for all platforms going to be dumped into main?
2. Are main/Torque.rc, main/torque.ico and main/torqueConfig.h being copied at some point into the project's directory so they may be modified for that project?
3. In your example, where does a project's source directory live, or have you just not gotten that far yet?

[tdev]

main/Torque.rc and main/torque.ico are Windows specific. Do you plan on moving these into a platform specific directory, or are all support files like this for all platforms going to be dumped into main

yes, sure. They should go somewhere else. I could extract them from the current buildscripts structure but one folder for every OS would be easier.

Are main/Torque.rc, main/torque.ico and main/torqueConfig.h being copied at some point into the project's directory so they may be modified for that project?
In your example, where does a project's source directory live, or have you just not gotten that far yet?

yes, i haven't account for this yet. We should have a source folder that contains the additional files (like the .rc ones) and the additional source code that should be used :)

If i find time later on, i will try to add this.

[tdev]

I will create a new PR that is cleaner without the unneeded changes later on.

[tdev]

second version: #590