Introduce CMake based build system.

[nemerle]

This was tested on following configurations:

1. cmake generated sln files for Visual studio 2017 - 32bit
2. cmake generated sln files for Visual studio 2017 - 64bit fbx linking problem
3. using Linux+QtCreator 64bit
4. using Windows+QtCreator+Mingw530 fbx linking problem

Entries marked with "fbx linking problem" are usually a sign that fbxsdk libraries provided in third_party directory are incorrect ( 32bit vs 64bit or unsupported by mingw ) The list of changes:

• Use separate ENGINE_EXPORT macro for engine exports, instead of reusing NEXT_LIBRARY_EXPORT.
• Fix includes ( in some places they could've been moved from a header to associated cpp file, thus potentially reducing compile times )
• Replace some of A OUT etc. defines with static constexpr const char *'s, since they've clashed with some headers ( A/OUT are use in some places as template class names-> template<class A> )
• fix include guard duplication in converters/builder.h builder/builder.h
• change some ifdef guards from _MSC_VER to _WIN32 to halpe with MINGW builds.

NOTE The build system is currently missing INSTALL target. NOTE2 The data files are not copied to output directory during build, so trying to run ./WorldEditor results in

qrc:/QML/qml/Emitters.qml:28: ReferenceError: effectModel is not defined
 [ FileIO ] Can't open file .embedded/DefaultSprite.mtl No such file or directory
 [ FileIO ] Can't open file .embedded/plane.fbx No such file or directory
 [ FileIO ] Can't open file .embedded/plane.fbx No such file or directory
 [ FileIO ] Can't open file .embedded/DirectLight.mtl No such file or directory

Related to #149

[nemerle]

Note: all CI builds will fail, since this PR does not modify their config files.

[eprikazchikov]

Hi Artur, Impressive job! Let's review it!

• First of all, the CMake will be a parallel build system until it will do exactly the same as qbs do.
• As you mentioned Install target must be done before transfer CI to Cmake.
• CI was failed because you don't include engine_export.h to your commit. After this, it will not compile right because qbs files must be modified to use the new define ENGINE_EXPORT
• And my last general comment or probably a question. Is it possible to use wild cards for sources in CMake? I mean, it will be hard to maintain the huge lists of sources. Wildcards were one of the great reasons to move to QBS.

[nemerle]

Hi Artur, Impressive job! Let's review it!

• First of all, the CMake will be a parallel build system until it will do exactly the same as qbs do.
• As you mentioned Install target must be done before transfer CI to Cmake.

Shouldn't be too hard, CMake's install support is quite good and will cover most of the required functionality. The only thing that might cause a problem is preparing/copying Qt related content to install dir ( qt installation on windows has windeployqt.exe that solves part of the problem)

• CI was failed because you don't include engine_export.h to your commit. After this, it will not compile right because qbs files must be modified to use the new define ENGINE_EXPORT

Yup, engine_export.h & related defines are the results of a cmake's builtin helper script. I'll try to provide the generate file in a qbs only subdirectory to keep the cmake's approach of generate-and-include untouched.

• And my last general comment or probably a question. Is it possible to use wild cards for sources in CMake? I mean, it will be hard to maintain the huge lists of sources. Wildcards were one of the great reasons to move to QBS.

Yes it's possible to use collect source files using expressions, but there are some caveats in earlier versions of CMake.

[nemerle]

So, I've done some research about using wildcards.

1. It is not a recommended approach since the file list is built during cmake's configure phase, so when you add new files to the filesystem, they will only become part of the build process when you run cmake's configure/generate steps beforhand.
2. If You're ok with only supporting cmake versions >= 3.12 then there's also CONFIGURE_DEPENDS flag that can be used while collecting the files, that will check the file list on every build and if the list changes will automatically configure/generate new build files, but: We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. The CONFIGURE_DEPENDS flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck.

[eprikazchikov]

Ok, probably, we can think about another approach.

1. Exclude all configuration logic from submodules except platform specific sources and generate these lists automatically (i guess you did this).
2. Create separate lists with compilation flags, defines and installation procedures. (these files will be configured manually)
3. I have no preferences for CMake version at this moment. In case it will be more convenient for users to use CMake I'm ok with this. But I think it should be an option because some of the users will use only binaries. That means they, probably, will not have CMake binaries and Thunder must provide it as build tools. I think I will move QBS to the separate directory from main binaries directory to specific tools directory and move qbsbuilder tool to separate plugin. I'm suggesting to do the same for CMake. It will give flexibility. These tools will be downloaded separately (like asset store).

[eprikazchikov]

Seems like travis is ok but windows still failed. Will look at the logs when will be at home. And will need to check which engine modules are done. Probably qbs must be fixed.

[eprikazchikov]

Hi Arthur, Thank you for your contribution to ThunderEngine. Do you plan to work on the installation part?

[nemerle]

Hi Arthur, Thank you for your contribution to ThunderEngine. Do you plan to work on the installation part?

Yup, if time allows :)

[eprikazchikov]

CMake added in #635 PR