[CMake] RE The Visual Studio project file inclusion problems.

[Marek Vojtko (Firaxis)]

On Mon, Jul 15, 2013 4:32 AM, Klaim - Joël Lamotte wrote:
> CMake 2.8.11 solves a lot of dependency tracking issues with normal CMake
> targets, which helps a lot!
> Unfortunately, the above issues I described months ago are still there.
>
> It wouldn't be a problem if I didn't need, for example, source versions of
> Protobuf and Intel TBB to work, which both don't provide (and don't seem to
> want to provide in the future) CMake configurations.
> When building these from source (because it's necessary in my project to
> build them from source), using Visual Studio, I'm forced to use
> include_external_msproject() which destroys all the benefits of dependency 
> tracking added to target_link_libraries() in 2.8.11.
>
> I got no response so far, so I don't know if fixing the issue is a work in
> progress, if it's not, if there is a fundamental issue, or if I'm doing it wrong.

You are overlooking one other solution - CMake-ifying the projects you depend on. Our project depends on several middlewares (TBB, Wwise, RapidXML, FreeType, etc.) and my experience has been that creating CMake files for them is far from the nightmare I imagined. Usually all that it takes is getting the file list from the .vcxproj, which is easily obtained since the .vcxproj files are human-readable XML files, and copying the preprocessor definitions. 

We CMake-ify all our dependencies because we want to enforce the same compile and link flags across the whole project (e.g. to disable exceptions) and because it simplifies dependency management - every project builds everything it needs and everything it needs is a CMake target. When a project doesn't provide a CMake configuration we simply create one and point it at the source code. Most middlewares are very easy, single-project solutions, so it worked well so far. TBB with its three projects and Wwise with its nine projects have been a bit more complicated, but the initial time-investment (never more than a day or two) has paid off a great deal by allowing developers to see all the source code in the same solution and by making any configuration (compile- or link-time) errors a thing of the past. 

Integrating new versions of the middlewares has also been far less painful than expected - you simply update the source code and then diff the solution and .vcxproj files from the previous and the current version to see if any files were added/removed and if any compile flags, compile definitions, or link flags have changed. Usually they haven't and your integration takes less than 30 minutes.

So rather than fight with include_external_msproject() and its lack of dependency handling I'd recommend just CMake-ifying your dependencies and then depend on them as normal CMake targets.

Hth,
--
Marek Vojtko
mail: marek.vojtko at firaxis.com