6 ms·

It sounds more like the problem is autoconf. Replacing autoconf with cmake or a similar metabuilder will provide a lot more flexibility to build on different p

It sounds more like the problem is autoconf. Replacing autoconf with cmake or a similar metabuilder will provide a lot more flexibility to build on different platforms, including, eg, windows, and cross-build. If it's easier to build on any platform, you don't need to try to get into the custom packager business and just focus on your library.

wirrbel 6y ago
I did my fair share of setting up C and C++ builds in the past and I can tell you: The difference between CMake and Autoconf is marginal, while CMake is of course a bit more versatile in terms of target build-systems, and of course its DSL is not as obscure as autotools toolchain, its no meaningful difference. What Bazel (or Buck) bring to the table is slightly different, its better control of inter-module dependencies and external dependencies. In a way they are not only build tools but opinionated and effective 'linkers', bundling together your applications and libraries in a way that it is hard to mess up and very reproducible. The other option would be the nix/guix route, which I think might be better-suited for the open-source model but require you to adapt at least the package managers.
- Teknoman117 6y ago
  The meaningful difference for me is that I work in a place where most of the developers love their IDEs. CMake is literally the only cross platform build system with first class IDE support on both Windows and Linux. If you use VS Code on macOS, you get it there as well.
  - jhasse 6y ago
    > If you use VS Code on macOS, you get it there as well. CMake can generate Xcode projects.
    - Teknoman117 6y ago
      Right, what I meant by developers who love their IDEs is that they complain if they see a console. They just want to open an IDE and click "open folder" or "open project", so not having to use an intermediate IDE project generator is a massive boon.
  - ajconway 6y ago
    CMake does very good when you have a C/C++ project, but it very poorly suited for cross-language dependencies. Blaze-like build systems, on the other hand, were built specifically for that.
  - JamesSwift 6y ago
    After digging into Bazel a bit recently, I really hope they invest significant energy into the IDE story next. That is a huge, gaping hole that is being not-really solved in all the language/IDE ecosystems and is a _massive_ roadblock to adoption. IDE integration would remove 90% of my hesitation to push it at my company.
    - vlovich123 6y ago
      It’s not much work. Internally at Google they have Idea integration. The challenge for open sourcing it may be that the plugin is also responsible for Google3 integration if I recall correctly.
      - JamesSwift 6y ago
        "not much work" is absolutely not the feeling I have about it based on some conference talks about the topic (e.g. the various xcode talks, or the Wix talks on intelliJ), and my own thought experiments on getting it tied into Visual Studio / Visual Studio for Mac. I think the Bazel team introduced Aspects and punted the rest for a later date. Now they hope each language/IDE community will take that infrastructure and build out the rest of the ecosystem. I think its too important of a piece of the puzzle to leave to the community.
    - Teknoman117 6y ago
      I really like Bazel as well. As you said, cross language dependency management in CMake is hilariously annoying. However, I'm at practically a C++ only shop so it rarely comes up. Where I am we were using CMake 2 for our build system for a long time and it got into bad shape. When we made the decision to rewrite the build system (across a few dozen subprojects), we looked at a few - Meson, Bazel, CMake, etc. CMake was hard to argue against because of the recent work (last few years) by Microsoft to support CMake projects directly (File -> Open Folder). We wanted to try to get away from maintaining separate IDE projects for every platform for every project.
- outsomnia 6y ago
  Well, one "meaningful difference" is I can find devs who have experience with cmake...
  - EdSchouten 6y ago
    You have to start somewhere, right? The same thing was said about things like Kubernetes a couple of years ago. Look at where we are now.
    - bluGill 6y ago
      Autoconf has been around for years, cmake for much less, yet cmake was able to become the major build system for C++ and get everywhere. I don't think autoconf has a future - even when it was "the only choice" everyone avoided it if they could. Cmake took over and became the thing everyone knew. Now if you (like the article) proposing something else you might have a chance. However autoconf has lost.
      - klodolph 6y ago
        Autoconf "lost" in the sense that it solved the problems that it needed to solve and is no longer needed.
        bregma 6y ago
        Autoconf solves the problem of easily porting software to different systems because autodiscovery is its default modus operandi. Now that we live in a post-innovation world, there is no need to port software: it's either Linux, Mac OS, or Windows. Except, of course, there is still a lot of innovation going on, and there's a lot of porting and cross-building that happens outside the the web domain, and a heck of a lot of things that are none of the big three development hosts. CMake is starting to converge towards what the autotools have provided for some decades now, but it's not there yet. When it comes down to it, the only real difference is different domain-specific languages and that just results in tribalism.
