patch #10416: Drop unreliable dependency on which program, publicize settable variables in --help
#291
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It accepts a filename, not a directory name, so say that.
…H_PROG The "which" utility is not guaranteed to be installed either, and if it is, its behavior is not portable either. This means that when llvm-config is installed, the `which` check will report a fatal error because the which tool did not exist and the shell returned a nonzero status when attempting to fork+exec. If it did exist, it might not be an implementation of `which` that returns nonzero when commands do not exist. The general scripting suggestion is to use the "command -v" shell builtin is required to exist in all POSIX 2008 compliant shells, and is thus guaranteed to work everywhere. For some in-depth discussions on the topic, see: - https://mywiki.wooledge.org/BashFAQ/081 - https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250 Examples of open-source shells likely to be installed as /bin/sh on Linux, which implement the 15-year-old standard: ash, bash, busybox, dash, ksh, mksh and zsh. Since this is an autoconf extension, however, autoconf provides its own guarantees: you are always supposed to use AC_PATH_PROG, which is guaranteed to generate code which does the right thing, and in particular tends to work even on systems which predate POSIX. It officially becomes autoconf's job to make sure path detection works. This has some convenient knock-on effects. In particular, we now permit users to specify the path via $LLVM_CONFIG, which is a somewhat standard approach, and we document it as well.
Fallout from commit c765658. Using shell quotes around autoconf macro parameters leads to literal double-quote chars appearing in ./configure --help output, in this case.
…PATH_PROG The "which" utility is not guaranteed to be installed either, and if it is, its behavior is not portable either. This means that when Qt is installed, the `which` check will report a fatal error because the which tool did not exist and the shell returned a nonzero status when attempting to fork+exec. If it did exist, it might not be an implementation of `which` that returns nonzero when commands do not exist. The general scripting suggestion is to use the "command -v" shell builtin is required to exist in all POSIX 2008 compliant shells, and is thus guaranteed to work everywhere. For some in-depth discussions on the topic, see: - https://mywiki.wooledge.org/BashFAQ/081 - https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250 Examples of open-source shells likely to be installed as /bin/sh on Linux, which implement the 15-year-old standard: ash, bash, busybox, dash, ksh, mksh and zsh. Since this is an autoconf extension, however, autoconf provides its own guarantees: you are always supposed to use AC_PATH_PROG, which is guaranteed to generate code which does the right thing, and in particular tends to work even on systems which predate POSIX. It officially becomes autoconf's job to make sure path detection works. This has some convenient knock-on effects. In particular, we now permit users to specify the path via $QT_* variables, which are documented inline as being set and are now documented as publicly settable too. This was even already the case with qmake.
``` /usr/lib/python3.11/subprocess.py:1016: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://savannah.gnu.org/patch/index.php?10416