5 ms·

Carp all you want about make, I'll take it over any of its ostensible "replacements".

by moonbug 12y ago

Negitivefrags 12y ago
I don't think anyone has a problem with make. The thing you need to replace is autotools.
- davexunit 12y ago
  As crufty as autotools is, nothing comes close to being a more robust build system. It does everything. Learning to use the autotools is difficult, but what's most frustrating is trying to build software that uses clever Makefiles with a bunch of hardcoded assumptions about the platform you are building on that you have to hack to get to work.
  - saboot 12y ago
    "As crufty as autotools is, nothing comes close to being a more robust build system." .. CMake? http://www.cmake.org/ http://www.cmake.org/
    - michael_h 12y ago
      I wish this were true. Getting cmake to do something off the wall like building static executable binaries is...frustrating. I had high hopes for scons, but that turned into a quagmire. Any build system that's going to unseat autotools will need to obviate the need for almost all custom scripts. AKA, specify the 'what', and let the user apply a 'recipe' for the 'how'. Or something...if I knew what it was supposed to look like I'd build it.
      - MereInterest 12y ago
        Out of curiosity, what are the quagmire-ish aspects of scons? I've been using it for a while, and it hasn't seemed too bad, which probably means that I haven't run into them yet.
        michael_h 12y ago
        Scons itself isn't bad, but it's power is also it's downfall: the build script is an unrestricted Python file. I almost always find that something 'clever' has been stashed in the SConscript. Plus, everybody writes wrapper functions for the env.* stuff - meaning just about every project has a second, hidden codebase that you need to learn first.
        MereInterest 12y ago
        Ah, got it. I'll admit that I tend to make build scripts that are a bit too complicated, due to the freedom of having a full language, but it is quite nice to have when needed. It does end up with build scripts that are far more flexible, though, not having read build scripts that others have written, I don't know how much of a cost there is to it.
      - bch 12y ago
        Cmake missed a huge opportunity when they developed their own syntax. Ironically, Cmake was invented specifically[0] for a project that was embedding Tcl, which is what they should have done with Cmake, too (embed Tcl). Cmake can be really nice to use for simple projects, but for the cases it gets you 95% to where you want to be... So frustrating. [0] https://en.wikipedia.org/wiki/CMake#History https://en.wikipedia.org/wiki/CMake#History
      - colin_mccabe 12y ago
        It's not that difficult to get CMake to build a static binary. SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a") SET(BUILD_SHARED_LIBRARIES OFF) SET(CMAKE_EXE_LINKER_FLAGS "-static") The bigger problems with building a static binary on Linux are that: 1. Most Linux distros don't install static versions of libraries. You can't link in a static library dependency that doesn't exist. 2. glibc can't "really" be linked statically because of the way it's designed. See here for the gory details: https://gcc.gnu.org/ml/gcc/1998-12/msg00083.html https://gcc.gnu.org/ml/gcc/1998-12/msg00083.html Naturally, you have problems #1 and #2 with autotools or any other build system as well, since they aren't CMake problems.
    - davexunit 12y ago
      In my experience as a distribution maintainer, cmake is a lot more painful to deal with.
      - saboot 12y ago
        A lot of large projects* I use were formally autotools, and now use CMake. CMake is by far easier to maintain and allows easier integration this code in other projects with dependencies. I will agree that the documentation isn't great, the only way I was able to use it meaningfully by understanding how larger established projects utilize it. http://www-public.slac.stanford.edu/geant4/ http://www-public.slac.stanford.edu/geant4/ https://root.cern.ch/drupal/ https://root.cern.ch/drupal/ https://www.kde.org/ https://www.kde.org/
  - stormbrew 12y ago
    Because your average configure.in actually works on platforms the devs haven't tested it on, right? Truth is most autoconf setups are just arbitrary pastiches of other autoconf setups that the devs didn't really understand. Half the time a bunch of the test results aren't even used, or are testing for something that isn't an issue on any platform it's ever going to be compiled on. And when that makefile breaks? At least you have a hope in hell of understanding why it broke. Autoconf breaks? Good luck.
    - tedunangst 12y ago
      1000x this. Nothing is more "entertaining" than watching a configure script run for a full minute, testing for the presence of standard headers like stdio.h (like wtf are you going to do without that?), in order to build a makefile that can then actually compile the project in only four seconds. This is probably also why libtool's configure probes no fewer than 26 different names for the Fortran compiler my system does not have, and then spends another 26 tests to find out if each of these nonexistent Fortran compilers supports the -g option. https://queue.acm.org/detail.cfm?id=2349257 https://queue.acm.org/detail.cfm?id=2349257
      - crististm 12y ago
        I took my chances at using autotools in 2014. I did this to see for myself if autotools bashing is justified and I can tell you this: If a configure script is that bad, then the project's developers did a poor job using autotools.
        tedunangst 12y ago
        It's hard to believe the problem lies solely with the developers when every project is this bad. For fun, I just downloaded the source for GNU grep. You'd figure they might have some experience. Among the 600 tests configure performs is checking whether mkfifoat is declared without a macro... yes Why? Nowhere in grep is there a single call to mkfifoat. Why does it care? I also liked this: checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes
