4 ms·

Dealing with a zillion of handwritten Makefiles sounds more hellish than dealing with autotools. These Makefiles will be more fickle, too. I'm not seeing a conv

Dealing with a zillion of handwritten Makefiles sounds more hellish than dealing with autotools. These Makefiles will be more fickle, too. I'm not seeing a convenience win.

vidarh 3y ago
You dealing with a zillion handwritten configuration files anyway, just hidden behind autotools in ways that most developers are even more clueless about than we are about makefiles.
josephg 3y ago
Are we talking about the same autotools? I'm getting flashbacks to running into some weird bash error in my configure file on line 3563. Where the configure script in question was generated by autoconf, automake, aclocal and all that jazz. Or autoconf mysteriously failing after automake works, or some similar nightmare. When autotools go wrong, trying to fix it feels like trying to breathe while you're held underwater. I'm sure part of the problem is I don't understand autotools as well as I could. But when "build expertise in autotools" is on the table, stabbing my eyes out with a fork starts to seem like an appealing option. Suffice it to say, I prefer to work with handwritten makefiles.
- fl7305 3y ago
  I'm not sure what the best solution is, but I agree on the pain dealing with autotools when they fail. Shotgun debugging where you start poking at things randomly can work for some stuff, but never works here. After working on many different software libraries and frameworks, my firm belief is that you really need to understand the lower layers to use and troubleshoot them effectively. Best case scenario there are excellent error messages and you can easily review logfiles to understand the root cause of the problem. But that is rarely the case. Instead you have to have a detailed mental model of the library/framework you're using, and you must be able to quickly picture what it will do internally for the inputs that you give it. Once you get to that point, many bugs don't appear in the first place because you immediately see that the input/usage doesn't make sense. And the bugs that do happen become much easier to figure out from the output and cryptic error messages you get. All this to say that it is really unappealing to work on things like bugs in someone else's autotool scripts. I just want to compile the program to run it. I don't want to spend months of my life to understand the inner workings of autotools.
- bregma 3y ago
  Yes. If you don;t know what you're doing things can seem difficult and you will have problems. This is not a property of the autotools but a property of life in general.
  - josephg 3y ago
    I seem to get on fine in life in general. I think the suckiness of auto tools gets to me because it’s so utterly unnecessary. Autotools are complex not because it solves a hard problem but because the design is bad. And everyone who interacts with it pays rent for their bad decisions. Compare it to CMake or even cargo - which fundamentally solves the same problem, faster and more reliably on more operating systems. And for no cost at all. The opposite: it’s easier to configure and use. Makefiles can be quite elegant. But it really seems like a waste of human potential to put up with such crap software as autotools. How many neurons do you have devoted to it? You could have used the same time and effort learning something that matters or that brings you joy.
    - bhaak 3y ago
      My personal experience with CMake is contrary to your claim. CMake based compilation breaks far more often for me than with Autotools and because of the crappy documentation I can rarely fix it myself. Cargo and other modern package manager OTOH are bliss compared to both CMake and Autotools but they are usually language specific and other modern non language specific build system are still leading a niche existence.
      - josephg 3y ago
        > Cargo and other modern package manager OTOH are bliss compared to both CMake and Autotools but they are usually language specific and other modern non language specific build system are still leading a niche existence. I hear you about CMake. I think what kills me about all of this stuff is that there's no essential reason we can't have something as nice as cargo for C and C++ code. Compiling C isn't a fundamentally more complex problem than compiling rust or swift. But instead of solving the problem in a clean, generic, cross-platform way that understands package interfaces and boundaries, C/C++ instead accreted hacky, vendor specific macros and junk for decades. And then C build tools need to be horribly complicated to undo all of that damage. Should your code export functions with __declspec(dllexport) (as VC++ demands) or __attribute((dllexport)) for gcc. Can't choose? Maybe your library should define its own idiosyncratic DLL_PUBLIC macro which looks at whether _WIN32 or __GNUC__ is defined on the platform. And now the header file (and thus the exposed functions) can only be machine interpreted if you know which platform / compiler you're building for. What does it do for clang? What should clang do? Aaahhhh nightmare o'clock. All of that when C could just do what every other modern language does and have a nice machine readable public attribute, that gets interpreted differently based on whether the code is compiled into a dynamically linked library or compiled statically. I know hindsight is 20/20. And I'm hopeful that C++20's modules will eventually help. But there's so much stuff like this to unpick that it'll take decades, if it happens at all. We can have nice things. It just takes some engineering and a willingness to change.
- deleted 3y ago
  [deleted]
maxcoder4 3y ago
I never got the hate for Makefiles. Granted I mostly use them for simple projects, but compiling C project takes just a few lines of code (compile .c to .o, .o to executable, optionally provide some PHONY convenience utils) and is very readable and hackable. What's not to love? I'm sure I'm missing something, and it's possible that they don't scale well, but I prefer it to any other could system for small C projects.
- finaard 3y ago
  Problem is that you have a wide range of makes with different syntax. It has gotten better nowadays where GNU make is available pretty much everywhere, but two decades ago you'd have a range of incompatible makes on different UNIX systems, plus a bunch of incompatible makes on Windows as each compiler would come with its own make. Assuming you can ignore Windows you'd typically end up with two makefiles (Makefile and GNUMakefile) and a bunch of includes sharing code all make variants understand.
- grumbel 3y ago
  With autotools you get DESTDIR, --prefix and a bunch of other things that work the same across all projects. With Makefiles everybody is rolling their own thing and you never know what to expect, or frequently have to implement those things yourself. That said, autotools, with its multiple layers of file generation, makes debugging rather annoying. And it's generally much easier to fix a broken Makefile than figuring out why autotools goes wrong.

