-
Notifications
You must be signed in to change notification settings - Fork 37.7k
build: Add --with-append-cxxflags option #22159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related discussion in #18892.
Note that -ftrivial-auto-var-init=zero
seems to be going away. If I use that with (Apple) Clang I see:
clang++ a.cpp -std=c++17 -ftrivial-auto-var-init=zero
clang: error: -ftrivial-auto-var-init=zero hasn't been enabled. Enable it at your own peril for benchmarking purpose only with -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
Tested this PR + my change, using -ftrivial-auto-var-init=uninitialized
.
Concept ACK Very nice to see! Let's kill the use of uninitialized memory (UUM) bug class! :) |
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsNo conflicts as of last run. |
I'm honestly not sure why this warrants adding another build system configuration flag. For new people buildng from source having so many options only vaguely related to bitcoin's application is confusing. Why not pass it in through Alternatively maybe we can group these kind of "warning: testing only" options together and have a single option. But I don't like having a separate one for it. |
I agree that it is stupid to wrap each compiler option into a config option. While using CXXFLAGS is certainly possible, it is not straightforward, because it comes with some unexpected downsides, like disabling Compare the default CXXFLAGS:
CXXFLAGS with "pattern":
|
I slightly misunderstood the intent when first reviewing, and agree with @laanwj here. Adding a new configuration option just to turn on a single compiler option is overkill. If it's not possible to achieve what you'd like, without downsides, when using CXXFLAGS, that seems like something we need to fix. |
Agree, if CXXFLAGS as a mechanism to pass arbitrary options in is broken, that's what we need to fix. Alternatively, if that is not possible, to add a method to pass arbitrary options that actually works. Wrapping every option in its own configure option is a no-go. |
fadbe02
to
faac838
Compare
Tried to addressed feedback |
Github-Pull: bitcoin#22159 Rebased-From: faac838
faac838
to
fa14c68
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
Seems the motivation is to add CXXFLAGS without losing whatever default flags autotools gave us previously. I probably won't use it, but it seems harmless and possibly useful to others, so why not?
cr ACK fa14c68 Nice not having to repeat the defaults. Nice not having to repeat the defaults. |
But if we start doing this for cxxflags, where does it stop. I still disagree with this, it's a non-standard convention, It saves so little effort. But whatever if everyone else thinks it is a good idea. |
Yeah, it would be nice if build systems were a bit more user friendly. I guess I'll just keep typing "-g -O2" every time. |
Github-Pull: bitcoin#22159 Rebased-From: fa14c68
This can be useful for testing. For example #22064 (comment) could use
--with-append-cxxflags="-ftrivial-auto-var-init=pattern"
without having to specify the default arguments again (-g -O2).