- bluGill 6y ago
  The meaningful difference for me is I cross compile everything. Every cmake project I've worked with just works. As in it only takes a couple hours to get it packaged for my custom (stupid...) package system I have to use, almost all of that boilerplate work. Only 1 in 50 autoconf project I've worked with actually works - in theory autoconf supports this case well, but in practice there is always something broken and so I know I'll spend a couple weeks (full time) getting it packaged.
badsectoracula 6y ago
One thing however that the autotools do and i do not see any of the other supposedly replacements do is that from the users (be it an application user who wants to compile the code or a developer who wants to compile a library but does not have plans to develop it, so for all intents and purposes the are just a "user" of that library) is that it does not require autotools to be installed unless you want to modify the project structure itself (even simple code changes are most of the time fine without having autotools). It only requires a Make but that is basically a standard and available anywhere, unlike the other systems that they target (and cmake, etc, also need Make anyway). I always found that annoying because if i just want to compile something (be it a program or a library) from source, i also need to install a bunch of build systems i'm not going to ever use myself. That is just pure and unnecessary bloat for me.
- jcranmer 6y ago
  The flip side of this is that it means most projects come with an old version of autotools--and if you need to do something where "old" is equivalent to "broken", it becomes a wonderful world of pain. A specific example I ran into was compiling random projects with -flto. libtool, in its infinite wisdom, decided long ago that it was a bad idea to pass any -f flags to the linker invocation and so stripped them out, even if you the user manually told it to via LDFLAGS. This of course breaks -flto--so newer versions of libtool got the picture and whitelisted that flag. Except projects haven't updated libtool for a while, so you have to patch their source to get it to work.
  - badsectoracula 6y ago
    AFAICT if you need to modify the build configuration -changing optimization levels is one such things since optimizations can potentially break applications- you are expected to install (and hence, update) autotools as if you were a developer of the program/library. But TBH my comment was more about the other build tools than autotools... Autotools have many issues and are way more complex than need to be, but i do not see a build tool that does exactly the same thing as autotools do, despite being so many tools out there.
klodolph 6y ago
The problem is autoconf because the problems that autoconf was designed to solve are not the problems we want to solve today. Autoconf does an excellent job of solving the problems that it was designed to solve--configuring a build system on different POSIX-like systems--but times have changed. My experience using CMake and Autotools and migrating between the two is... the only appreciable benefit to CMake is that it works well enough on Windows, and Autotools sucks on Windows. Whereas Bazel is in a different league, IMO. For people on Windows, the fact that CMake works well on Windows is enough to sing its praises, but I think Bazel will be eating the C and C++ world over the next five years. In defense of Autotools, it's designed to work on systems which don't have Autotools installed, back in an era where you might download Apache and compile it from source to get a web server running on your system. It will work on a stock install of Linux, Solaris, AIX, or macOS. Almost nobody cares about this use case any more.
- jnxx 6y ago
  > For people on Windows, the fact that CMake works well on Windows is enough to sing its praises, Maybe, but how relevant is this? Application development on Windows is historically not based on open source, and for developing anything else than Windows apps, supporting something different from a POSIX system is not really important. > but I think Bazel will be eating the C and C++ world over the next five years. Do you think bazel is better than NixOS and GNU Guix? I think things like bazel are pretty much geared to big companies which want to move ecosystems to the cloud and have a lot of manpower to support very complex dependency systems. I think that for distributed open source projects, a system like Guix which decouples individual packages while suppurting (or even requiring) a build from source is better. There is also the issue that with a bazel build, there is potentially a whole lot of stuff which runs uncontrolled on your local system. It is basically "curl | bash" on stereoids, which means you hand over your machine to the cloud.

