3 ms·

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

by 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.

by 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.