Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Autoconf makes me think we stopped evolving too soon

rachelbythebay.com

Post reply on HN
Print view View original

101–110 of 169 posts

Re: Autoconf makes me think we stopped evolving too soon

#101

Post by kergonath »

cout wrote: post #88
ndiddy wrote: post #83

Earlier quoted context omitted.

IMO Cmake's "killer app" is that it will generate projects for Visual Studio and Xcode, which allows you to get access to the Windows/Mac specific tooling that those products offer. It's also a LOT faster on Windows than Autotools because of how NTFS performs poorly when dealing with writing a ton of small files. I agree that its syntax is ugly but once I got beyond that I found it fairly simple to work with. The mos…

Honestly I think cmake got a foothold early on because it had color.

It also hides stuff so users look at simple, colourful lines with progress indicators instead of naked, overwhelming calls to the compiler.

That said, as a user I prefer autoconf. The semantics of --with-foo or --enable-bar are simple and well documented. And ./configure --help shows all the possibilities. Faffing around with -DCMAKE_STUFF is horrible. Ccmake should be nice but in practice never works properly.

As a developer, both autoconf and cmake are horrifying and a huge time sink to get them to behave.

Re: Autoconf makes me think we stopped evolving too soon

#102

Post by nindalf »

chubot wrote: post #55
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…

Shells have some of the absolutely bonkersly dumb parsers and interpreters Oils fixes all this, it's a from-scratch reimplementation of shell with an upgrade path from OSH (compatible) to YSH (new). --- aliases that can override keywords and change the parsing of shell script You can control this with shopt -u expand_aliases in bash, and YSH turns it off by default. Oils is statically parsed: How To Parse Shell Like…

I hope this can become the new standard shell. https://xkcd.com/927/

Re: Autoconf makes me think we stopped evolving too soon

#103

Post by wewxjfq »

pas wrote: post #71
wyldfire wrote: post #60

I'm finding myself in the unenviable position of defending autotools. > They were a reflection of the way the kernel, C libraries, APIs and userspace happened to work. Short of that changing, the results wouldn't change either. These things do change, especially as toolchain and OS vendors realize their quirks that cause portability friction.

there's absolutely nothing wrong with the functionality (it's essential in fact), it's that maybe, maybe, we should purge shell scripts from our hearts. (or at least reserve them for ad-hoc one-off in-situ time-conscious pragmatic programs, instead of letting a billion bash-lines beat its little shell-song behind every .deb,.rpm & etc.) // and of course 'should' is more like "it would be great if someone would rewrit…

Remember the serde_derive fiasco?

https://news.ycombinator.com/item?id=37205647

Re: Autoconf makes me think we stopped evolving too soon

#104

Post by matheusmoreira »

forrestthewoods wrote: post #20
BoomerMoment wrote: post #3

Portability. A test to get the answer to "what the fuck am I running on and what does it support" is more portable and robust than thousands of "flavours" manually configured in /etc/whatamieven.conf The author misses that the buildtime magic for the xz exploit is not in the m4 file but in an obfuscated, compressed, encrypted, binary disguised as a test file that alters the build process at multiple stages (configure…

configure is a mistake. Building a project shouldn’t generate input files that are dependent on the system state. That’s what C projects from the 90s do and it’s genuinely awful.

What is the alternative? Even if you're very organized and abstract away all the stuff into neat platform-specific modules, you'll still have those system-dependent inputs in the build system. No matter what happens it will still have to pick which of those modules to include in the build and it will most likely do so via some target variable whose default value is whatever it autodetects the host system as.

Re: Autoconf makes me think we stopped evolving too soon

#106

Post by pjmlp »

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…

The UNIX haters book happened for a reason, and sadly many of the complaints have hardly changed.

At least on cloud and mobile space, we have largely moved beyond that, in the age of serverless, managed containers and programming languages.

Smalltalk and Lisp based REPLs are just as programmable, even more so given the whole OS exposure, and is no wonder why Notebooks got adopted by the science community and are inspired by them.

Re: Autoconf makes me think we stopped evolving too soon

#107

Post by matheusmoreira »

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…

Note that quite a lot of these problems would just go away if people would just stop trying to conform to some "portable" POSIX nonsense. There's no reason why shell scripting needs to be this painful but people keep doing it to themselves by restricting themselves to the smallest possible subset of features, the most ancient ones at that. The so called "bashisms" for example make everything so much easier and less error prone but people act like it's wrong to use those features. When you read stuff about shell scripting there's usually an entire section on avoiding the evil bashisms and torturing the shell script until it runs in the mythical POSIX shell as if it was some kind of virtuous thing to do, like bash is pushing you into temptation or something.

Just throw POSIX into the trash where it belongs. Then we can finally evolve past it.

Also, shellcheck is a wonderful tool. The script isn't done until shellcheck stops complaining.

Re: Autoconf makes me think we stopped evolving too soon

#108

Post by vineyardmike »

Scarblac wrote: post #91
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.

IMO a big reason Python is popular is because so many big seemingly unrelated librarues (AI things, scipy, Pillow, pandas, GDAL rasters, matplotlib, etc) all work with the "Numpy array" datatype and can therefore do things with each other's data.

Relatedly, this is why big companies (eg Google) all have internal standard interchange formats (eg Protos). It’s so every programmer and every service and every file stored can always be consumed or produced as needed.

Even smaller companies I’ve seen end up with an “interfaces” or “types” repo that contains definitions of every external object.

Re: Autoconf makes me think we stopped evolving too soon

#109

Post by forrestthewoods »

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

Let me rephrase, storage capacity with respond to dynamic/shared libraries hasn't been relevant for over a decade.

AAA video games have massive storage requirements primarily due to textures, and sometimes audio. Which is a totally different conversation. It's not a bunch of redundant static libraries causing your pain.

$100 will get you an 8Tb spinning drive or a 1Tb SSD or possibly 2TB. You can also get an external SSD for the same price. Large game sizes is a real and annoying issue. But even 4 year old consoles launched with a 1Tb SSD.

Re: Autoconf makes me think we stopped evolving too soon

#110

Post by junon »

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

That is almost all assets and has almost nothing to do with static vs shared. In fact, making things shared usually makes them worse, because you miss out on WPLTO.
Post reply on HN