- atilaneves 12y ago
  I have a problem with make. It's super slow. And impossible to get right. Autotools is awful but better than hand-edited Makefiles. CMake is far far better than either of the previously mentioned options.
nemoniac 12y ago
An overview of the current status of the "replacements" would be welcome. Every so often I go looking for one but end up crawling back to make.
- jjoonathan 12y ago
  The last one I tried was drake, the "Make for data." I was really excited when I saw the demo, it was exactly what I needed! And then I tried to run it. It took 6.5 seconds to run without any input. The "can't handle filenames with spaces" bug has been open for almost two years. And then I went crawling back to make. Again.
SixSigma 12y ago
That's too bad for you http://plan9.bell-labs.com/sys/doc/mk.html http://plan9.bell-labs.com/sys/doc/mk.html
- jjoonathan 12y ago
  What's the killer feature for your workflow? I don't see anything that gets me particularly excited in their "Differences between make and mk" list.
  - yrro 12y ago
    "11. Alternative out-of-date determination Sometimes the modification time is not useful for deciding when a target and prerequisite are out of date. The P attribute replaces the default mechanism with the result of a command. The command immediately follows the attribute and is repeatedly executed with each target and each prerequisite as its arguments; if its exit status is non-zero, they are considered out of date and the recipe is executed." When I want this in GNU Make I end up hacking together something resembling: define test-exec $(filter OK,$(shell if $1 >/dev/null; then echo OK; fi)) endef define test-docker-image $(if $(call test-exec,$(DOCKER) inspect $1,,docker_$1)) endef target: $(call test-docker-image,foo) $(DOCKER) run foo ... docker_%: $(DOCKER) build --force-rm -t project/$* $* It seems this can be replaced with: docker_%:VPdocker inspect: % $DOCKER build --fore-rm -t project/$stem $stem
- Dewie 12y ago
  Plan9 once again show themselves to be the most Unix(-like) - omit the pesky vowels and get a short and sweet unpronounceable (by itself) name with only constants.

Carp all you want about make, I'll take it over any of its ostensible "replacements".

by moonbug 12y ago

Carp all you want about make, I'll take it over any of its ostensible "replacements".

Negitivefrags 12y ago

I don't think anyone has a problem with make. The thing you need to replace is autotools.

davexunit 12y ago
As crufty as autotools is, nothing comes close to being a more robust build system. It does everything. Learning to use the autotools is difficult, but what's most frustrating is trying to build software that uses clever Makefiles with a bunch of hardcoded assumptions about the platform you are building on that you have to hack to get to work.
- saboot 12y ago
  "As crufty as autotools is, nothing comes close to being a more robust build system." .. CMake? http://www.cmake.org/ http://www.cmake.org/
  - michael_h 12y ago
    I wish this were true. Getting cmake to do something off the wall like building static executable binaries is...frustrating. I had high hopes for scons, but that turned into a quagmire. Any build system that's going to unseat autotools will need to obviate the need for almost all custom scripts. AKA, specify the 'what', and let the user apply a 'recipe' for the 'how'. Or something...if I knew what it was supposed to look like I'd build it.
    - MereInterest 12y ago
      Out of curiosity, what are the quagmire-ish aspects of scons? I've been using it for a while, and it hasn't seemed too bad, which probably means that I haven't run into them yet.
      - michael_h 12y ago
        Scons itself isn't bad, but it's power is also it's downfall: the build script is an unrestricted Python file. I almost always find that something 'clever' has been stashed in the SConscript. Plus, everybody writes wrapper functions for the env.* stuff - meaning just about every project has a second, hidden codebase that you need to learn first.
        MereInterest 12y ago
        Ah, got it. I'll admit that I tend to make build scripts that are a bit too complicated, due to the freedom of having a full language, but it is quite nice to have when needed. It does end up with build scripts that are far more flexible, though, not having read build scripts that others have written, I don't know how much of a cost there is to it.
    - bch 12y ago
      Cmake missed a huge opportunity when they developed their own syntax. Ironically, Cmake was invented specifically[0] for a project that was embedding Tcl, which is what they should have done with Cmake, too (embed Tcl). Cmake can be really nice to use for simple projects, but for the cases it gets you 95% to where you want to be... So frustrating. [0] https://en.wikipedia.org/wiki/CMake#History https://en.wikipedia.org/wiki/CMake#History
    - colin_mccabe 12y ago
      It's not that difficult to get CMake to build a static binary. SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a") SET(BUILD_SHARED_LIBRARIES OFF) SET(CMAKE_EXE_LINKER_FLAGS "-static") The bigger problems with building a static binary on Linux are that: 1. Most Linux distros don't install static versions of libraries. You can't link in a static library dependency that doesn't exist. 2. glibc can't "really" be linked statically because of the way it's designed. See here for the gory details: https://gcc.gnu.org/ml/gcc/1998-12/msg00083.html https://gcc.gnu.org/ml/gcc/1998-12/msg00083.html Naturally, you have problems #1 and #2 with autotools or any other build system as well, since they aren't CMake problems.
  - davexunit 12y ago
    In my experience as a distribution maintainer, cmake is a lot more painful to deal with.
    - saboot 12y ago
      A lot of large projects* I use were formally autotools, and now use CMake. CMake is by far easier to maintain and allows easier integration this code in other projects with dependencies. I will agree that the documentation isn't great, the only way I was able to use it meaningfully by understanding how larger established projects utilize it. http://www-public.slac.stanford.edu/geant4/ http://www-public.slac.stanford.edu/geant4/ https://root.cern.ch/drupal/ https://root.cern.ch/drupal/ https://www.kde.org/ https://www.kde.org/
