4 ms·

I thought this was going to be a rant against autoconf. When that rant comes I'll post our 186 line shell script that does what autoconf does for pretty much a

I thought this was going to be a rant against autoconf. When that rant comes I'll post our 186 line shell script that does what autoconf does for pretty much any platform. Handles AIX, Solaris, FreeBSD, HP-UX, IRIX, Linux, NetBSD, OpenBSD, SCO, SunOS, Windows, MacOS. I hate autoconf but that's not part of this thread. I'll wait.

yeowMeng 11y ago
Can you please GNU me yr 186 lines of bytes. I am curious.
qznc 11y ago
Why not write a preemptive blog post?
Ace17 11y ago
I'm curious about this shell script ; this looks to good to be true! Having automated the build of dozens of FOSS packages, I can definitely say that autoconf-based packages are _by far_ the easiest ones to build ; especially if you want to do funny stuff like out-of-tree builds or cross-compilation (can your 186-line script do this?). Some projects (x264, ffmpeg) provide 'configure'-like custom scripts, trying to imitate what autoconf does ; but in practise you can't automate their build the same way you did with autoconf-based projects.
- bhaak 11y ago
  I see where the hate for autoconf comes from. Properly done autoconf is very developer-friendly for building but if you have to maintain it, it can be a nightmare. OTOH, because you can always escape to shell scripts, I usually can fix any issue that crops up. With cmake, I regularly fail, e.g. configuring succeeds but building fails because of a missing library and because I actually have no clue what the standard approach should be (online documentation is abysmal with cmake).
- atilaneves 11y ago
  Have you tried CMake?
  - Ace17 11y ago
    Yes. Cross-compilation of existing packets has proven to be a nightmare with cmake. I have to override manually CMAKE_C_COMPILER, CMAKE_CXX_COMPILER ... Have a look at zenbuild, which is a toy-project of mine trying to homogeneize the build interface of many FOSS projects. Each packet get its script (ala PKGBUILD), it can be seen as a list of hacks around the quirks of each project's build system. Projects using autoconf are a breeze to build: https://github.com/Ace17/zenbuild/blob/master/zen-libxau.sh https://github.com/Ace17/zenbuild/blob/master/zen-libxau.sh But projects using cmake are another story: https://github.com/Ace17/zenbuild/blob/master/zen-x265.sh https://github.com/Ace17/zenbuild/blob/master/zen-x265.sh
  - abiox 11y ago
    i like the idea of cmake, but i thoroughly despise the pseudo-language. i haven't used it in some time, so perhaps it's improved; but the ergonomics, documentation and developer-friendliness of it was absolutely dreadful.
bhaak 11y ago
Unix, Unix, Unix, Unix, Unix, Unix clone, Unix, Unix, Unix, Unix, Windows, Unix. So, your shell script handles Unix, its most popular clone and Windows. ;-) The Windows part is interesting. What are the requirements to run your shell script on Windows?
- thristian 11y ago
  I'm interested that you count BSD-derived OSs as "Unix" but Linux as a "Unix clone", even though they include the same amount of code from AT&T Unix (i.e. zero), and Linux and GNU have traditionally followed AT&T Unix conventions over BSD conventions.
  - danieldk 11y ago
    BSD derived directly from AT&T UNIX. In fact, the last releases of BSD from Berkeley still contained substantial amounts of AT&T code. They made the Net/2 release without AT&T code, but this was not a complete system. 386BSD reimplemented most of the missing parts and modern BSDs built on that work. tl;dr: while modern BSD does not contain AT&T UNIX code anymore, it evolved from AT&T UNIX. In contrast to Linux, it was not a clean-room implementation.
    - rat87 11y ago
      It's a ship of theseus. If you replace the whole things step by step, each step a small one, is it still the same thing or isn't it?
      - danieldk 11y ago
        The point is that it is not a clone of UNIX, it's one of the evolutionary strains of UNIX. You probably won't find substantial amounts of AT&T Research UNIX in Solaris, but it's still UNIX. The lineages of BSD and Solaris can be traced back directly to AT&T Research UNIX.
        abiox 11y ago

yeowMeng 11y ago

Can you please GNU me yr 186 lines of bytes. I am curious.

qznc 11y ago

Why not write a preemptive blog post?

Ace17 11y ago

I'm curious about this shell script ; this looks to good to be true! Having automated the build of dozens of FOSS packages, I can definitely say that autoconf-based packages are _by far_ the easiest ones to build ; especially if you want to do funny stuff like out-of-tree builds or cross-compilation (can your 186-line script do this?). Some projects (x264, ffmpeg) provide 'configure'-like custom scripts, trying to imitate what autoconf does ; but in practise you can't automate their build the same way you did with autoconf-based projects.

bhaak 11y ago
I see where the hate for autoconf comes from. Properly done autoconf is very developer-friendly for building but if you have to maintain it, it can be a nightmare. OTOH, because you can always escape to shell scripts, I usually can fix any issue that crops up. With cmake, I regularly fail, e.g. configuring succeeds but building fails because of a missing library and because I actually have no clue what the standard approach should be (online documentation is abysmal with cmake).
atilaneves 11y ago
Have you tried CMake?
- Ace17 11y ago
  Yes. Cross-compilation of existing packets has proven to be a nightmare with cmake. I have to override manually CMAKE_C_COMPILER, CMAKE_CXX_COMPILER ... Have a look at zenbuild, which is a toy-project of mine trying to homogeneize the build interface of many FOSS projects. Each packet get its script (ala PKGBUILD), it can be seen as a list of hacks around the quirks of each project's build system. Projects using autoconf are a breeze to build: https://github.com/Ace17/zenbuild/blob/master/zen-libxau.sh https://github.com/Ace17/zenbuild/blob/master/zen-libxau.sh But projects using cmake are another story: https://github.com/Ace17/zenbuild/blob/master/zen-x265.sh https://github.com/Ace17/zenbuild/blob/master/zen-x265.sh
- abiox 11y ago
  i like the idea of cmake, but i thoroughly despise the pseudo-language. i haven't used it in some time, so perhaps it's improved; but the ergonomics, documentation and developer-friendliness of it was absolutely dreadful.

bhaak 11y ago

Unix, Unix, Unix, Unix, Unix, Unix clone, Unix, Unix, Unix, Unix, Windows, Unix. So, your shell script handles Unix, its most popular clone and Windows. ;-) The Windows part is interesting. What are the requirements to run your shell script on Windows?

thristian 11y ago
I'm interested that you count BSD-derived OSs as "Unix" but Linux as a "Unix clone", even though they include the same amount of code from AT&T Unix (i.e. zero), and Linux and GNU have traditionally followed AT&T Unix conventions over BSD conventions.
- danieldk 11y ago
  BSD derived directly from AT&T UNIX. In fact, the last releases of BSD from Berkeley still contained substantial amounts of AT&T code. They made the Net/2 release without AT&T code, but this was not a complete system. 386BSD reimplemented most of the missing parts and modern BSDs built on that work. tl;dr: while modern BSD does not contain AT&T UNIX code anymore, it evolved from AT&T UNIX. In contrast to Linux, it was not a clean-room implementation.
  - rat87 11y ago
    It's a ship of theseus. If you replace the whole things step by step, each step a small one, is it still the same thing or isn't it?
    - danieldk 11y ago
      The point is that it is not a clone of UNIX, it's one of the evolutionary strains of UNIX. You probably won't find substantial amounts of AT&T Research UNIX in Solaris, but it's still UNIX. The lineages of BSD and Solaris can be traced back directly to AT&T Research UNIX.
      - abiox 11y ago