Autoconf makes me think we stopped evolving too soon • Hacker News Board

Re: Autoconf makes me think we stopped evolving too soon

#111

Post by czarit » Thu, Apr 04, 2024, 7:33 AM UTC

forrestthewoods wrote: post #85

marcus_holmes wrote: post #44

Earlier quoted context omitted.

Ahh the eternal cycle of static vs dynamic linking swings around again. "I need common.lib, it gets linked into my application at compile-time" "why does every binary include this common.lib code? Let's pull that out to a shared module so we only have one version of it! See? that saved 35739475749Kb of storage! Everything is smaller and sleeker now!" "which version of common.lib does this application need? Hmm, but t…

> Ahh the eternal cycle of static vs dynamic linking swings around again. Somewhat. Although it's agnostic to static vs dynamic linking. The philosophy goes a bit deeper than that. > See? that saved 35739475749Kb of storage! Storage capacity hasn't been relevant for over a decade. Besides, we foolishly replaced "use shared modules to save storage space" with "build multi-gigabyte docker images because it's the only w…

> Storage capacity hasn't been relevant for over a decade.

The Linux installs that run your Pi, router, toaster, security camera and toothbrush begs to differ.

Re: Autoconf makes me think we stopped evolving too soon

#112

Post by foul » Thu, Apr 04, 2024, 7:35 AM UTC

_jackdk_ wrote: post #67

jonstewart wrote: post #10

Earlier quoted context omitted.

I use autotools for my C++ projects and I hate it (in my weak defense, I hate cmake more). config.cache helps (and ccache helps a lot, too; most of my ccache hits are on stupid autoconf test programs; ya gotta use ccache if you use autoconf), but rerunning configure is still s l o w. Worse, automake and autoconf have a cyclic dependency, so if you're a developer (as opposed to a user building from source on a system)…

> If you add a new source file, you must rerun autoreconf to regenerate your Makefile No you don't: automake generates rules for `Makefile.am -> Makefile.in` (`automake`) and `Makefile.in -> Makefile` (`config.status`). You should just be able to edit `Makefile.am` and run `make`. > Is it really less effort to write Makefile.am than to write a straight Makefile? Wouldn't that be simpler? I don't think so. Not if you…

>I don't think so. Not if you want to get DESTDIR support right, and proper dependency tracking (dep info as a side-effect of compilation, so you get all the headers and don't slow down one-off builds), and support for all the standard Makefile targets, etc.

With any make, yes. With modern GNU make you can embed sh code inside a makefile with the define hack, so no, ugly, but no.

Re: Autoconf makes me think we stopped evolving too soon

#113

Post by mid-kid » Thu, Apr 04, 2024, 8:18 AM UTC

dima55 wrote: post #95

Too wrote: post #80

Earlier quoted context omitted.

Makefiles are too brittle and allow all kinds of user errors. Targets with too many dependencies, too few dependencies, race conditions. The default doesn’t even handle transitive #include dependencies without you yourself plugging in complex .d-file generation using the compiler.

Are they though? The "complex .d-file generation" is "gcc -MMD" and a "-include *.d" at the end of the Makefile. You specify the dependencies, and it's on you to get those right, as it is in every other build system. I've never seen a race condition. The problem with Make, is that it works just well-enough to allow people to sorta get it to work without requiring them to learn how to actually use the thing. Then they…

