4 ms·

What did they use before? GNU make? (on Windows?) It seems like CMake is quite popular now, with LLVM having moved to it a few years ago.

by chubot 9y ago

adzm 9y ago
b2 / bjam, a custom build tool that was bootstrapped via a script that just builds.
- noobermin 9y ago
  If they have a tool that builds it, why require CMake? Why add an unneeded dependency?
  - SXX 9y ago
    One huge advantage: if your project already using CMake then you'll be able to include exact version of Boost library into your project as git submodule. Then it's will be built hassle-free across all of your toolchains and platforms. This will of course require some proper configuration on Boost side, but no doubt they'll handle it.
  - lomnakkus 9y ago
    Well, partly because b2/bjam is aboslutely awful and obtuse, etc. etc. I did some semi-serious experimenting with it at one point and it was just... well, awful. It basically did very few things right. (BTW, don't take this as criticism of the authors of said system. I just don't "we" had learned enough and infrastructure was incredibly far behind what we have now. So I don't "blame" them in the least. It's just a product of its time.)
sevensor 9y ago
I'm not sure what it's like to maintain the build system, but my experience with CMake as a user has been great. It can even generate makefiles for nmake so I can do Windows builds from the comfort of the Windows command line, although I mostly use it under Linux. Under Linux, I've found that CMake is much friendlier when it comes to helping you fix your dependencies than autotools-based build systems.
- weberc2 9y ago
  It probably is nicer than autotools, but my experience with build systems for other languages makes CMake feel like a pile of hacked-together macros. My last company used it for a large codebase and we spent nearly as much time maintaining the build scripts as we did developing features.
  - lomnakkus 9y ago
    Please be specific. What other build systems do you have experience with? (Because, honestly, I've never heard of a "good one", but there are "less bad ones".)
    - weberc2 9y ago
      Cargo and Go's build tool are great.
      - lomnakkus 9y ago
        If all you want to build is Rust and Go code... what happens if you have a project composed of multiple languages? FWIW, I like "cabal-install", the Haskell equivalent of cargo. It also suffers from the same problems as soon as you start to use multiple languages in a project (except C, that's quite well supported). I stress the word "project". If a "project" to you is just a single language then I'm, first of all, happy for you... Unfortunately that's not the reality for many of us, and THAT is why we need build systems. EDIT: Point being: A language-specific build system can be great, but as soon as you get a big project with multiple languages it leaves you, the Master of the Build, with a big problem because you suddenly have to incorporate every $OTHER_LANGUAGE into the build... somehow. All of that integration is on you and is specific to your situation. A build system on the other hand leaves each language implementation with a simple problem: how do I integrate with build system X? One that's settled it works for everyone using build system X, so we're not duplicating that huge amount of effort you would put in in the language-specific-build-tool situation. (Obviously, this imaginary perfect build tool "interface" is highly non-trivial, but that doesn't mean we shouldn't strive for it.)

What did they use before? GNU make? (on Windows?) It seems like CMake is quite popular now, with LLVM having moved to it a few years ago.

by chubot 9y ago

What did they use before? GNU make? (on Windows?) It seems like CMake is quite popular now, with LLVM having moved to it a few years ago.

adzm 9y ago

b2 / bjam, a custom build tool that was bootstrapped via a script that just builds.

noobermin 9y ago
If they have a tool that builds it, why require CMake? Why add an unneeded dependency?
- SXX 9y ago
  One huge advantage: if your project already using CMake then you'll be able to include exact version of Boost library into your project as git submodule. Then it's will be built hassle-free across all of your toolchains and platforms. This will of course require some proper configuration on Boost side, but no doubt they'll handle it.
- lomnakkus 9y ago
  Well, partly because b2/bjam is aboslutely awful and obtuse, etc. etc. I did some semi-serious experimenting with it at one point and it was just... well, awful. It basically did very few things right. (BTW, don't take this as criticism of the authors of said system. I just don't "we" had learned enough and infrastructure was incredibly far behind what we have now. So I don't "blame" them in the least. It's just a product of its time.)

sevensor 9y ago

I'm not sure what it's like to maintain the build system, but my experience with CMake as a user has been great. It can even generate makefiles for nmake so I can do Windows builds from the comfort of the Windows command line, although I mostly use it under Linux. Under Linux, I've found that CMake is much friendlier when it comes to helping you fix your dependencies than autotools-based build systems.

weberc2 9y ago
It probably is nicer than autotools, but my experience with build systems for other languages makes CMake feel like a pile of hacked-together macros. My last company used it for a large codebase and we spent nearly as much time maintaining the build scripts as we did developing features.
- lomnakkus 9y ago
  Please be specific. What other build systems do you have experience with? (Because, honestly, I've never heard of a "good one", but there are "less bad ones".)
  - weberc2 9y ago
    Cargo and Go's build tool are great.
    - lomnakkus 9y ago
      If all you want to build is Rust and Go code... what happens if you have a project composed of multiple languages? FWIW, I like "cabal-install", the Haskell equivalent of cargo. It also suffers from the same problems as soon as you start to use multiple languages in a project (except C, that's quite well supported). I stress the word "project". If a "project" to you is just a single language then I'm, first of all, happy for you... Unfortunately that's not the reality for many of us, and THAT is why we need build systems. EDIT: Point being: A language-specific build system can be great, but as soon as you get a big project with multiple languages it leaves you, the Master of the Build, with a big problem because you suddenly have to incorporate every $OTHER_LANGUAGE into the build... somehow. All of that integration is on you and is specific to your situation. A build system on the other hand leaves each language implementation with a simple problem: how do I integrate with build system X? One that's settled it works for everyone using build system X, so we're not duplicating that huge amount of effort you would put in in the language-specific-build-tool situation. (Obviously, this imaginary perfect build tool "interface" is highly non-trivial, but that doesn't mean we shouldn't strive for it.)