Standard invocation of ./bootstrap

[Ryan Carsten Schmidt]

On Aug 8, 2026, at 00:00, Seth McDonald wrote:
> 
> Is there a standard or preferred way for portfiles to invoke ./bootstrap
> for ports that require it to build?  Searching the macports-ports GitHub
> repo, I've found the following methods portfiles use to run the script.
> 
> (0)
>    configure.cmd ./bootstrap
> or
>    configure.cmd ./bootstrap && ./configure
> or
>    build.cmd ./bootstrap
> 
> (1)
>    use_autoconf yes
>    autoconf.cmd ./bootstrap
> or
>    use_autoreconf yes
>    autoreconf.cmd ./bootstrap
> or
>    use_automake yes
>    automake.cmd ./bootstrap
> 
> (2)
>    pre-configure {
>        system -W ${worksrcpath} "./bootstrap"
>    }
> or
>    pre-configure {
>        system -W ${worksrcpath} "sh ./bootstrap"
>    }
> 
> Methods (0) and (1) feel quite hacky, but (2) feels slightly more
> complex than what should be necessary.

The bootstrap script (often called autogen.sh although that name is no longer recommended) typically generates the configure script, by running autoreconf or other commands, so I prefer the variant of (1) that sets use_autoreconf yes and autoreconf.cmd. 

This enables you to easily set autoreconf.env if you need to pass environment variables to the script and/or autoreconf.args if you want to pass it arguments. 

MacPorts by default supplies arguments to autoreconf (and autoconf) which are not appropriate for another script, so you will want to clear autoreconf.args (or autoconf.args) if you have no other values you want to supply.

MacPorts by default adds dependencies on autoconf, automake, and libtool when you set use_autoreconf yes (or use_autoconf yes), but removes those dependencies if you change autoreconf.cmd (or autoconf.cmd) so be sure to re-add the dependencies and be sure to do it after you set the cmd, not before. 

Some bootstrap or autogen.sh scripts automatically run the configure script afterward. In this case, using configure.cmd ./bootstrap as in (0) makes sense. Or, if the script accepts an arg or env var to tell it not to run the configure script afterward, you could choose to do that and leave configure.cmd alone. 

Manually running commands via system as in (2) is usually not recommended because of the increased difficulty of correctly passing custom env vars or args and the fact that MacPorts will not supply default env vars.