4 ms·

A better solution is just to write a plain ass shell script that tests if various C snippets compile. https://github.com/oilshell/oil/blob/master/configure ht

by chubot 3y ago

A better solution is just to write a plain ass shell script that tests if various C snippets compile. https://github.com/oilshell/oil/blob/master/configure https://github.com/oilshell/oil/blob/master/configure https://github.com/oilshell/oil/blob/master/build/detect-pwent.c https://github.com/oilshell/oil/blob/master/build/detect-pwe... Not an unholy mix of m4, shell, and C, all in the same file. --- These are the same style as a the configure scripts that Fabrice Bellard wrote for tcc and QEMU. They are plain ass shell scripts, because he actually understands the code he writes. https://github.com/qemu/qemu/blob/master/configure https://github.com/qemu/qemu/blob/master/configure https://github.com/TinyCC/tinycc/blob/mob/configure https://github.com/TinyCC/tinycc/blob/mob/configure OCaml’s configure script is also “normal”. You don’t have to copy and paste thousands of lines of GNU stuff that you don’t understand. (copy of lobste.rs comment)

Gormo 3y ago
> A better solution is just to write a plain ass shell script that tests if various C snippets compile. Then standardize those scripts and share them so others can benefit from code reuse. Then build a configuration tool to make it easy for everyone to define collections of tests applicable to their software. Then create a meta-level scripting system so all of the above can be integrated into the software build process. Then complain about how confusing and complicated the whole thing has become and start over from the beginning again.
- chubot 3y ago
  If you redid all that work, and managed to avoid m4, it would still be a win! I believe m4 was used because some Unix shells at the time did not have functions. All shells have functions now -- it's in POSIX. If you have shell functions, then you can have modularity without concatenating blocks of code. You can make a library of functions, and then allow people to reuse them. It could just be source lib_configure.sh detect_foo detect_bar etc. POSIX shell can do everything that m4 can, and it's MORE deployed, not less. (Related: some people missed that m4 never runs on the end user machine which compiles the source code -- only on the machine that makes the tarball from the repo.)
forrestthewoods 3y ago
eww. “Try to compile and see if it fails” is awful. I have never and would never do that. That’s so gross.
- stonogo 3y ago
  It's literally the only way to be absolutely certain a specific feature is available. Version checks, shibboleth strings like __GLIBC__, documentation, all of these things can be subverted or lied to. In the end, verifying the desired behavior is present is the only correct move.
  - forrestthewoods 3y ago
    In 17 years of professional dev I have never, ever worked on a project that required such dark arts. glibc is a special evil. zig, which can compile C/C++, solves that conundrum. Hopefully someday the core glibc project fixes itself. Food for thought: cross-compile should be a first class feature of any build system. If you’re depending on a pile of arbitrary system state you’re doing it wrong. zig can compile for any target from any target. It’s beautiful. And not nearly as difficult as people seem to think.
    - naasking 3y ago
      Zig definitely has the right approach, but it's targets are still a bit limited so saying it's not difficult is maybe ignoring gcc's extreme portability that zig hasn't yet had to deal with.
    - stonogo 3y ago
      Congrats on the clean living, but it remains the norm regardless. Both CMake and Autotools use this approach. C and C++ aren't the only languages for which this is true, by the way. It is de rigueur these days to have versioned releases for the purposes of feature gating, but there's half a century of code out there written in languages without that, and explicit feature testing will be with us as long as that code is. Anyway, native cross-compilation is also not a language feature. Plan 9's C compilers can target any supported architecture from any other supported architecture with no special configuration. Autotools, CMake, and "compile and see" are all artifacts of a highly diverse unix ecosystem. Tools like it are the price we pay for heterogeneity. Flexing to accomodate so many subtly different platforms is a big part of what brought things like GNU and llvm to promenence, so it's not a good idea to dismiss it as a bad thing.
