It's already bad enough that the developer needs to understand both target-based CMake and legacy CMake, now there need to be two more languages (slide 13) that must be understood? It's been 9 years since Modern CMake came out, and I'd estimate adoption at 50-50.
This deck does not address the drawbacks of doing this at all, and the only recognition of this problem is in "Stretch Goal: Research development of tool(s) to translate legacy CMake to new CMake language."
The current CMake language is fine. Nothing amazing, but good enough.
But every moment that I spend configuring CMake is a moment I don't spend doing something actually useful. I don't want to disparage the team's work--CMake is awesome software--but the way they see it is very different from the way typical developers see it.
> The current CMake language is fine. Nothing amazing, but good enough.
Lol CMake was a huge reason I got out of C++ development almost a decade ago. I was tired of scripting my own shitty build systems, especially ones which couldn't even manage packages. I never actually need the power CMake offers, but the stuff I do need (reproducible package management) CMake punted on. 99.9% of the time, all you need is a build tool that takes a list of dependencies and a lockfile (or similar).
> 99.9% of the time, all you need is a build tool that takes a list of dependencies and a lockfile (or similar).
I'm very happy for you but almost all the C++ projects I've worked on have needed muuuuuuch more complex build system scripting than this.
The question you should be asking yourself is "why? why does my C++ project need 18 programming languages to build and java needs an xml file, javascript some json, or rust a toml file".
how many times did you have to build a java or javascript project where you are counting kilobytes, or are pre-generating data tables for maximum efficiency which you want to be configurable as a build option because you're going to need different tables for different hardware/target ? people with this sort of problem just aren't even considering using java or javascript so of course in C++ we end up with a hairier solution. A lot could be solved if there was good compile-time reflection for sure but still.
An example: the main software I work on, along with a few other software I know, has to generate a SDK as part of its build so that people can build plug-ins for it. How often do you have to do this in java or JS ? almost never. But this requirement implies having a build system powerful enough to do that.
Another example: another software I work on must produce a Max/MSP package ; this implies:
- working with multiple versions of the Max SDK which changed their structure on disk
- setting different build options such as file naming depending on the target architecture: .dll on win32, .dll64 on win64
- generating a relatively complex tree structure which combines a Windows and a macOS build together because people don't want the hassle of having two different download options
- generating some stub C file that will declare a function to be exported
- generating some .json file with various build information, build date, etc
- generating a symbols.txt file which contains all the symbols that are known to be explicitly exported to minimize binary size ; the build system has to: list the symbols (one per plug-in we build), write them to a symbols.txt file, pass that file to Apple's dyld like this:
set_property(TARGET ossia-max APPEND PROPERTY
LINK_FLAGS
"-s -exported_symbols_list '${CMAKE_CURRENT_BINARY_DIR}/symbols.txt'"
)
these are the requirements we have. can you solve these requirements with just Java's XML ?
> these are the requirements we have. can you solve these requirements with just Java's XML
Yes, actually. They don’t come up very often, but maven in particular has the ability to do everything you’ve mentioned. Most of them built right into the standard plugin set, like setting various compiler options, adding build information, or even platform specific build shenanigans (usually when dealing with javafx).
Maven also has a rarely used escape hatch plugin (ant run) which allows you to run custom scripts if you really need to.
can you show an example of how you'd parse, say, a .java.in file from Maven (say match some lines with regexes), and generate a .java file from it, that you'd add as part of the build? And could you really say that this would be cleaner than the same thing done with cmake?
The canonical way to do such a thing is through the java annotation processing api [1] and using a tool like java poet [2]. Before you did that, you'd probably decide if you wanted to instead use bytecode generation with a library like bytebuddy [3]
But, assuming for some reason, you wanted to torture yourself and actually consume a java.in file and apply a regex, then you'd probably pull out the "maven-replacer-plugin" [4] and configure that for the task at hand. (or use your favorite templating language plugin. There's a million of them).
Though, to be fair, this really isn't something that comes up in regular java programming due to the nature of the ecosystem. Anything you'd want to codegen likely already has a library and anything you didn't would receive (legitimate) push back.
> And could you really say that this would be cleaner than the same thing done with cmake?
Probably not. But not really the main point. cmake becomes a problem when you want to do anything more complex than string replacement. Imagine, for example, if you did want to use a code generation library within a project. The strength of maven is a new team dev only needs maven. Further, if they need to update that library they only need to change that maven file.
What happens with cmake if you wanted to update a minimum dependency?
[1] https://www.baeldung.com/java-annotation-processing-builder