6 ms·

> 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++

> 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.

cogman10 4y ago
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".
- throwaway894345 4y ago
  In fairness, many of the CMake criticisms also apply to Gradle in the Java world, but yeah, Go just needs its go.mod file, Rust just needs its Cargo.toml file.
  - palata 4y ago
    I would argue that Gradle is fine, just like CMake is :-). 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.
  - vlovich123 4y ago
    99% of the time but Rust also has build.rs as an escape hatch which lets you run your own code at build time (eg code generator like grpc). The sane part is that you do all this in the same language.
    - throwaway894345 4y ago
      Agreed, but “escape hatch” is the salient distinction. It’s not the default, contra CMake. Also, Rust pays dearly for build.rs support in terms of difficulty optimizing compile times, so supporting that extra 0.1% ain’t free.
- tannhaeuser 4y ago
  > java needs an xml file 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?
  - throwaway894345 4y ago
    This is a straw man. The objection was never "XML is too boring", the objection was "the XML models an actual programming language, so we're doing imperative programming but without the ergonomics and syntax of a programming language". "It's just XML/YAML/HCL! Way easier than programming in an imperative language!" is such a farce (not only among build systems but especially among infrastructure-as-code solutions). Just because it accepts XML doesn't mean your build system is meaningfully declarative.
    - tannhaeuser 4y ago
      Oh, I fully agree with your argument as it applies to the old ant build tool, which is in fact a programming language using XML serialization - the author even apologized for it when he realized syntax wasn't the hard part. But a maven pom.xml is actually a component model serialization rather than a programming language in disguise - unless you're referring to embedded ant scripts in maven files which is a thing, but not common enough to warrant criticism IMO. Scripted deployment tasks in a Java context were more commonly seen in Jenkins, and only recently spill into gradle build scripts (I've always thought gradle was following Jenkins' Groovy syntax for eventual integration but that hasn't happened).
- jcelerier 4y ago
  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'" ) etc etc. these are the requirements we have. can you solve these requirements with just Java's XML ?
  - cogman10 4y ago
    > 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.
- palata 4y ago
  I have worked with Android (ant, maven, gradle), iOS (CocoaPods, Carthage, SwiftPM), C++ (CMake, autotools, meson) and some Python. 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.
- ridiculous_fish 4y ago
  Part of the answer is that C++ wants to interrogate your system or build root to understand its capabilities. "Call this function if available" or "Access this variable if it exists" are more common in C++ projects, compared to the other languages you listed. 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.
  - vlovich123 4y ago
    Rust can do that through build.rs, no?
    - ridiculous_fish 4y ago
      Probably. I would like to see how it's done, build.rs does seem like the most sensible place. Debugging build.rs is painful.
- simplotek 4y ago
  > 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". 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} )
throwaway894345 4y ago
I mean, my remark was a bit of an oversimplification. Modern build systems do a bit more than take a list of dependencies--they'll also allow for bundling data files into the compiled artifact, platform-conditional compilation units, and a few other things. But they don't expose these things as a fully imperative scripting language / meta build system--a few bits of declarative configuration can cover 99.9% of use cases.

cogman10 4y ago

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".

throwaway894345 4y ago
In fairness, many of the CMake criticisms also apply to Gradle in the Java world, but yeah, Go just needs its go.mod file, Rust just needs its Cargo.toml file.
- palata 4y ago
  I would argue that Gradle is fine, just like CMake is :-). 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.
- vlovich123 4y ago
  99% of the time but Rust also has build.rs as an escape hatch which lets you run your own code at build time (eg code generator like grpc). The sane part is that you do all this in the same language.
  - throwaway894345 4y ago
    Agreed, but “escape hatch” is the salient distinction. It’s not the default, contra CMake. Also, Rust pays dearly for build.rs support in terms of difficulty optimizing compile times, so supporting that extra 0.1% ain’t free.
tannhaeuser 4y ago
> java needs an xml file 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?
- throwaway894345 4y ago
  This is a straw man. The objection was never "XML is too boring", the objection was "the XML models an actual programming language, so we're doing imperative programming but without the ergonomics and syntax of a programming language". "It's just XML/YAML/HCL! Way easier than programming in an imperative language!" is such a farce (not only among build systems but especially among infrastructure-as-code solutions). Just because it accepts XML doesn't mean your build system is meaningfully declarative.
  - tannhaeuser 4y ago
    Oh, I fully agree with your argument as it applies to the old ant build tool, which is in fact a programming language using XML serialization - the author even apologized for it when he realized syntax wasn't the hard part. But a maven pom.xml is actually a component model serialization rather than a programming language in disguise - unless you're referring to embedded ant scripts in maven files which is a thing, but not common enough to warrant criticism IMO. Scripted deployment tasks in a Java context were more commonly seen in Jenkins, and only recently spill into gradle build scripts (I've always thought gradle was following Jenkins' Groovy syntax for eventual integration but that hasn't happened).
jcelerier 4y ago
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'" ) etc etc. these are the requirements we have. can you solve these requirements with just Java's XML ?
- cogman10 4y ago
  > 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.
palata 4y ago
I have worked with Android (ant, maven, gradle), iOS (CocoaPods, Carthage, SwiftPM), C++ (CMake, autotools, meson) and some Python. 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.
ridiculous_fish 4y ago
Part of the answer is that C++ wants to interrogate your system or build root to understand its capabilities. "Call this function if available" or "Access this variable if it exists" are more common in C++ projects, compared to the other languages you listed. 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.
- vlovich123 4y ago
  Rust can do that through build.rs, no?
  - ridiculous_fish 4y ago
    Probably. I would like to see how it's done, build.rs does seem like the most sensible place. Debugging build.rs is painful.
simplotek 4y ago
> 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". 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} )

throwaway894345 4y ago

I mean, my remark was a bit of an oversimplification. Modern build systems do a bit more than take a list of dependencies--they'll also allow for bundling data files into the compiled artifact, platform-conditional compilation units, and a few other things. But they don't expose these things as a fully imperative scripting language / meta build system--a few bits of declarative configuration can cover 99.9% of use cases.