Nice job, you just hit a footgun: try to remove any .h file (and the corresponding #include directive) and see your build just break. You need an empty `%.h: ;` directive for make to ignore missing .h files.

Make is full of this stuff and as a distro packager having to deal with each's individual quirks is prone to drive one insane. Please consider using meson, at least.

Re: Autoconf makes me think we stopped evolving too soon

#114

Post by octachron » Thu, Apr 04, 2024, 8:43 AM UTC

chubot wrote: post #8

smackeyacky wrote: post #6

Earlier quoted context omitted.

If you're building something really portable, you still need autoconf. Anything that has to run on a BSD or a Mac needs these tools. The article comes across as a bit of "blame the tools" where the tools aren't really at fault, it's the culture which has failed here. We seem to have never graduated from "wow it actually works" levels of Linux appreciation that isn't that different from the 1990s. Those distributions…

Anything that has to run on a BSD or a Mac needs these tools Do QEMU, tcc, and OCaml run on BSD and Mac? Pretty sure they do https://news.ycombinator.com/item?id=39925033 https://github.com/lucasaiu/ocaml/blob/master/configure They have hand-written configure scripts, and don't use autoconf. --- Also, https://www.oilshell.org/ runs on BSD and Mac, and it doesn't use autoconf. The configure script is a few hundred lin…

Note that OCaml has been using autoconf since OCaml 4.09.

Re: Autoconf makes me think we stopped evolving too soon

#115

Post by bitwize » Thu, Apr 04, 2024, 8:55 AM UTC

yau8edq12i wrote: post #99

forrestthewoods wrote: post #85

Earlier quoted context omitted.

> Ahh the eternal cycle of static vs dynamic linking swings around again. Somewhat. Although it's agnostic to static vs dynamic linking. The philosophy goes a bit deeper than that. > See? that saved 35739475749Kb of storage! Storage capacity hasn't been relevant for over a decade. Besides, we foolishly replaced "use shared modules to save storage space" with "build multi-gigabyte docker images because it's the only w…

> Storage capacity hasn't been relevant for over a decade. Bullshit. It's especially visible with games. I cannot install more than 3-4 big games on my 512GB drive because apparently all game developers believe that "storage capacity isn't relevant".

Storage is cheap. Buy a bigger drive.

Re: Autoconf makes me think we stopped evolving too soon

#116

Post by bitwize » Thu, Apr 04, 2024, 9:08 AM UTC

Autotools, for all its ugliness, solved a critical problem: getting GNU software up and going on a variety of Unix systems each of which supported a different mix of features.

But it's 2024, people. If you port to Linux, macOS, and Windows, that's cross-platform enough to capture 99% of your userbase, and everything after that is diminishing returns. Still running DEC Ultrix on Alpha, a CPU architecture that's been out of manufacture for literal decades? Maintain the support yourself if it's so important.

In conclusion, use cmake or Meson. Let autotools die. Kill them if you have to.

Re: Autoconf makes me think we stopped evolving too soon

#117

Post by phoe-krk » Thu, Apr 04, 2024, 10:01 AM UTC

chubot wrote: post #52

nabla9 wrote: post #36

Earlier quoted context omitted.

Alan Perlis Epigram #9: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." Unix settled for string as a data structure and it's little too low level. All Lisp programmers know that s-expressions would have been the right choice. JSON works also.

Yup, I call that the Perlis-Thompson Principle -- because Ken Thompson made a similar combinatorial argument about software composition: you should design it around "one thing". https://www.oilshell.org/blog/2021/07/blog-backlog-1.html#co... Files had structure on pre-Unix OSes, but they don't on Unix, because it doesn't compose. The "Uniform Interface Constraint" of REST is the same thing, and resembles a file syste…

> What about a Clojure program and a Common Lisp program? Probably a byte stream. (Ironically, S-expressions have no commonly used "exterior" interchange format)

Probably because the details of S-expressions differ underneath the hood - a simple (foo ()) can mean a different thing on CL (where the second element is the symbol NIL) than on Scheme (where it is an empty list and not a symbol); also because Clojure introduces additional bracketing patterns, such as [] for arrays and {} for maps, which will confuse non-Clojures. And let's not talk about sexp variants of Lisp-Flavored Erlang.

Also, if you squint hard enough, https://en.wikipedia.org/wiki/Canonical_S-expressions works.

Also I have no idea if anyone ever cared enough to implement cross-language software transactional memory that would work across a process boundary, to close the gap between a Clojure process and a Lisp process. It could work in theory, but someone would need to do it - either get paid to do it, or have enough mojo of their own to write and bulletprove such a thing.

And, since everyone serializes to JSON anyway, serializing to JSON is a decent enough choice for communicating across Lisps as well.

Re: Autoconf makes me think we stopped evolving too soon

#118

Post by donatj » Thu, Apr 04, 2024, 1:21 PM UTC

bandrami wrote: post #70

Younger people may not remember one of the early alternatives, libiberty (now at least somewhat improved as gnulib), but as an idea it was even worse : if your system doesn't provide a GNU compatible function call, it wrote one that hijacked whatever your system did have. It's still bumbling around there in the internals of gcc, silently patching every system it builds on.

Maybe I'm crazy but that sounds like a huge improvement.

Re: Autoconf makes me think we stopped evolving too soon

#119

Post by sevensor » Thu, Apr 04, 2024, 1:29 PM UTC

nabla9 wrote: post #36

titzer wrote: post #32

Autoconf is one of the absolutely hilarious things about UNIX. On the one hand, we've got people optimizing kernels down to the individual instructions (often doing very unsafe dirty C tricks underneath), sometimes with super-clunky and overly complex APIs as a result...and on the other hand you have all the shell script absolute nuttery like the behemoth heap of kludges that is autoconf. It's crazy to me the disconn…

Alan Perlis Epigram #9: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." Unix settled for string as a data structure and it's little too low level. All Lisp programmers know that s-expressions would have been the right choice. JSON works also.

What's worse, with autotools, is that while maybe only one programmer in 100 knows how to do ./configure; make; make install, only one in 10,000 knows m4. It's one of those odd corners of the ecosystem like troff. It would be very easy to slip by me an exploit written in m4, or troff for that matter, because I've never paid any attention to either.

Re: Autoconf makes me think we stopped evolving too soon

#120

Post by mediumsmart » Thu, Apr 04, 2024, 1:39 PM UTC

I am so grateful and happy I only have to write little programs for this one machine that only I run. Free cookies, fortune and fame for the real programmers who made this possible

The sendmail configuration file is one of those files that looks like someone beat their head on the keyboard. After working with it... I can see why! -- Harry Skelton