11 ms·

The other issue is that people seem to just copy configure/autotools scripts over from older or other projects because either they are lazy or don't understand

The other issue is that people seem to just copy configure/autotools scripts over from older or other projects because either they are lazy or don't understand them enough to do it themselves. The result is that even with relatively modern code bases that only target something like x86, arm and maybe mips and only gcc/clang, you still get checks for the size of an int, or which header is needed for printf, or whether long long exists.... And then the entire code base never checks the generated macros in a single place, uses int64_t and never checks for stint.h in the configure script...

rbanffy 1y ago
It’s always wise to be specific about the sizes you want for your variables. You don’t want your ancient 64-bit code to act differently on your grandkids 128-bit laptops. Unless, of course, you want to let the compiler decide whether to leverage higher precision types that become available after you retire.
IshKebab 1y ago
I don't think it's fair to say "because they are lazy or don't understand". Who would want to understand that mess? It isn't a virtue. A fairer criticism would be that they have no sense to use a more sane build system. CMake is a mess but even that is faaaaar saner than autotools, and probably more popular at this point.
- xiaoyu2006 1y ago
  Autotools use M4 to meta-program a bash script that meta-programs a bunch of C(++) sources and generates C(++) sources that utilizes meta-programming for different configurations; after which the meta-programmed script, again, meta-programs monolithic makefiles. This is peak engineering.
  - krior 1y ago
    Sounds like a headache. Is there a nice Python lib to generate all this M4-mumbo-jumbo?
    - lionkor 1y ago
      "Sounds complicated. I want it to throw exceptions and have significant whitespace on top of all that complexity!"
      - IshKebab 1y ago
        It was obviously a joke.
      - kazinator 1y ago
        Oh it has significant white space. Make generally doesn't handle paths with spaces, so if you put the build or source directory somewhere where the absolute path has a space, all bets are off.
  - 1718627440 1y ago
    Yes, that sound ridiculous, but it is that way, so that the user can modify each intermediate step, which is the main selling point. As a user I really prefer that experience, which is why I as a developer put up with the non-sense of M4. (Which I think is more due to M4 being a macro language, then inherent language flaws.)
- knorker 1y ago
  autotools is the worst, except for all the others. I'd like to think of myself as reasonable, so I'll just say that reasonable people may disagree with your assertion that cmake is in any way at all better than autotools.
  - IshKebab 1y ago
    Nope, autotools is actually the worst. There is no way in hell anyone reasonable could say that Autotools is better than CMake.
    - tpoacher 1y ago
      And presumably the measure by which they are judged to be reasonable or not is if they prefer CMake over Autotools, correct? :D
      - ordu 1y ago
        Correct. I avoid autotools and cmake as much as I can. I'd better write Makefiles by hand. But when I need to deal with them, I'd prefer cmake. I can can modify CMakeLists.txt in a meaningful way and get the results I want. I wouldn't touch autotools build system because I never was able to figure out which of the files is the configuration that is meant to be edited by hands and not generated by scripts in other files. I tried to dig the documentation but I never made it.
    - pletnes 1y ago
      Configure-make is easier to use for someone else. Configuring a cmake based project is slightly harder. In every other conceivable way I agree 100% (until someone can convince me otherwise)
    - jeroenhd 1y ago
      I've seen programs replicate autotools in their Makefiles. That's actually worse. I've also used the old Visual Studio build tooling. Autotools is terrible, but it's not the worst.
    - 1y ago
- smartmic 1y ago
  I took the trouble (and even spent the money) to get to grips with autotools in a structured and detailed way by buying a book [1] about it and reading as much as possible. Yes, it's not trivial, but autotools are not witchcraft either, but as written elsewhere, a masterpiece of engineering. I have dealt with it without prejudice and since then I have been more of a fan of autotools than a hater. Anyway, I highly recommend the book and yes, after reading it, I think autotools is better than its reputation. [1] https://nostarch.com/autotools2e https://nostarch.com/autotools2e
  - deleted 1y ago
    [deleted]