Dealing with a zillion of handwritten Makefiles sounds more hellish than dealing with autotools. These Makefiles will be more fickle, too. I'm not seeing a convenience win.

vidarh 3y ago

You dealing with a zillion handwritten configuration files anyway, just hidden behind autotools in ways that most developers are even more clueless about than we are about makefiles.

josephg 3y ago

Are we talking about the same autotools? I'm getting flashbacks to running into some weird bash error in my configure file on line 3563. Where the configure script in question was generated by autoconf, automake, aclocal and all that jazz. Or autoconf mysteriously failing after automake works, or some similar nightmare. When autotools go wrong, trying to fix it feels like trying to breathe while you're held underwater. I'm sure part of the problem is I don't understand autotools as well as I could. But when "build expertise in autotools" is on the table, stabbing my eyes out with a fork starts to seem like an appealing option. Suffice it to say, I prefer to work with handwritten makefiles.

fl7305 3y ago
I'm not sure what the best solution is, but I agree on the pain dealing with autotools when they fail. Shotgun debugging where you start poking at things randomly can work for some stuff, but never works here. After working on many different software libraries and frameworks, my firm belief is that you really need to understand the lower layers to use and troubleshoot them effectively. Best case scenario there are excellent error messages and you can easily review logfiles to understand the root cause of the problem. But that is rarely the case. Instead you have to have a detailed mental model of the library/framework you're using, and you must be able to quickly picture what it will do internally for the inputs that you give it. Once you get to that point, many bugs don't appear in the first place because you immediately see that the input/usage doesn't make sense. And the bugs that do happen become much easier to figure out from the output and cryptic error messages you get. All this to say that it is really unappealing to work on things like bugs in someone else's autotool scripts. I just want to compile the program to run it. I don't want to spend months of my life to understand the inner workings of autotools.
bregma 3y ago
Yes. If you don;t know what you're doing things can seem difficult and you will have problems. This is not a property of the autotools but a property of life in general.
- josephg 3y ago
  I seem to get on fine in life in general. I think the suckiness of auto tools gets to me because it’s so utterly unnecessary. Autotools are complex not because it solves a hard problem but because the design is bad. And everyone who interacts with it pays rent for their bad decisions. Compare it to CMake or even cargo - which fundamentally solves the same problem, faster and more reliably on more operating systems. And for no cost at all. The opposite: it’s easier to configure and use. Makefiles can be quite elegant. But it really seems like a waste of human potential to put up with such crap software as autotools. How many neurons do you have devoted to it? You could have used the same time and effort learning something that matters or that brings you joy.
  - bhaak 3y ago
    My personal experience with CMake is contrary to your claim. CMake based compilation breaks far more often for me than with Autotools and because of the crappy documentation I can rarely fix it myself. Cargo and other modern package manager OTOH are bliss compared to both CMake and Autotools but they are usually language specific and other modern non language specific build system are still leading a niche existence.
    - josephg 3y ago
      > Cargo and other modern package manager OTOH are bliss compared to both CMake and Autotools but they are usually language specific and other modern non language specific build system are still leading a niche existence. I hear you about CMake. I think what kills me about all of this stuff is that there's no essential reason we can't have something as nice as cargo for C and C++ code. Compiling C isn't a fundamentally more complex problem than compiling rust or swift. But instead of solving the problem in a clean, generic, cross-platform way that understands package interfaces and boundaries, C/C++ instead accreted hacky, vendor specific macros and junk for decades. And then C build tools need to be horribly complicated to undo all of that damage. Should your code export functions with __declspec(dllexport) (as VC++ demands) or __attribute((dllexport)) for gcc. Can't choose? Maybe your library should define its own idiosyncratic DLL_PUBLIC macro which looks at whether _WIN32 or __GNUC__ is defined on the platform. And now the header file (and thus the exposed functions) can only be machine interpreted if you know which platform / compiler you're building for. What does it do for clang? What should clang do? Aaahhhh nightmare o'clock. All of that when C could just do what every other modern language does and have a nice machine readable public attribute, that gets interpreted differently based on whether the code is compiled into a dynamically linked library or compiled statically. I know hindsight is 20/20. And I'm hopeful that C++20's modules will eventually help. But there's so much stuff like this to unpick that it'll take decades, if it happens at all. We can have nice things. It just takes some engineering and a willingness to change.
deleted 3y ago
[deleted]

maxcoder4 3y ago

I never got the hate for Makefiles. Granted I mostly use them for simple projects, but compiling C project takes just a few lines of code (compile .c to .o, .o to executable, optionally provide some PHONY convenience utils) and is very readable and hackable. What's not to love? I'm sure I'm missing something, and it's possible that they don't scale well, but I prefer it to any other could system for small C projects.

finaard 3y ago
Problem is that you have a wide range of makes with different syntax. It has gotten better nowadays where GNU make is available pretty much everywhere, but two decades ago you'd have a range of incompatible makes on different UNIX systems, plus a bunch of incompatible makes on Windows as each compiler would come with its own make. Assuming you can ignore Windows you'd typically end up with two makefiles (Makefile and GNUMakefile) and a bunch of includes sharing code all make variants understand.
grumbel 3y ago
With autotools you get DESTDIR, --prefix and a bunch of other things that work the same across all projects. With Makefiles everybody is rolling their own thing and you never know what to expect, or frequently have to implement those things yourself. That said, autotools, with its multiple layers of file generation, makes debugging rather annoying. And it's generally much easier to fix a broken Makefile than figuring out why autotools goes wrong.