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).
https://mesonbuild.com/Wrapdb-projects.html
Writing new wraps involves essentially porting the target project to meson though, so it's far from trivial.
It is harder to get 400 dependencies than with other ecosystems, I'll admit that. But I see this as a feature. I can't even start to imagine how people deal with security when the most basic app they write gets tens (hundreds?) of transitive dependencies. I guess they don't. Nobody cares about security.
This assumption implies that C++ developers are all one-track wonders that lock themselves in a basement and have no contact with any other programming language or tooling.
> But the tooling is just insanely cumbersome (...)
It really isn't. Node.js with npm or yarn is a far greater mess than anything that happened in C++.
I'd say that 9 out of 10 times people complain about the C++ ecosystem, they are actually talking from a place of ignorance and at best are only complaining about the mess they needlessly dug themselves into.
Case in point: who in their right mind feels the need to bolt on a different scripting language to cmake, a build system that only rarely needs a damn if statement in the project? These guys are clearly deeply invested in making their lives far hard and worse than they need to be. I mean, where's the need?
If anything, this wave of contrarian bullshit targeting C++ only shows the high volume of inexperient and clueless developers who decided to skip learning the basics and instead thought it was a good idea o dive head-first into wheels reinvented very poorly, and from there in proceed to depict their own mess as representative of everyone else's experience.
You can just link all your files together in a single command without make
Not sure why a makefile is so bad.. it’s just a file generation tool which can check out-of-date files and specify dependencies by pointing out which input files are needed for an output.
It should be read as: “Make file”
Makefiles don't work for extremely large and complex applications. That's the whole reason we have junk like CMake and Gradle.
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.
But there is a philosophical question here: I think that developers should master their basic tools to the point where they don't make a mess writing a CMakeLists.txt or a build.gradle.
It feels like many devs think that a tool is too complex if you need to learn it.
But that was too boring, so people turned to gradle and we're back at ad-hoc scripting in a bizarre Turing-complete language. Believe me, I've hated maven with a passion (and still do) but this episode taught me build systems are nothing but a zero-sum game and typical junior-grade pastime.
Update: the story with Node.js is a bit different, but package.json was soon augmented by package-lock.json and yarn at about the same time Webpack and similar became kitchen sinks requiring config-generator tools such as create-react-app. The morale is, the grass is always greener on the other side I guess. Though tbh, cmake always was absolute garbage making autotools look sane in comparison. Now I hear there's legacy/unmaintained and new cmake syntax; what were people thinking?
Just because it accepts XML doesn't mean your build system is meaningfully declarative.
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 ?
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.
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
Never needed 18 programming languages to build. I actually don't think CMake is harder than Gradle or SwiftPM. Most people I see complaining about CMake actually write bad CMakeLists, so the way I see it is that they don't want to learn the basics. And that's maybe why e.g. gradle works better: for many projects, the IDE is probably able to automatically handle an imperfect and not-so-readable gradle configuration, so people don't need to learn gradle.
But the result is the same: they don't really master their build tool.
Rust tries to avoid that by hard-coding availability into the libraries themselves, but the result is less reliable. For example I cannot use `libc::mkostemp` on macOS because Rust has (incorrectly) hard-coded that it is not available on that platform.
CMake is able to detect it, but we pay a cost in build system complexity. I wish instead this detection could be done at runtime.
But your C++ project never needed 18 languages.
If you feel it does, you need to take a step back and take a serious look at the mess you're making because you're making at least 17 mistakes.
Tell me, what exactly does your build need that is not met with the following:
project(foo LANGUAGES CXX)
add_executable(foo_exec ${SOURCE_FILES} )
target_link_libraries(foo_exec ${MY_TARGETS} )
That's funny. After thirty-odd years of C++ development, it's only in the last year or so that I've started to take CMake seriously, since a critical mass of other people seem to have (inexplicably) decided to treat it as something akin to an official C++ build system.