5 ms·

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 a

by im3w1l 3y ago

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.

dgfitz 3y ago
> 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?
- e12e 3y ago
  This? https://manpages.org/git-restore-mtime https://manpages.org/git-restore-mtime
  - dgfitz 3y ago
    Sure. Are you trying to imply the existence of a manpage means something ubiquitous?
    - e12e 3y ago
      I was wondering if “got-restore-mtime" was a typo or a cleverly named similar project to “git-restore-mtime".
- im3w1l 3y ago
  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.