So, looking at closely at the autoconf package, it seems autoreconf and autoheader (both written in perl), have this feature, for one or more of the ENV vars that I would expect.
Autoconf on the other hand, seems to only check for AUTO4MATE, a cursory check of aclocal shows it isn’t checking for any of these.
I’m trying to deconstruct how this “should” work, or determine what the intent was. (Hopefully, similar to what I’m after, but I’m not sure.).
Would appreciate any insight.
> On Jul 19, 2021, at 2:05 PM, Christopher O Cowan <Christopher.O.Cowan@xxxxxxx> wrote:
>
> Just curious if there is a feature within autotools to allow me run autoconf and similar utilities via an absolute path, without the autotools suite commands, in the PATH. Maybe this already exists, and I just haven’t stumbled across it?
>
> I am aware, that this probably on enforced by convention, and that each individual package developer could change this at will. And perhaps this is package/project specific. I ran into this with rsync, just for the record.
>
> I’m trying to do build on a platform where I’m trying to keep the footprint to the absolute minimum. Most of my GNU tools including, autotools, use a separate prefix (that is not /usr/local). I’m always worried that if I add the autotools, to my path, I have to thoroughly check for configure logs, for artifacts that I may not want in my builds. (Particularly with something like pkgconfig in the mix).
>
> I’m envisioning a feature where certain commands might be specified by explicitly via ENV vars, when I’m actually running autoconf or autoreconf.
> Such as, AUTOCONF, ACLOCAL, AUTOM4TE, AUTOMAKE, AUTOPOINT, LIBTOOL, LIBTOOLIZE, etc.. In my mind, it would be easy to replace occurrences of automake in the templates, with something like
> ${AUTOMAKE:-automake}, for example.
>
> I think this would allow a bit more control over the various build phases, including autogen and configure.
> It would also allow me to run different versions of autotools, as well.
>
> Regards,
> --
> Chris Cowan