technion 3y ago
Djb followed this with email and Djbdns having config scripts that were plain bash. I remember at the time a lot of people got upset - "it can never be portable". But it compiles and runs everywhere it's supported maybe we're OK with not having detection for amigaOS or something.
- chubot 3y ago
  All the good programmers use plain shell -- DJB, Fabrice Bellard, Xavier Leroy for OCaml, etc. :) They don't copy and paste stuff they don't understand (The DJB scripts were almost certainly plain sh and not bash, since I think this machines were BSD. At that time bash wasn't so ubiquitous -- there was more diversity in shells. I did read a bunch of his scripts many years ago.)
guappa 3y ago
"better" until you actually have to support more than 1 system and architecture
kergonath 3y ago
> OCaml’s configure script is also “normal” If that’s this OCaml, it has a configure.ac file in the root directory, which looks suspicious for an Autotools-free package: https://github.com/ocaml/ocaml https://github.com/ocaml/ocaml

by chubot 3y ago

Gormo 3y ago

> A better solution is just to write a plain ass shell script that tests if various C snippets compile. Then standardize those scripts and share them so others can benefit from code reuse. Then build a configuration tool to make it easy for everyone to define collections of tests applicable to their software. Then create a meta-level scripting system so all of the above can be integrated into the software build process. Then complain about how confusing and complicated the whole thing has become and start over from the beginning again.

chubot 3y ago
If you redid all that work, and managed to avoid m4, it would still be a win! I believe m4 was used because some Unix shells at the time did not have functions. All shells have functions now -- it's in POSIX. If you have shell functions, then you can have modularity without concatenating blocks of code. You can make a library of functions, and then allow people to reuse them. It could just be source lib_configure.sh detect_foo detect_bar etc. POSIX shell can do everything that m4 can, and it's MORE deployed, not less. (Related: some people missed that m4 never runs on the end user machine which compiles the source code -- only on the machine that makes the tarball from the repo.)

forrestthewoods 3y ago

eww. “Try to compile and see if it fails” is awful. I have never and would never do that. That’s so gross.

stonogo 3y ago
It's literally the only way to be absolutely certain a specific feature is available. Version checks, shibboleth strings like __GLIBC__, documentation, all of these things can be subverted or lied to. In the end, verifying the desired behavior is present is the only correct move.
- forrestthewoods 3y ago
  In 17 years of professional dev I have never, ever worked on a project that required such dark arts. glibc is a special evil. zig, which can compile C/C++, solves that conundrum. Hopefully someday the core glibc project fixes itself. Food for thought: cross-compile should be a first class feature of any build system. If you’re depending on a pile of arbitrary system state you’re doing it wrong. zig can compile for any target from any target. It’s beautiful. And not nearly as difficult as people seem to think.
  - naasking 3y ago
    Zig definitely has the right approach, but it's targets are still a bit limited so saying it's not difficult is maybe ignoring gcc's extreme portability that zig hasn't yet had to deal with.
  - stonogo 3y ago
    Congrats on the clean living, but it remains the norm regardless. Both CMake and Autotools use this approach. C and C++ aren't the only languages for which this is true, by the way. It is de rigueur these days to have versioned releases for the purposes of feature gating, but there's half a century of code out there written in languages without that, and explicit feature testing will be with us as long as that code is. Anyway, native cross-compilation is also not a language feature. Plan 9's C compilers can target any supported architecture from any other supported architecture with no special configuration. Autotools, CMake, and "compile and see" are all artifacts of a highly diverse unix ecosystem. Tools like it are the price we pay for heterogeneity. Flexing to accomodate so many subtly different platforms is a big part of what brought things like GNU and llvm to promenence, so it's not a good idea to dismiss it as a bad thing.

technion 3y ago

Djb followed this with email and Djbdns having config scripts that were plain bash. I remember at the time a lot of people got upset - "it can never be portable". But it compiles and runs everywhere it's supported maybe we're OK with not having detection for amigaOS or something.

chubot 3y ago
All the good programmers use plain shell -- DJB, Fabrice Bellard, Xavier Leroy for OCaml, etc. :) They don't copy and paste stuff they don't understand (The DJB scripts were almost certainly plain sh and not bash, since I think this machines were BSD. At that time bash wasn't so ubiquitous -- there was more diversity in shells. I did read a bunch of his scripts many years ago.)

guappa 3y ago

"better" until you actually have to support more than 1 system and architecture

kergonath 3y ago

> OCaml’s configure script is also “normal” If that’s this OCaml, it has a configure.ac file in the root directory, which looks suspicious for an Autotools-free package: https://github.com/ocaml/ocaml https://github.com/ocaml/ocaml