wirrbel 6y ago

I did my fair share of setting up C and C++ builds in the past and I can tell you: The difference between CMake and Autoconf is marginal, while CMake is of course a bit more versatile in terms of target build-systems, and of course its DSL is not as obscure as autotools toolchain, its no meaningful difference. What Bazel (or Buck) bring to the table is slightly different, its better control of inter-module dependencies and external dependencies. In a way they are not only build tools but opinionated and effective 'linkers', bundling together your applications and libraries in a way that it is hard to mess up and very reproducible. The other option would be the nix/guix route, which I think might be better-suited for the open-source model but require you to adapt at least the package managers.

Teknoman117 6y ago
The meaningful difference for me is that I work in a place where most of the developers love their IDEs. CMake is literally the only cross platform build system with first class IDE support on both Windows and Linux. If you use VS Code on macOS, you get it there as well.
- jhasse 6y ago
  > If you use VS Code on macOS, you get it there as well. CMake can generate Xcode projects.
  - Teknoman117 6y ago
    Right, what I meant by developers who love their IDEs is that they complain if they see a console. They just want to open an IDE and click "open folder" or "open project", so not having to use an intermediate IDE project generator is a massive boon.
- ajconway 6y ago
  CMake does very good when you have a C/C++ project, but it very poorly suited for cross-language dependencies. Blaze-like build systems, on the other hand, were built specifically for that.
- JamesSwift 6y ago
  After digging into Bazel a bit recently, I really hope they invest significant energy into the IDE story next. That is a huge, gaping hole that is being not-really solved in all the language/IDE ecosystems and is a _massive_ roadblock to adoption. IDE integration would remove 90% of my hesitation to push it at my company.
  - vlovich123 6y ago
    It’s not much work. Internally at Google they have Idea integration. The challenge for open sourcing it may be that the plugin is also responsible for Google3 integration if I recall correctly.
    - JamesSwift 6y ago
      "not much work" is absolutely not the feeling I have about it based on some conference talks about the topic (e.g. the various xcode talks, or the Wix talks on intelliJ), and my own thought experiments on getting it tied into Visual Studio / Visual Studio for Mac. I think the Bazel team introduced Aspects and punted the rest for a later date. Now they hope each language/IDE community will take that infrastructure and build out the rest of the ecosystem. I think its too important of a piece of the puzzle to leave to the community.
  - Teknoman117 6y ago
    I really like Bazel as well. As you said, cross language dependency management in CMake is hilariously annoying. However, I'm at practically a C++ only shop so it rarely comes up. Where I am we were using CMake 2 for our build system for a long time and it got into bad shape. When we made the decision to rewrite the build system (across a few dozen subprojects), we looked at a few - Meson, Bazel, CMake, etc. CMake was hard to argue against because of the recent work (last few years) by Microsoft to support CMake projects directly (File -> Open Folder). We wanted to try to get away from maintaining separate IDE projects for every platform for every project.
outsomnia 6y ago
Well, one "meaningful difference" is I can find devs who have experience with cmake...
- EdSchouten 6y ago
  You have to start somewhere, right? The same thing was said about things like Kubernetes a couple of years ago. Look at where we are now.
  - bluGill 6y ago
    Autoconf has been around for years, cmake for much less, yet cmake was able to become the major build system for C++ and get everywhere. I don't think autoconf has a future - even when it was "the only choice" everyone avoided it if they could. Cmake took over and became the thing everyone knew. Now if you (like the article) proposing something else you might have a chance. However autoconf has lost.
    - klodolph 6y ago
      Autoconf "lost" in the sense that it solved the problems that it needed to solve and is no longer needed.
      - bregma 6y ago
        Autoconf solves the problem of easily porting software to different systems because autodiscovery is its default modus operandi. Now that we live in a post-innovation world, there is no need to port software: it's either Linux, Mac OS, or Windows. Except, of course, there is still a lot of innovation going on, and there's a lot of porting and cross-building that happens outside the the web domain, and a heck of a lot of things that are none of the big three development hosts. CMake is starting to converge towards what the autotools have provided for some decades now, but it's not there yet. When it comes down to it, the only real difference is different domain-specific languages and that just results in tribalism.
