<html>
<head>
<meta name="generator" content="Windows Mail 17.5.9600.20911">
<style data-externalstyle="true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst,
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle,
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir="ltr">
<div data-externalstyle="false" dir="ltr" style="font-family: 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif';font-size:12pt;"><div>Dear CMake devs/users,</div><div><br></div><div>I wanted to ask your opinion on something that has been troubling me since… well, ever since I started using CMake. I have not found a single person alive who would have said:</div><div><br></div><div>“The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.”</div><div><br></div><div>There are gazillions of scripting languages one could have chosen for CMake (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to reuse existing skills, or learn one that is useful elsewhere, not just in terms of CMake. These languages have a lot of thought put into them. They are superior to CMake’s own in just about every regard.</div><div><br></div><div>I came up with an idea presented here: <a href="http://1drv.ms/1MsufbF" target="_parent"><u><font color="#0066cc">http://1drv.ms/1MsufbF</font></u></a><br></div><div data-signatureblock="true"><br></div><div data-signatureblock="true">Enhancements such a change could bring about:</div><ul style="padding-top: 0px; padding-bottom: 0px; margin-top: 0px; margin-bottom: 0px; list-style-type: disc;"><li style='color: rgb(0, 0, 0); font-family: "Color Emoji", "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 16px;'><div data-signatureblock="true">The big selling point would be the ability to introduce arbitrary front-ends to CMake, not just CMakelists.txt. Every developer could choose an input language that suits their project/needs/skills.</div></li><li style='color: rgb(0, 0, 0); font-family: "Color Emoji", "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 16px;'><div data-signatureblock="true">(It would also ease the custom implementations of cmake.exe itself in any language, but that is just a side-effect.)</div></li><li style='color: rgb(0, 0, 0); font-family: "Color Emoji", "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 16px;'><div data-signatureblock="true">It would modularize the internals of CMake in a cleaner fashion</div></li><li style='color: rgb(0, 0, 0); font-family: "Color Emoji", "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 16px;'><div data-signatureblock="true">Facilitate the introduction of new languages understood by CMake (such as work put into C# and Swift currently)</div></li><li style='color: rgb(0, 0, 0); font-family: "Color Emoji", "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 16px;'><div data-signatureblock="true">Would allow for configure-time validating of compiler-specific options</div></li><li style='color: rgb(0, 0, 0); font-family: "Color Emoji", "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 16px;'><div data-signatureblock="true">Use deferred makefile generation by default (making the implementation of tools like <a href="https://github.com/sakra/cotire/" target="_parent">Cotire</a> for precompiled headers trivial to implement, as well NMake batch mode, or detecting multiple/cyclic linkage, by making use of global information about the build process)</div></li><li style='color: rgb(0, 0, 0); font-family: "Color Emoji", "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 16px;'><div data-signatureblock="true">Many features could automatically be reused by all generators. (Imagine Swift, and Fortran libraries being compiled as NuGet packages and publishing them without any hassle on user side, or having to implement anything in the XCode generator.)</div></li><li style='color: rgb(0, 0, 0); font-family: "Color Emoji", "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 16px;'><div data-signatureblock="true">SIGNIFICANTLY increase interoperability with other tools. Implementing GUI front-ends (such as in CLion, or Visual Studio (work in progress)) are orders of magnitude simpler by generating a stateless IR, as opposed to generating a stateful script.</div></li></ul><div data-signatureblock="true"><br></div><div data-signatureblock="true">While it is a refactor of the entire toolchain, it is something that could be done incrementally, with the existing parts functioning normally.</div><div data-signatureblock="true"><br></div><div data-signatureblock="true">I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake users I’ve met say they are “happy” CMake users. The learning curve is steep, and the skills gained are not reusable. CMake could gain even greater momentum (not by ditching, but) by offering alternate input languages with entities (classes, functions, macros, etc.) that feel natural in the given context.</div><div data-signatureblock="true"><br></div><div data-signatureblock="true">Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in something similar, starting with CMake 4.0 perhaps.</div><div data-signatureblock="true"><br></div><div data-signatureblock="true">Eagerly await the rolling ball.</div><div data-signatureblock="true"><br></div><div data-signatureblock="true">With all due respect,</div><div data-signatureblock="true">Máté<br></div></div>
</body>
</html>