- NekkoDroid 1y ago
  > CMake is a mess but even that is faaaaar saner than autotools, and probably more popular at this point. Having done a deep dive into CMake I actually kinda like it (really modern cmake is actually very nice, except the DSL but that probably isn't changing any time soon), but that is also the problem: I had to do a deep dive into learning it.
- kazinator 1y ago
  Someone who doesn't want to understand a huge mess should probably not be bringing it into their project. In software you sometimes have to have the courage to reject doing what others do, especially if they're only doing it because of others.
epcoa 1y ago
> either they are lazy or don't understand them enough to do it themselves. Meh, I used to keep printed copies of autotools manuals. I sympathize with all of these people and acknowledge they are likely the sane ones.
- Levitating 1y ago
  I've had projects where I spent more time configuring autoconf than actually writing code. That's what you get for wanting to use a glib function.
rollcat 1y ago
This. Simple projects: just use plain C. This is dwm, the window manager that spawned a thousand forks. No ./configure in sight: <https://git.suckless.org/dwm/files.html https://git.suckless.org/dwm/files.html> If you run into platform-specific stuff, just write a ./configure in simple and plain shell: <https://git.suckless.org/utmp/file/configure.html https://git.suckless.org/utmp/file/configure.html>. Even if you keep adding more stuff, it shouldn't take more than 100ms. If you're doing something really complex (like say, writing a compiler), take the approach from Plan 9 / Go. Make a conditionally included header file that takes care of platform differences for you. Check the $GOARCH/u.h files here: <https://go.googlesource.com/go/+/refs/heads/release-branch.go1.4/include/plan9/ https://go.googlesource.com/go/+/refs/heads/release-branch.g...> (There are also some simple OS-specific checks: <https://go.googlesource.com/go/+/refs/heads/release-branch.go1.4/include/u.h https://go.googlesource.com/go/+/refs/heads/release-branch.g...>) This is the reference Go compiler; it can target any platform, from any host (modulo CGO); later versions are also self-hosting and reproducible.
- knorker 1y ago
  Interesting that you would bring up Go. Go is probably the most head-desk language of all for writing portable code. Go will fight you the whole way. Even plain C is easier. You can have a whole file be for OpenBSD, to work around that some standard library parts have different types on different platforms. So now you need one file for all platforms and architectures where Timeval.Usec is int32, and another file for where it is int64. And you need to enumerate in your code all GOOS/GOARCH combinations that Go supports or will ever support. You need a file for Linux 32 bit ARM (int32/int32 bit), one for Linux 64 bit ARM (int64,int64), one for OpenBSD 32 bit ARM (int64/int32), etc…. Maybe you can group them, but this is just one difference, so in the end you'll have to do one file per combination of OS and Arch. And all you wanted was pluggable "what's a Timeval?". Something that all build systems solved a long time ago. And then maybe the next release of OpenBSD they've changed it, so now you cannot use Go's way to write portable code at all. So between autotools, cmake, and the Go method, the Go method is by far the worst option for writing portable code.
  - rollcat 1y ago
technion 1y ago
There's a trending post right now for printf implemented in bare metal and my first thought was "finally, all that autoconf code that checks for printf can handle the use can where it doesn't exist".
deleted 1y ago
[deleted]

rbanffy 1y ago

It’s always wise to be specific about the sizes you want for your variables. You don’t want your ancient 64-bit code to act differently on your grandkids 128-bit laptops. Unless, of course, you want to let the compiler decide whether to leverage higher precision types that become available after you retire.

IshKebab 1y ago

I don't think it's fair to say "because they are lazy or don't understand". Who would want to understand that mess? It isn't a virtue. A fairer criticism would be that they have no sense to use a more sane build system. CMake is a mess but even that is faaaaar saner than autotools, and probably more popular at this point.

xiaoyu2006 1y ago
Autotools use M4 to meta-program a bash script that meta-programs a bunch of C(++) sources and generates C(++) sources that utilizes meta-programming for different configurations; after which the meta-programmed script, again, meta-programs monolithic makefiles. This is peak engineering.
- krior 1y ago
  Sounds like a headache. Is there a nice Python lib to generate all this M4-mumbo-jumbo?
  - lionkor 1y ago
    "Sounds complicated. I want it to throw exceptions and have significant whitespace on top of all that complexity!"
    - IshKebab 1y ago
      It was obviously a joke.
    - kazinator 1y ago
      Oh it has significant white space. Make generally doesn't handle paths with spaces, so if you put the build or source directory somewhere where the absolute path has a space, all bets are off.
- 1718627440 1y ago
  Yes, that sound ridiculous, but it is that way, so that the user can modify each intermediate step, which is the main selling point. As a user I really prefer that experience, which is why I as a developer put up with the non-sense of M4. (Which I think is more due to M4 being a macro language, then inherent language flaws.)
knorker 1y ago
autotools is the worst, except for all the others. I'd like to think of myself as reasonable, so I'll just say that reasonable people may disagree with your assertion that cmake is in any way at all better than autotools.
- IshKebab 1y ago
  Nope, autotools is actually the worst. There is no way in hell anyone reasonable could say that Autotools is better than CMake.
  - tpoacher 1y ago
    And presumably the measure by which they are judged to be reasonable or not is if they prefer CMake over Autotools, correct? :D
    - ordu 1y ago
      Correct. I avoid autotools and cmake as much as I can. I'd better write Makefiles by hand. But when I need to deal with them, I'd prefer cmake. I can can modify CMakeLists.txt in a meaningful way and get the results I want. I wouldn't touch autotools build system because I never was able to figure out which of the files is the configuration that is meant to be edited by hands and not generated by scripts in other files. I tried to dig the documentation but I never made it.
  - pletnes 1y ago
    Configure-make is easier to use for someone else. Configuring a cmake based project is slightly harder. In every other conceivable way I agree 100% (until someone can convince me otherwise)
  - jeroenhd 1y ago
    I've seen programs replicate autotools in their Makefiles. That's actually worse. I've also used the old Visual Studio build tooling. Autotools is terrible, but it's not the worst.
  - 1y ago
smartmic 1y ago
I took the trouble (and even spent the money) to get to grips with autotools in a structured and detailed way by buying a book [1] about it and reading as much as possible. Yes, it's not trivial, but autotools are not witchcraft either, but as written elsewhere, a masterpiece of engineering. I have dealt with it without prejudice and since then I have been more of a fan of autotools than a hater. Anyway, I highly recommend the book and yes, after reading it, I think autotools is better than its reputation. [1] https://nostarch.com/autotools2e https://nostarch.com/autotools2e
- deleted 1y ago
  [deleted]
NekkoDroid 1y ago
> CMake is a mess but even that is faaaaar saner than autotools, and probably more popular at this point. Having done a deep dive into CMake I actually kinda like it (really modern cmake is actually very nice, except the DSL but that probably isn't changing any time soon), but that is also the problem: I had to do a deep dive into learning it.
kazinator 1y ago
Someone who doesn't want to understand a huge mess should probably not be bringing it into their project. In software you sometimes have to have the courage to reject doing what others do, especially if they're only doing it because of others.

epcoa 1y ago

> either they are lazy or don't understand them enough to do it themselves. Meh, I used to keep printed copies of autotools manuals. I sympathize with all of these people and acknowledge they are likely the sane ones.

Levitating 1y ago
I've had projects where I spent more time configuring autoconf than actually writing code. That's what you get for wanting to use a glib function.

rollcat 1y ago

This. Simple projects: just use plain C. This is dwm, the window manager that spawned a thousand forks. No ./configure in sight: <https://git.suckless.org/dwm/files.html https://git.suckless.org/dwm/files.html> If you run into platform-specific stuff, just write a ./configure in simple and plain shell: <https://git.suckless.org/utmp/file/configure.html https://git.suckless.org/utmp/file/configure.html>. Even if you keep adding more stuff, it shouldn't take more than 100ms. If you're doing something really complex (like say, writing a compiler), take the approach from Plan 9 / Go. Make a conditionally included header file that takes care of platform differences for you. Check the $GOARCH/u.h files here: <https://go.googlesource.com/go/+/refs/heads/release-branch.go1.4/include/plan9/ https://go.googlesource.com/go/+/refs/heads/release-branch.g...> (There are also some simple OS-specific checks: <https://go.googlesource.com/go/+/refs/heads/release-branch.go1.4/include/u.h https://go.googlesource.com/go/+/refs/heads/release-branch.g...>) This is the reference Go compiler; it can target any platform, from any host (modulo CGO); later versions are also self-hosting and reproducible.

knorker 1y ago
Interesting that you would bring up Go. Go is probably the most head-desk language of all for writing portable code. Go will fight you the whole way. Even plain C is easier. You can have a whole file be for OpenBSD, to work around that some standard library parts have different types on different platforms. So now you need one file for all platforms and architectures where Timeval.Usec is int32, and another file for where it is int64. And you need to enumerate in your code all GOOS/GOARCH combinations that Go supports or will ever support. You need a file for Linux 32 bit ARM (int32/int32 bit), one for Linux 64 bit ARM (int64,int64), one for OpenBSD 32 bit ARM (int64/int32), etc…. Maybe you can group them, but this is just one difference, so in the end you'll have to do one file per combination of OS and Arch. And all you wanted was pluggable "what's a Timeval?". Something that all build systems solved a long time ago. And then maybe the next release of OpenBSD they've changed it, so now you cannot use Go's way to write portable code at all. So between autotools, cmake, and the Go method, the Go method is by far the worst option for writing portable code.
- rollcat 1y ago

technion 1y ago

There's a trending post right now for printf implemented in bare metal and my first thought was "finally, all that autoconf code that checks for printf can handle the use can where it doesn't exist".

deleted 1y ago

[deleted]