On 2018 M07 21, Sat 18:24:23 CEST Giuseppe D'Angelo via Development wrote: > Il 21/07/2018 17:42, Jean-Michaël Celerier ha scritto: > > Besides... why would it matter that they are implemented in C++ instead > > of cmake-lang ? If anything, CMake's automoc is in my experience much > > faster to process the whole repo. > > Playing devil's advocate, please bear with me: > > > Because it makes people worry that cmake-lang is too limited, and if you > need to do certain things (*), you need to resort to patch the tool itself. > > Which opens other sets of problems, such as: > > * what are the things that I can do in cmake-lang and the things I can't > do?
you can do almost everything in cmake-lang ;-) By now, in 2018, most build-related challenges should have been taken care of in CMake. I think the biggest issues are: - IDE integration: cmake server mode is still relatively new and and I don't know exactly how powerful it currently is - better documentation/tutorial especially for old vs. new-style cmake - new technology that appaers with new operating system features etc. often needs a new cmake release > * Does all of this imply having changes landing in CMake itself, or can > one have some sort of plugin system so that a project can ship the CMake > C++ plugins to build it? there is intentionally no plugin system/public API in CMake, to keep changing the internals of cmake itself easy. But really a lot can be done via cmake scripts. > * If the former, what happens if my users are running a "slightly older" > CMake that doesn't have my patches in it yet? The older cmake will error out saying that the project requires a newer version of CMake. Alex _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
