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

91–100 of 169 posts

Re: Autoconf makes me think we stopped evolving too soon

#91

Post by Scarblac »

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.

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.

Re: Autoconf makes me think we stopped evolving too soon

#92

Post by dilyevsky »

pianoben wrote: post #73
dilyevsky wrote: post #45

Earlier quoted context omitted.

> Bazel's obviously a terrible Google project and won't work if you're not sufficiently Googly I don’t even know what that means, sounds like a bunch of fud to me. C++ and Java are first-class languages in Bazel. It works great for these, then Go, then you start venturing into the alpha land

Works great if you follow Google's style of vendoring all of your dependencies. If you try to rely on third-party package managers like Maven or Ivy or whatever C++ uses, you're in for some serious pain. The more you venture into OSS tools like Spring, gRPC, containers, the more you have to incorporate shoddy and poorly-maintained third-party Bazel tools which inevitable stomp on each other in subtle ways. My team ab…

> Works great if you follow Google's style of vendoring all of your dependencies. If you try to rely on third-party package managers like Maven or Ivy or whatever C++ uses, you're in for some serious pain.

It sounds like you've mainly dealt with Java because it's not a pain in C/C++ - if you wish you can link dynamically with system libs or vendor .so binaries. And at least for Maven I used rules_jvm_external which worked fine.

I’ll grant that container rules were a mess for a long time but new oci rules are much improved.

> My team abandoned Bazel for Gradle, and it has been a tremendous quality-of-life improvement.

I hear as much if not more gripes about gradle of the same variety - "hurr durr it sucks bc i don't like it". Personally I'm thinking this is more appropriate critique for an art piece not a build system.

Re: Autoconf makes me think we stopped evolving too soon

#93

Post by lelanthran »

forrestthewoods wrote: post #17
chubot wrote: post #7

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/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, beca…

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

Okay, what's the alternative when `accept` has three parameters when using glibc and two parameters when using musl?[1]

How else do you determine which one to use other than by compiling against the chosen library and seeing what fails?

[1] just an example, musl mighy actually have same amount of parameters as glibc for all I know. But newlib doesn't.

Re: Autoconf makes me think we stopped evolving too soon

#94

Post by darnir »

db48x wrote: post #28
thechao wrote: post #13

Earlier quoted context omitted.

I'm be written lots of C code that runs on lots of architectures & platforms: PDPs, x86, ARM; Windows, BSD, Linux, VMS. My projects have spanned them gamut from tiny to gargantuan (millions of lines of code). I've never needed autoconf... what's it even for !?

In decades past, if you were developing software for Unix you would inevitably run across compatibility problems. Even with the POSIX standard, every Unix was trying new things, inventing new things, or just implementing the same thing in slightly different ways. So your programs had to have a bunch of macros to switch between different variations. Some API would have two arguments on Unix A but three on Unix B, so y…

That's a very nice summary. But you're missing one crucial point. These are GNU tools and if you use them within that ecosystem, you also often use gnulib.

Gnulib is effectively the GNU Portability Library. Your fancy, new, auto generated configure script can find all the differences, but someone still needs to account for them and write alternative code to support the various platforms. This is where gnulib comes into play. It reads all the configure checks and plugs in replacements / stubs for whatever is different. This allows you, the developer to simply target GNU/Linux in your code while gnulib handles everything else (and pretty automatically) making is portable across all the unices and even non UNIX systems.

Re: Autoconf makes me think we stopped evolving too soon

#95

Post by dima55 »

Too wrote: post #80
bee_rider wrote: post #74

Earlier quoted context omitted.

We should just write Makefiles. If you want to be really nice, have it source a Makefile.inc file and keep all the user configuration stuff in there. If you want to be really really nice, consider accepting pull requests for .inc files that work with popular distros.

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 don't read the manual, and complain that Make doesn't, in fact, work.

Re: Autoconf makes me think we stopped evolving too soon

#96

Post by dima55 »

cout wrote: post #89
bee_rider wrote: post #74

Earlier quoted context omitted.

We should just write Makefiles. If you want to be really nice, have it source a Makefile.inc file and keep all the user configuration stuff in there. If you want to be really really nice, consider accepting pull requests for .inc files that work with popular distros.

I just write (gnu) makefiles for my projects these days and invoke pkg-config to detect libraries and features. It's easy for me because I've been doing it this way for decades. But there are way too many footguns for me to recommend it to new developers (although I'm not sure what I would recommend instead either).

I think Make is exactly what you want, and I do recommend it to everybody, since the default alternative is usually something heinous like CMake which isn't really an improvement. You want the bit of logic to create a "build system" out of Make abstracted into a library, and then it's perfect. I use this: https://github.com/dkogan/mrbuild/ but there're many other ways to do it

Re: Autoconf makes me think we stopped evolving too soon

#97

Post by dima55 »

ndiddy wrote: post #83
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)…

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…

Rather than the "killer app", that's the only thing that cmake does better than other systems, and the only reason for anybody to use cmake.

Re: Autoconf makes me think we stopped evolving too soon

#98

Post by parasti »

Autoconf has never really made sense to me in the last twenty years or so. At what point does a Makefile-based project start thinking "hmm, we should upgrade to autoconf to solve this"? And what is "this" that they can't solve any other way? Seems like that point never occurs anymore. Either projects start with autoconf or they don't.

Re: Autoconf makes me think we stopped evolving too soon

#99

Post by yau8edq12i »

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.

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

Re: Autoconf makes me think we stopped evolving too soon

#100

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.

Post reply on HN