4 ms·

> One last item remains (and possibly the most controversial): not using a language other than C++ to describe how to a package a C++ project Totally agree on

> One last item remains (and possibly the most controversial): not using a language other than C++ to describe how to a package a C++ project Totally agree on this point. Why learn all the quirks of the CMake language just to express the structure of my program?

vvanders 9y ago
This is what makes me love Rust/Cargo so much. You can create pre-build orchestration in your build.rs in the same language as you build your project.
- deleted 9y ago
  [deleted]
- pornel 9y ago
  Initially I thought they've lost their mind to replace domain-specific scripting languages with Rust, but I've come around to love it. It has enabled Cargo use its own package ecosystem at build time as well, so build scripts can easily reuse other crates instead of reinventing the wheel for each project. It also saved Cargo from needing to be a build system that works with everything and supports everyone (the midlayer mistake[1]) and instead 3rd party build-time crates and *-sys library wrappers provide the flexibility. [1] https://lwn.net/Articles/336262/ https://lwn.net/Articles/336262/
  - masklinn 9y ago
    build.rs is a fallback though, the main "language […] to describe how to a package a [Rust] project" is Toml and the Cargo.toml file (http://doc.crates.io/manifest.html http://doc.crates.io/manifest.html), build.rs is the escape hatch if the main manifest file does not suffice. Python uses a Python script as the main entry point to the package, and it's commonly problematic as doing all kinds of weird shit so your package builds (on your machines, until you change your configuration) is a smaller step than looking up what the system already provides, and thus the default. It also makes static package in(tro)spection much more difficult.
    - lomnakkus 9y ago
      > build.rs is a fallback though, the main "language […] to describe how to a package a [Rust] project" is Toml and the Cargo.toml file (http://doc.crates.io/manifest.html http://doc.crates.io/manifest.html), build.rs is the escape hatch if the main manifest file does not suffice. I get the feeling that they're making the exact same mistake that Cabal/cabal-install did in the Haskell world[1] -- they just don't have complex-enough builds and/or a big enough ecosystem yet to know it. (In Cabal/cabal-install there's a "Custom" build type where "anything goes". Unfortunately that means that it's basically impossible for any higher-level tooling to have any idea of what's going on in the build... and hence it thus powerless to introspect anything useful. It's a huge pain.) [1] Not that I blame them, it's just such a tempting thing to do rather than completely redesigning the build system to accomodate everything and provide enough introspection/metadata. So it goes, I guess...
      - vvanders 9y ago
        Considering ~60% of the use cases for build.rs is wrapping C/C++ builds I'd love to know exactly how you expose metadata for that ;).
        lomnakkus 9y ago
        That's a fair point, but even mandating "choose one of Ninja/CMake/etc." would be helpful in terms of at least getting a little bit of metadata out. This is obviously non-trivial, and I'm not sure how much metadata is even retrievable from my examples, but it's better than nothing. (Ninja and CMake operate at sort of different levels, but that's OK for this purpose, I think. At least you can ask things like "if X changed, what else would change?" without actually having to run a compiler.) (AFAIUI Cabal:Custom had exactly the same reasoning, btw. "It's too difficult! Let's just give up and allow anything.") It might be a practical reality that this is just unavoidable if you want to achieve success, but at a meta-level I think deserves thinking about whether builds should actually be allowed the full Turing Complete treatment. At least, theoretically: As long as we continue 'allowing' Custom for practical reasons and without serious thought, there can be no progress. (Btw, I'm quite mad which it comes to this type of thing. I spend way too much time thinking about build systems, etc.) EDIT: This problem manifests EVERYWHERE: Docker builds randomly guess wrong about whether inputs have changed, cabal-install gets it wrong, SBT/Zinc doesn't quite track dependencies correctly, etc. etc. and it's infuriating.
ridiculous_fish 9y ago
Raw C++ is unsuitable as a build language, so you'll have to layer a DSL on top of it. Either way you're learning a new language. As to "why learn all the quirks of CMake," the selling points of CMake are its widespread availability, maturity, and coverage. For example, just on the packaging side, it knows how to create tarballs, .debs, .rpms, Windows .msi files, multiple flavors of Mac installers... Less mature build tools require you to implement this stuff manually. CMake mostly handles it for you (and has the scars to prove it).
- desertrider12 9y ago
  C++ as it exists now is unsuitable, but I can imagine an alternate history where C++ actually allowed arbitrary compile time execution (better than macros and constexpr). Then someone would have made a library for build system logic, and all the user would have to do is g++ project.cpp.
  - fatbob 9y ago
    Herb Sutter has a proposal for metaclasses, which involve running some compile-time C++-like code. I don't think it would stretch to this, but it's heading in your direction.
- pjmlp 9y ago
  I do like cmake, however I think that actually C++03 is the one unsuitable, C++17 is quite capable. All those actions can be easily modeled in a libraries coupled with a DSL.
Jaxan 9y ago
I never understood why people insist of having a single language for all parts of development. Most developers already (should) speak a few languages, so one extra is fine, I guess. I strongly believe in DSLs.
- Koshkin 9y ago
  It's not that they "insist", it's just that when you look at a modern general-purpose programming language you often ask yourself, why couldn't I use it for such and such particular purpose?

vvanders 9y ago

This is what makes me love Rust/Cargo so much. You can create pre-build orchestration in your build.rs in the same language as you build your project.

deleted 9y ago
[deleted]
pornel 9y ago
Initially I thought they've lost their mind to replace domain-specific scripting languages with Rust, but I've come around to love it. It has enabled Cargo use its own package ecosystem at build time as well, so build scripts can easily reuse other crates instead of reinventing the wheel for each project. It also saved Cargo from needing to be a build system that works with everything and supports everyone (the midlayer mistake[1]) and instead 3rd party build-time crates and *-sys library wrappers provide the flexibility. [1] https://lwn.net/Articles/336262/ https://lwn.net/Articles/336262/
- masklinn 9y ago
  build.rs is a fallback though, the main "language […] to describe how to a package a [Rust] project" is Toml and the Cargo.toml file (http://doc.crates.io/manifest.html http://doc.crates.io/manifest.html), build.rs is the escape hatch if the main manifest file does not suffice. Python uses a Python script as the main entry point to the package, and it's commonly problematic as doing all kinds of weird shit so your package builds (on your machines, until you change your configuration) is a smaller step than looking up what the system already provides, and thus the default. It also makes static package in(tro)spection much more difficult.
  - lomnakkus 9y ago
    > build.rs is a fallback though, the main "language […] to describe how to a package a [Rust] project" is Toml and the Cargo.toml file (http://doc.crates.io/manifest.html http://doc.crates.io/manifest.html), build.rs is the escape hatch if the main manifest file does not suffice. I get the feeling that they're making the exact same mistake that Cabal/cabal-install did in the Haskell world[1] -- they just don't have complex-enough builds and/or a big enough ecosystem yet to know it. (In Cabal/cabal-install there's a "Custom" build type where "anything goes". Unfortunately that means that it's basically impossible for any higher-level tooling to have any idea of what's going on in the build... and hence it thus powerless to introspect anything useful. It's a huge pain.) [1] Not that I blame them, it's just such a tempting thing to do rather than completely redesigning the build system to accomodate everything and provide enough introspection/metadata. So it goes, I guess...
    - vvanders 9y ago
      Considering ~60% of the use cases for build.rs is wrapping C/C++ builds I'd love to know exactly how you expose metadata for that ;).
      - lomnakkus 9y ago
        That's a fair point, but even mandating "choose one of Ninja/CMake/etc." would be helpful in terms of at least getting a little bit of metadata out. This is obviously non-trivial, and I'm not sure how much metadata is even retrievable from my examples, but it's better than nothing. (Ninja and CMake operate at sort of different levels, but that's OK for this purpose, I think. At least you can ask things like "if X changed, what else would change?" without actually having to run a compiler.) (AFAIUI Cabal:Custom had exactly the same reasoning, btw. "It's too difficult! Let's just give up and allow anything.") It might be a practical reality that this is just unavoidable if you want to achieve success, but at a meta-level I think deserves thinking about whether builds should actually be allowed the full Turing Complete treatment. At least, theoretically: As long as we continue 'allowing' Custom for practical reasons and without serious thought, there can be no progress. (Btw, I'm quite mad which it comes to this type of thing. I spend way too much time thinking about build systems, etc.) EDIT: This problem manifests EVERYWHERE: Docker builds randomly guess wrong about whether inputs have changed, cabal-install gets it wrong, SBT/Zinc doesn't quite track dependencies correctly, etc. etc. and it's infuriating.

ridiculous_fish 9y ago

Raw C++ is unsuitable as a build language, so you'll have to layer a DSL on top of it. Either way you're learning a new language. As to "why learn all the quirks of CMake," the selling points of CMake are its widespread availability, maturity, and coverage. For example, just on the packaging side, it knows how to create tarballs, .debs, .rpms, Windows .msi files, multiple flavors of Mac installers... Less mature build tools require you to implement this stuff manually. CMake mostly handles it for you (and has the scars to prove it).

desertrider12 9y ago
C++ as it exists now is unsuitable, but I can imagine an alternate history where C++ actually allowed arbitrary compile time execution (better than macros and constexpr). Then someone would have made a library for build system logic, and all the user would have to do is g++ project.cpp.
- fatbob 9y ago
  Herb Sutter has a proposal for metaclasses, which involve running some compile-time C++-like code. I don't think it would stretch to this, but it's heading in your direction.
pjmlp 9y ago
I do like cmake, however I think that actually C++03 is the one unsuitable, C++17 is quite capable. All those actions can be easily modeled in a libraries coupled with a DSL.

Jaxan 9y ago

I never understood why people insist of having a single language for all parts of development. Most developers already (should) speak a few languages, so one extra is fine, I guess. I strongly believe in DSLs.

Koshkin 9y ago
It's not that they "insist", it's just that when you look at a modern general-purpose programming language you often ask yourself, why couldn't I use it for such and such particular purpose?