@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!
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
