configure --enable-debug sub options cannot be overridden
#24416
Comments
|
part of #8058 |
bors
added a commit
that referenced
this issue
Jul 21, 2015
fix `configure`: allow both `--enable-debug` and `--disable-debuginfo` in one invocation. This is my very local fix to allow one to be able to (1.) build `rustc` and (2.) run `make check` with internal debug-mode *assertions* turned on in the presence of bugs like #26447 and #26484 (both of which are solely caused by debuginfo and thus can be sidestepped via `--disable-debuginfo`). This partially addresses #24416 (namely, it addresses the papercut outlined in the description of that ticket). But there are other issues mentioned in the comment thread that are not addressed here, so they should be separately addressed before closing that ticket, or separate bugs should be opened for them.
|
I believe this issue is also causing Since the script interface is modeled after autoconf (same script name and argument forms) having different argument processing behavior than autoconf (where later options override earlier ones) is surprising. |
|
I believe this has now been fixed with # =============================================================================
# Tweaking how LLVM is compiled
# =============================================================================
[llvm]
# Indicates whether the LLVM build is a Release or Debug build
#optimize = true
# Indicates whether an LLVM Release build should include debug info
#release-debuginfo = false
# Indicates whether the LLVM assertions are enabled or not
#assertions = falsenow all available separately. Closing! let me know if that's wrong. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Spawned off of #24405.
configure --enable-debugwill enableCFG_ENABLE_LLVM_ASSERTIONS,CFG_ENABLE_DEBUG_ASSERTIONS,CFG_ENABLE_DEBUG_JEMALLOC,and there is no way to turn them off.
The options
--disable-{llvm-assertions,debug-assertions,debug-jemalloc}will all be silently ignored.An analogous approach to that used by #24408 would probably work here.
But it might be better still to revisit how we are handling the option parsing in
configurehere, (for example, an invocation likeconfigure --enable-debug --disable-debughas many potential interpretations, including emitting an error outright, but you might be surprised which one we choose under the current configure implementation). The strategy of "ignore arguments that already match the default" seems like a big pitfall in the script.The text was updated successfully, but these errors were encountered: