Hacker News Reader

Comment by NelsonMinar | Hacker News Reader

Autoconf, that's the thing that spends time making sure that my software can be built on BeOS and A/UX?

I have a vivid memory of autoconf. I set it up best as I could. Someone ran ./configure. It triggered a new run of autoconf that failed because of mismatching autoconf version. Why it triggered a new run? Because of mtime checks. Why did they say it needed to be rerun? Because git doesn't preserve mtime. I guess it's just assumed that everyone distributes their sources as a tarball. I spent many hours trying to figure out how to bypass those issues, and I can't remember if I ever succeeded.

These days I just use Rust instead.

> I spent many hours trying to figure out how to bypass those issues, and I can't remember if I ever succeeded.

Might I suggest “got-restore-mtime” for this, upstream in Debian and Ubuntu already.

Did you really spend hours on this?

This?

https://manpages.org/git-restore-mtime

Sure. Are you trying to imply the existence of a manpage means something ubiquitous?

I was wondering if “got-restore-mtime" was a typo or a cleverly named similar project to “git-restore-mtime".

Well I wanted to create an easy and familiar process for people installing from source, so I wanted it to be roughly git pull && ./configure && make && sudo make install. So I didn't consider restoring mtimes into that flow, just looked for options for autoconf to not regen.

Also I think it took quite a while to even realize the mtimes were the issue from an error messages, as I was not very knowledgeable about autoconf / automake.

More like some obscure pre-c89 stuff. But it takes actual work and testing to get that working, so most people have a configure script that checks for all that stuff but when it's time to compile it only actually works on their specific Linux distro.

autoconf's principal purpose is to waste time.

Reply on news.ycombinator.com