3 ms·

TIL thank you!

by srik 2y ago

TIL thank you!

bandrami 2y ago
I sometimes wonder if we would even have autotools or cmake if people just knew about this one simple trick
- o11c 2y ago
  Autotools is designed to solve one very important problem: how do you build the GNU tools in the first place if all you have is some obscure Unix from the 1980s. If you already have gnu make, gnu bash, gnu binutils, gnu coreutils, etc. installed then autotools is pointless. I have yet to find evidence of cmake solving a problem (or even having design), though I guess `ccmake` would be kind of cool if it weren't full of nonsense?
  - t43562 2y ago
    I see Autotools as sort of cool if you're porting to a new platform - the tests find out what works and if that's not enough then you have to make some effort to get around it. If you're lucky, however, you put your autotooled code on some completely new OS/hardware and it just builds. Nowadays the proportion of people who are porting the code is probably much smaller but it's still a way of keeping code working on unix with various compiler, architecture variations. IMO cmake just includes windows more effectively - for autotools you'd probably be forced down the cygwin route. I find it a bit easier to work with but it's still a nightmare from hell sometimes.
  - bandrami 2y ago
    Though there's also gnulib, which as part of the autotools process simply replaces system functions with their own stubs. It was a great idea, briefly, and then it became a fiasco.
  - wichert 2y ago
    Even with all the GNU tools available there are still a lot of system-specific things that you may need to know: supported C version, supported C++ version, how to invoke the compiler, correct compiler flags for warnings / desired C or C++ version / etc, where to install things, how to install them and set the right owner and permissions and many many more. Autotools (and cmake) can figure all of that out for you. If you operate in a monoculture and, for example, only deal with a single Linux distribution on a single architecture most or all of this may not be relevant for you. But if you target a more diverse set of environments it can save you a lot of headaches.
  - jcranmer 2y ago
    One of the other things that autotools does that cmake does (admittedly badly) is provide a "configure" step that gives a much more controllable interface into enabling or disabling features of a program. The problem with autoconf in particular is that it spends a lot of time trying to paper over the compatibility issues of ancient Unixes, whereas modern portability tends to rely more on a concept of a portable abstract system layer. The latter means that most of the work a configure step needs to do isn't "does your system have $UNIX_SYSTEM_CALL" but instead "what OS is this."
    - amiga386 2y ago
      I see it both ways. On the one hand, sure Windows vs macOS vs "Linux/BSD" is so very different, you mainly need OS detection. On the other, I don't need a list of the exact featuresets of Fedora, Debian, FreeBSD, NetBSD, OpenBSD, DragonBSD, MorphOS, etc. so I can write narcissism-of-small-differences shit like: #if defined(SUNOS_V4) || defined(_MSC_VER) || defined(GNU) || defined(FREEBSD) # include <strings.h> #else # include <string.h> #endif I will _gladly_ run a feature test and write: #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_STRING_H # include <string.h> #endif That is soooooooo much cleaner
      - bandrami 2y ago
        This came up with musl, IIRC, and was problematic: the existence of a named header doesn't guarantee it contains what you think it does
      - johnisgood 2y ago
        Speaking of, I am using https://zolk3ri.name/cgit/m4conf/about/ https://zolk3ri.name/cgit/m4conf/about/ so I do not have to use anything more bloated or complex.
    - danudey 2y ago
      You can configure things with cmake! All you need to do is 1. Figure out what varibles you want to change 2. Add a -DVAR_NAME=value parameter to the command-line! ...which sucks to do. Meson is a much better way of doing things, but even that falls into "Here are the supported flags and settings, and then here are variable names for everything else"
- t43562 2y ago
  Make's BIG problem (IMO of course) is that the commands are executed in the system shell. If make supplied it's own shell language, a simplified one, then everything would be fantastic. For one thing, cross platform builds would be much easier to get working as there would be no issue about "is the default shell bash or ash or sh or dash or ksh or whatever" and on Windows there would be no need to use cygwin. The other thing is there would not need to be such a huge clash between the way expansion works in shells versus make which is very confusing when you combine the two.
  - rixed 2y ago
    Yes, but where do you stop? In make shell one would routinely call rm, sed, find... should they be included too? So instead of make including a shell, it would be simpler if busybox included a make.
    - lmm 2y ago
      > In make shell one would routinely call rm, sed, find... should they be included too? If you want to use it as a build tool, yes. The most successful build tools build hermetically, with the build definition specifying the versions of anything and everything that is needed to perform the build. (With Maven you even specify e.g. what version of the Java compiler to use, and it will download and use that version). > So instead of make including a shell, it would be simpler if busybox included a make. Can busybox be used portably from e.g. a user's homedir? I've only ever seen it used as the main system in /bin etc..
      - rixed 2y ago
        Well, I believe make is already the most succesful build tool, at least on every platform I'm caring about (ie any variant of unices + few more). What you are describing looks like packaging more than building. Pinning the versions of everything is not the build tool job. I understand the standpoint of software publishers who want to limit the number of environments they have to suport, but proprietary software is not the use case that every tools should be optimizing for. When, a nix user or a gentoo user decides that she wants this version of library X with this version of library Y, that's not make's job to overide her decision, is it? We need some flexibility.

