fix: avoid autotools regeneration when building bundled libuv

[Copilot]

CRAN r-devel-macos-arm64 is failing to install httpuv because the bundled libuv build conditionally runs autoupdate/autogen.sh when automake is present, even if the rest of the autotools toolchain is missing or version-mismatched. The vendored libuv sources already include the generated autotools artifacts needed at build time, so regeneration is both unnecessary and fragile.

• Root cause

  • src/Makevars.in treated automake on PATH as a signal to fully regenerate libuv build files.
  • On some builders, that branch fails inside autogen.sh due to missing companion tools (glibtoolize, matching aclocal, etc.).

• Change

  • Remove the automake detection branch from src/Makevars.in.
  • Always use the existing timestamp normalization path before running ./configure.

• Effect

  • Build-time libuv compilation now consistently uses the checked-in configure, Makefile.in, and aclocal.m4.
  • This preserves the intended vendored-dependency workflow and avoids accidental autotools regeneration on end-user or CRAN machines.

• Updated build flow

  cd libuv; \
  touch aclocal.m4; \
  touch -r aclocal.m4 configure Makefile.in; \
  chmod +x configure; \
  ./configure $(CONFIGURE_FLAGS)

• Why this is the right scope

  • The change only affects the bundled-libuv build path.
  • It aligns Makevars.in with the documented libuv update flow: generate autotools files when updating the vendored source, not when installing the package.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}