Bugzilla – Bug 622
Updates to Autoconf infrastructure
Last modified: 2013-11-16 01:52:42 MST
Created attachment 379 [details] Patch against sudo hg tip In the course of working on Sudo vis-a-vis HP-UX and Tru64, I found some issues with the configure script and related files that are addressed in the attached patch. * aclocal.m4 is not a good place to maintain local M4 macros (like SUDO_PROG_SENDMAIL), because this is usually a generated file---see the aclocal(1) tool bundled with Automake---and thus is not immediately obvious as a proper hand-edited source file. This is better kept alongside other macro files in the AC_CONFIG_MACRO_DIR, so I renamed it to m4/sudo.m4. Note: There are file changes in aclocal.m4 -> sudo.m4 in addition to the rename, too. * configure.in and sudo.m4 have been run through autoupdate(1) (and subsequently hand-tuned to restore formatting), so warnings about obsolete macro usage (e.g. AC_TRY_RUN) are gone. * Numerous #include directives in Autoconf test program sources were not formatted so that the "#" mark is placed correctly in the first column. * sudo.m4 no longer needs the m4_include bits at the end. * I've included an autogen.sh script to facilitate regeneration of the build system. It's typical to have this at the top of a version-control tree---even though Sudo includes the generated Autoconf files in the repository, and thus most users don't need to do the bootstrapping themselves, they'll still want an easy way to do so when they hack the build system (*wink*).
Since I am not using automake (and have absolutely no plans to do so) I still need the m4_include calls. They can be at the top of configure.in though. With that change I am able to use your autogen.sh
There's "using Automake" in the sense of having aclocal(1) (a tool bundled with Automake) generate aclocal.m4, and then there's "*using* Automake" as in Makefile.am files everywhere. The former can be done without the latter---would that work for you? (That way, the m4_includes are generated automatically in aclocal.m4 and don't need to be maintained. Plus, you can rely on autoreconf(1), which invokes aclocal(1) anyway.)
Now I understand. I suppose it is fine to just use aclocal if this makes things easier on people who want to re-gen autofoo. I've committed your changes and also renamed configure.in -> configure.ac and regenerated configure with autoconf 2.69.
Created attachment 382 [details] Follow-up patch against sudo hg tip Looks great! Renaming configure.in makes the whole setup even more up-to-date. This patch addresses the remaining #includes in the configure script.
I've applied the follow-up patch. Thanks!
All set here.