TIL thank you!

by srik 2y ago

TIL thank you!

bandrami 2y ago

I sometimes wonder if we would even have autotools or cmake if people just knew about this one simple trick

o11c 2y ago
Autotools is designed to solve one very important problem: how do you build the GNU tools in the first place if all you have is some obscure Unix from the 1980s. If you already have gnu make, gnu bash, gnu binutils, gnu coreutils, etc. installed then autotools is pointless. I have yet to find evidence of cmake solving a problem (or even having design), though I guess `ccmake` would be kind of cool if it weren't full of nonsense?
- t43562 2y ago
  I see Autotools as sort of cool if you're porting to a new platform - the tests find out what works and if that's not enough then you have to make some effort to get around it. If you're lucky, however, you put your autotooled code on some completely new OS/hardware and it just builds. Nowadays the proportion of people who are porting the code is probably much smaller but it's still a way of keeping code working on unix with various compiler, architecture variations. IMO cmake just includes windows more effectively - for autotools you'd probably be forced down the cygwin route. I find it a bit easier to work with but it's still a nightmare from hell sometimes.
- bandrami 2y ago
  Though there's also gnulib, which as part of the autotools process simply replaces system functions with their own stubs. It was a great idea, briefly, and then it became a fiasco.
- wichert 2y ago
  Even with all the GNU tools available there are still a lot of system-specific things that you may need to know: supported C version, supported C++ version, how to invoke the compiler, correct compiler flags for warnings / desired C or C++ version / etc, where to install things, how to install them and set the right owner and permissions and many many more. Autotools (and cmake) can figure all of that out for you. If you operate in a monoculture and, for example, only deal with a single Linux distribution on a single architecture most or all of this may not be relevant for you. But if you target a more diverse set of environments it can save you a lot of headaches.
- jcranmer 2y ago
  One of the other things that autotools does that cmake does (admittedly badly) is provide a "configure" step that gives a much more controllable interface into enabling or disabling features of a program. The problem with autoconf in particular is that it spends a lot of time trying to paper over the compatibility issues of ancient Unixes, whereas modern portability tends to rely more on a concept of a portable abstract system layer. The latter means that most of the work a configure step needs to do isn't "does your system have $UNIX_SYSTEM_CALL" but instead "what OS is this."
  - amiga386 2y ago
    I see it both ways. On the one hand, sure Windows vs macOS vs "Linux/BSD" is so very different, you mainly need OS detection. On the other, I don't need a list of the exact featuresets of Fedora, Debian, FreeBSD, NetBSD, OpenBSD, DragonBSD, MorphOS, etc. so I can write narcissism-of-small-differences shit like: #if defined(SUNOS_V4) || defined(_MSC_VER) || defined(GNU) || defined(FREEBSD) # include <strings.h> #else # include <string.h> #endif I will _gladly_ run a feature test and write: #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_STRING_H # include <string.h> #endif That is soooooooo much cleaner
    - bandrami 2y ago
      This came up with musl, IIRC, and was problematic: the existence of a named header doesn't guarantee it contains what you think it does
    - johnisgood 2y ago
      Speaking of, I am using https://zolk3ri.name/cgit/m4conf/about/ https://zolk3ri.name/cgit/m4conf/about/ so I do not have to use anything more bloated or complex.
  - danudey 2y ago
    You can configure things with cmake! All you need to do is 1. Figure out what varibles you want to change 2. Add a -DVAR_NAME=value parameter to the command-line! ...which sucks to do. Meson is a much better way of doing things, but even that falls into "Here are the supported flags and settings, and then here are variable names for everything else"
t43562 2y ago
Make's BIG problem (IMO of course) is that the commands are executed in the system shell. If make supplied it's own shell language, a simplified one, then everything would be fantastic. For one thing, cross platform builds would be much easier to get working as there would be no issue about "is the default shell bash or ash or sh or dash or ksh or whatever" and on Windows there would be no need to use cygwin. The other thing is there would not need to be such a huge clash between the way expansion works in shells versus make which is very confusing when you combine the two.
- rixed 2y ago
  Yes, but where do you stop? In make shell one would routinely call rm, sed, find... should they be included too? So instead of make including a shell, it would be simpler if busybox included a make.
  - lmm 2y ago
    > In make shell one would routinely call rm, sed, find... should they be included too? If you want to use it as a build tool, yes. The most successful build tools build hermetically, with the build definition specifying the versions of anything and everything that is needed to perform the build. (With Maven you even specify e.g. what version of the Java compiler to use, and it will download and use that version). > So instead of make including a shell, it would be simpler if busybox included a make. Can busybox be used portably from e.g. a user's homedir? I've only ever seen it used as the main system in /bin etc..
    - rixed 2y ago
      Well, I believe make is already the most succesful build tool, at least on every platform I'm caring about (ie any variant of unices + few more). What you are describing looks like packaging more than building. Pinning the versions of everything is not the build tool job. I understand the standpoint of software publishers who want to limit the number of environments they have to suport, but proprietary software is not the use case that every tools should be optimizing for. When, a nix user or a gentoo user decides that she wants this version of library X with this version of library Y, that's not make's job to overide her decision, is it? We need some flexibility.