[CMake] CMake IR

Thu Jul 30 07:51:54 EDT 2015

@Domagoj:

“In addition to it feeling like working with (or fighting against) an ugly 
crossover between a C preprocessor and a shell script from 1979, an increasingly 
big source of frustration is its rigidness and limitation of 'only one 
toolset/compiler per project'.”

😃 I couldn’t have put it any better myself.

Indeed, I recently had the idea of writing a Windows Store XAML application to give a GUI frontend to TagLib, just as an excercise and give it a jump start in August on my vacation when I want to do something productive. I started collecting the dependencies and everything, and came across… CMake has Windows Store support, but how on Earth am I going to build x86/x64/ARM targets from one VS solution? I was reading the docs a while and said to mysef “ah, f*ck it, no CMake has nothing to do here.” It is very annoying that CMake has these limitation at it’s very core that would take months and months to rule out. I can imagine Android being even more painful in this regard. CMake really could do a whole lot better in this.

@Nicolas:

Yes, these tools indeed have been working for the past few decades. Others also suggested why don’t I generate CMakelists.txt instead?

The problem is that the current limitations of CMake all originate from the way the workflow is organized. Multi-configuration makefiles are trivial to implement if you do them by hand. All targets append the architecture after their name (app-x86, app-x64, lib-x86, etc.) and there were all-x86 and all-x64 targets, and there were the usual “all” target that references all-x86, all-x64. In CMake the workflow is baked into selecting an architecture at the earliest points in the configuration process and stores it as a global variable (state!) which then shoots all multi-configuration generators in the knee.

Yes, it is possible to remove this limitation from CMake, but it would take roughly a year. Holding onto this limitation alone just because it is historically the way how CMake has been designed immediately rules it out from ~75% of application development going on in the world in the future (mobile app devel), which is funny because building cross-platform mobile apps is the future, and this is just the market that could benefit of CMake the most.

@Bill:

I am a member, I just tried sending using the same mail using the “secret CC” option. It seems it did not work.

@David:

Maybe some convincing and positive feedback can do the trick. I mostly live my life on Windows, so most technologies and tools relate to Windows, but all the HPC clusters I use are linux, hence the need for CMake. My initial research builded down to this:

Learn from the ‘competition’

Identify the portable properties of building a C++ application (mostly from CMake) and define an XML Schema.

Create the Schema of a chosen compiler

Implementing everything in C++

Initially do not bother with a front-end. Using the Schema, Visual Studio can provide Intellisense based on the .xsd file. This is sufficient for dev pourposes.

Using this open-source lib, getting a parser/deserializer and datastructure for use in C++ is as easy as 1-2-3.

Use the aforementioned lib to get a datastructure and serializer using the MSBuild Schema.

Almost done. Just wrap the Schemas of the IR into neat C++ classes. Tadaaa: C++ front-end.

Wrap the C++ classes with C++/CX for use with Powershell. Tadaaa: Powershell front-end.

Implement everything in PS (just for kicks)

PS alread understands the [xml] type and can read/write and process it. Validation can be used from PSCX.

Transform the data read into MSBuild’s own. (Somewhat blindly, because there are no neat classes available in the MSBuild Schema format)

Amost done. Write PS5 classes around the Schema entities. Tadaaa: PS front-end.

Future work:

Make it better

Implement other generators after the all too convenient, XML based MSBuild.

Add Unit Test Schemas

Add packaging Schemas (Nuget is again XML based with XSD Schema, trivial to implement)

Enhance package support to be able to fetch dependencies from git and build (a la Cargo), have installation method similar to CMake packages, etc.

If the entire build’s information is available as an iterable C++ tree-like datastructure, how hard can it be to implement generators like Ninja? (Not trivial, but not hard either.) If there is a clear Schema of valid options for a specific feature, so many things simplify. Again, imagine automatic fetching of dependencies from multiple repositories even. Nuget, GitHub, .deb, you name it!

And I haven’t even mentioned things like remote builds and what not… all new features could be introduced as a seperate Schema with it’s respective options, and if the user references the schema in the IR, and the generator supports it, it is done. Imagine distributed builds similar to Incredibuild, but with CMake. Nothing is needed, but the user define a pool of machines, and execution falls back to the core custom_command feature and call ssh and scp (or anything else) from the CLI and get the job done. SOOO many things could be trivially done, and GNUMake, Ninja, XCode, and all generators gain the ability for free!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150730/25736cf6/attachment.html>