Ryan Schmidt ryandesign at
Mon Dec 25 22:07:29 UTC 2017

On Dec 25, 2017, at 12:38, Mojca Miklavec wrote:

> On 23 December 2017 at 16:38, Ryan Schmidt wrote:
>> Should we add a "use_autogen" (or "use_autogen_sh") option to MacPorts base?
> What about (This is one I would need at the moment,
> but it's only used in 9 other ports rather than 200.)
> I support the idea except that the list could get much much longer and
> doesn't seem to scale too much in the sense that we can end up with a
> potentially "infinite" list of commands. In that sense I prefer the
> idea of explicitly setting autoconf.cmd.
> What I don't like is that this removes the dependencies without any
> option to enforce keeping the dependencies.
> If the port needs something completely different from autotools, we
> could add a different command like "use_<somethingelse>" (I'm not sure
> what that name should be, but I assume it would allow the port to set
> any command that is being run before configure) and make sure not to
> reset dependencies for those ports that do specify use_autoconf.
>> We already have "use_autoconf", "use_automake" and "use_autoreconf". Each of these add the autoconf, automake, libtool dependencies, and set up the right command to run before the configure phase.
>> But many projects now include an script that should be run instead. The contents of the script is not standardized but at least the name is. I count over 200 portfiles mentioning
> ... that said, I still like consistency much more, so I wouldn't be
> strongly opposed to having another commend like use_autogen if others
> don't agree with the idea mentioned above.

Yeah I think probably we should not be removing the dependencies if the .cmd is changed. That was probably an idea that doesn't turn out to be really useful. Here's all of the values that ports are currently changing a .cmd to:

$ port file all|sort -u|xargs sed -E -n 's/^[[:space:]]*(autoconf|automake|autoreconf|xmkmf)\.cmd[[:space:]]+//p'|sort|uniq -c
   1 "build/"
   1 ${autoreconf.dir}/s_config
   1 ${worksrcpath}/
  21 ./
   5 ./bootstrap
   4 autoconf213
   1 autoreconf
   1 make autoconf

I haven't checked the 5 bootstrap scripts but it looks like most if not all of these are using autotools and do need the dependencies, so it's counterproductive for MacPorts to remove them.

The few autoconf213 ports could just as easily do "depends_build-replace port:autoconf port:autoconf213".

We could introduce a new "use_something" that does not add autotools dependencies, for ports that want to run a non-autotools-related pre-configure script. But it looks like we don't have any ports using that now, and it's probably ok to just ask those ports to call "system" in a pre-configure block. Many are probably already doing that.

For we could continue to use "autoreconf.cmd ./". But I think the idea was that we should have options for common use cases. That was why "use_autoreconf" was introduced--so that we wouldn't have to keep writing "autoconf.cmd ${prefix}/bin/autoreconf". And since is becoming so popular at this point I'm still leaning toward adding "use_autogen", even if use_autoconf, use_automake, use_autoreconf and use_autogen do very similar things.

One difference would be the default args. The default args MacPorts specifies for autoreconf aren't appropriate for an or bootstrap script. They don't harm most scripts since most scripts won't look for them, but it's still not right for MacPorts to be specifying them to scripts. See

I was going to say we should not have a separate "use_bootstrap" due to its lack of popularity, but to my surprise I see that GNU recommends using a "bootstrap" script instead of an "" script so now I don't know what we should do:

Either we add "use_bootstrap" and make all the ports set "bootstrap.cmd ./" (this is what we should do if we follow GNU recommendations but would mean more ports would have to override the .cmd), or we add "use_autogen" and make the bootstrap ports set "autogen.cmd ./bootstrap".

More information about the macports-dev mailing list