bluGill 6y ago
The meaningful difference for me is I cross compile everything. Every cmake project I've worked with just works. As in it only takes a couple hours to get it packaged for my custom (stupid...) package system I have to use, almost all of that boilerplate work. Only 1 in 50 autoconf project I've worked with actually works - in theory autoconf supports this case well, but in practice there is always something broken and so I know I'll spend a couple weeks (full time) getting it packaged.

badsectoracula 6y ago

One thing however that the autotools do and i do not see any of the other supposedly replacements do is that from the users (be it an application user who wants to compile the code or a developer who wants to compile a library but does not have plans to develop it, so for all intents and purposes the are just a "user" of that library) is that it does not require autotools to be installed unless you want to modify the project structure itself (even simple code changes are most of the time fine without having autotools). It only requires a Make but that is basically a standard and available anywhere, unlike the other systems that they target (and cmake, etc, also need Make anyway). I always found that annoying because if i just want to compile something (be it a program or a library) from source, i also need to install a bunch of build systems i'm not going to ever use myself. That is just pure and unnecessary bloat for me.

jcranmer 6y ago
The flip side of this is that it means most projects come with an old version of autotools--and if you need to do something where "old" is equivalent to "broken", it becomes a wonderful world of pain. A specific example I ran into was compiling random projects with -flto. libtool, in its infinite wisdom, decided long ago that it was a bad idea to pass any -f flags to the linker invocation and so stripped them out, even if you the user manually told it to via LDFLAGS. This of course breaks -flto--so newer versions of libtool got the picture and whitelisted that flag. Except projects haven't updated libtool for a while, so you have to patch their source to get it to work.
- badsectoracula 6y ago
  AFAICT if you need to modify the build configuration -changing optimization levels is one such things since optimizations can potentially break applications- you are expected to install (and hence, update) autotools as if you were a developer of the program/library. But TBH my comment was more about the other build tools than autotools... Autotools have many issues and are way more complex than need to be, but i do not see a build tool that does exactly the same thing as autotools do, despite being so many tools out there.

klodolph 6y ago

The problem is autoconf because the problems that autoconf was designed to solve are not the problems we want to solve today. Autoconf does an excellent job of solving the problems that it was designed to solve--configuring a build system on different POSIX-like systems--but times have changed. My experience using CMake and Autotools and migrating between the two is... the only appreciable benefit to CMake is that it works well enough on Windows, and Autotools sucks on Windows. Whereas Bazel is in a different league, IMO. For people on Windows, the fact that CMake works well on Windows is enough to sing its praises, but I think Bazel will be eating the C and C++ world over the next five years. In defense of Autotools, it's designed to work on systems which don't have Autotools installed, back in an era where you might download Apache and compile it from source to get a web server running on your system. It will work on a stock install of Linux, Solaris, AIX, or macOS. Almost nobody cares about this use case any more.

jnxx 6y ago
> For people on Windows, the fact that CMake works well on Windows is enough to sing its praises, Maybe, but how relevant is this? Application development on Windows is historically not based on open source, and for developing anything else than Windows apps, supporting something different from a POSIX system is not really important. > but I think Bazel will be eating the C and C++ world over the next five years. Do you think bazel is better than NixOS and GNU Guix? I think things like bazel are pretty much geared to big companies which want to move ecosystems to the cloud and have a lot of manpower to support very complex dependency systems. I think that for distributed open source projects, a system like Guix which decouples individual packages while suppurting (or even requiring) a build from source is better. There is also the issue that with a bazel build, there is potentially a whole lot of stuff which runs uncontrolled on your local system. It is basically "curl | bash" on stereoids, which means you hand over your machine to the cloud.