- stormbrew 12y ago
  Because your average configure.in actually works on platforms the devs haven't tested it on, right? Truth is most autoconf setups are just arbitrary pastiches of other autoconf setups that the devs didn't really understand. Half the time a bunch of the test results aren't even used, or are testing for something that isn't an issue on any platform it's ever going to be compiled on. And when that makefile breaks? At least you have a hope in hell of understanding why it broke. Autoconf breaks? Good luck.
  - tedunangst 12y ago
    1000x this. Nothing is more "entertaining" than watching a configure script run for a full minute, testing for the presence of standard headers like stdio.h (like wtf are you going to do without that?), in order to build a makefile that can then actually compile the project in only four seconds. This is probably also why libtool's configure probes no fewer than 26 different names for the Fortran compiler my system does not have, and then spends another 26 tests to find out if each of these nonexistent Fortran compilers supports the -g option. https://queue.acm.org/detail.cfm?id=2349257 https://queue.acm.org/detail.cfm?id=2349257
    - crististm 12y ago
      I took my chances at using autotools in 2014. I did this to see for myself if autotools bashing is justified and I can tell you this: If a configure script is that bad, then the project's developers did a poor job using autotools.
      - tedunangst 12y ago
        It's hard to believe the problem lies solely with the developers when every project is this bad. For fun, I just downloaded the source for GNU grep. You'd figure they might have some experience. Among the 600 tests configure performs is checking whether mkfifoat is declared without a macro... yes Why? Nowhere in grep is there a single call to mkfifoat. Why does it care? I also liked this: checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes checking for MAP_ANONYMOUS... yes
atilaneves 12y ago
I have a problem with make. It's super slow. And impossible to get right. Autotools is awful but better than hand-edited Makefiles. CMake is far far better than either of the previously mentioned options.

nemoniac 12y ago

An overview of the current status of the "replacements" would be welcome. Every so often I go looking for one but end up crawling back to make.

jjoonathan 12y ago
The last one I tried was drake, the "Make for data." I was really excited when I saw the demo, it was exactly what I needed! And then I tried to run it. It took 6.5 seconds to run without any input. The "can't handle filenames with spaces" bug has been open for almost two years. And then I went crawling back to make. Again.

SixSigma 12y ago

That's too bad for you http://plan9.bell-labs.com/sys/doc/mk.html http://plan9.bell-labs.com/sys/doc/mk.html

jjoonathan 12y ago
What's the killer feature for your workflow? I don't see anything that gets me particularly excited in their "Differences between make and mk" list.
- yrro 12y ago
  "11. Alternative out-of-date determination Sometimes the modification time is not useful for deciding when a target and prerequisite are out of date. The P attribute replaces the default mechanism with the result of a command. The command immediately follows the attribute and is repeatedly executed with each target and each prerequisite as its arguments; if its exit status is non-zero, they are considered out of date and the recipe is executed." When I want this in GNU Make I end up hacking together something resembling: define test-exec $(filter OK,$(shell if $1 >/dev/null; then echo OK; fi)) endef define test-docker-image $(if $(call test-exec,$(DOCKER) inspect $1,,docker_$1)) endef target: $(call test-docker-image,foo) $(DOCKER) run foo ... docker_%: $(DOCKER) build --force-rm -t project/$* $* It seems this can be replaced with: docker_%:VPdocker inspect: % $DOCKER build --fore-rm -t project/$stem $stem
Dewie 12y ago
Plan9 once again show themselves to be the most Unix(-like) - omit the pesky vowels and get a short and sweet unpronounceable (by itself) name with only constants.