selfupdate: Use standard_configure.sh

[ryandesign]

This makes the MacPorts base you get after selfupdate more similar to the MacPorts you get after using the binary installer.

standard_configure.sh enforces a PATH that does not contain the MacPorts prefix, so there's no longer a need to set CC to guard against a compiler in the MacPorts prefix.

standard_configure.sh defaults to enabling readline, so add a flag to disable readline when needed.

[raimue]

The configure script already removes the given prefix from PATH. The CC=... must have been added for unrelated reasons.

This means we are bound to support ./standard_configure.sh forever to allow upgrades. Do we want that?

If ./standard_configure.sh should always be run instead of ./configure, why do we keep it in a separate script instead of moving everything it does into configure? (We could even keep it as a wrapper if we rename configure.ac or move it to a subdirectory.)

[jmroot]

The configure script already removes the given prefix from PATH. The CC=... must have been added for unrelated reasons.

https://trac.macports.org/ticket/23095 https://trac.macports.org/ticket/30009#comment:1

[ryandesign]

The configure script already removes the given prefix from PATH.

I didn't know/remember it did that, but indeed that's been there a long time, since 2e689647a03d131ebfee89888108234e8c4e37de.

The CC=... must have been added for unrelated reasons.

It was added because I asked for it, assuming that a gcc in the user's configured binpath might be found instead of the compiler we want. That still allows for a gcc in other custom entries of binpath to be found, though it is unusual for the user to customize binpath. Setting PATH to a known-good value eliminates all possibility of the wrong compiler being found, which is what standard_configure.sh does.

This means we are bound to support ./standard_configure.sh forever to allow upgrades. Do we want that?

It does mean that—perhaps not forever, but for a long time. I didn't consider that to be a huge problem. If one day we move all of the functionality of standard_configure.sh to configure then standard_configure.sh can become a simple wrapper that calls configure.

If ./standard_configure.sh should always be run instead of ./configure, why do we keep it in a separate script instead of moving everything it does into configure? (We could even keep it as a wrapper if we rename configure.ac or move it to a subdirectory.)

standard_configure.sh does three things, two of which we previously decided we did not want the configure script to do:

1. Uses PATH=/usr/bin:/bin:/usr/sbin:/sbin because we wanted a known-good path for finding the compilers and libraries. We didn't want the configure script to find libraries in /usr/local, for example. We previously tried moving this PATH-clearing code to the configure script but it was reverted because setting a custom PATH was thought to be important for custom builds. It was this commit that introduced the standard_configure.sh script.
2. Uses --enable-readline. We disabled readline in the configure script by default in 18403544dc44fcb8b84c265b25fb734df79b4049. The reason may have been that many users had a copy of GNU readline installed in /usr/local, with which I don't think MacPorts is compatible. We're only compatible with the readline Apple ships in macOS, which isn't readline at all but editline, a.k.a. libedit. So we only used --enable-readline in situations where we could be sure that /usr/local/bin was not in the user's PATH so that that readline wouldn't be found. I tried building MacPorts base with --enable-readline while the MacPorts prefix was in PATH and the readline port was installed, and it failed with readline.c:128:23: error: use of undeclared identifier 'username_completion_function'; did you mean 'rl_username_completion_function'?.
3. Uses CFLAGS="-pipe -Os" because that's how MacPorts builds ports, including the MacPorts port that's currently used to build our installers. I don't think we've discussed moving that functionality into the configure script but I suppose we could.

My proposal in #86 moves the rest of the configure-phase functionality of the MacPorts port into standard_configure.sh.

Perhaps we need to consider at this point the problem that selfupdate does not use the original configure parameters. If we want to support MacPorts installs that use non-default configure args or env vars, we should remember those settings for use when selfupdating. And if we do that, then moving more of our preferred build functionality into the configure script seems more acceptable.

[ryandesign]

If we want to support MacPorts installs that use non-default configure args or env vars, we should remember those settings for use when selfupdating. And if we do that, then moving more of our preferred build functionality into the configure script seems more acceptable

And if we do that, there's no need for making selfupdate use standard_configure.sh.

[mojca]

Ping?

[kencu]

The extra configure args that were used on the command line to initially configure macports, if any, are recorded temporarily in config.status during the initial configuration and build. To maintain them, extract them from that file and save them in the installed prefix, to be used during later selfupdates.