BOOST_CPPFLAGS
was needed here, is because of the policy/rbf.h
include, which ultimately includes boost multi_index via txmempool.h
. However this include is unused.
BOOST_CPPFLAGS
was needed here, is because of the policy/rbf.h
include, which ultimately includes boost multi_index via txmempool.h
. However this include is unused.
The only reason BOOST_CPPFLAGS is needed here, is because of the
policy/rbf.h include, which ultimately includes boost multi_index
via txmempool.h. However this include is actually unused.
Nice. ACK f839697d9b89002d020997154e182ddb4dccf45b.
As an aside, do any of our c-i runs actually test this? At least for depends, the boost headers are installed to the same prefix as everything else, meaning that $(BOOST_CPPFLAGS)
is almost always redundant.
Since boost is our only remaining external consensus dependency, as a follow-up, I’m wondering if we need a less hackish version of: https://github.com/theuni/bitcoin/commit/e131d8f1e33baa9a9499d2e1a4a99b171566c5a5
As an aside, do any of our c-i runs actually test this? At least for depends, the boost headers are installed to the same prefix as everything else, meaning that
$(BOOST_CPPFLAGS)
is almost always redundant.
Agree. Right now a build will success even after sed 's/ $(BOOST_CPPFLAGS)//g'
through the entire code base. To make manipulations with $(BOOST_CPPFLAGS)
verifiable, I strongly believe that @theuni’s suggestion should go first.
As an aside, do any of our c-i runs actually test this? At least for depends, the boost headers are installed to the same prefix as everything else, meaning that $(BOOST_CPPFLAGS) is almost always redundant.
At the moment, atleast a native macOS (M1) build will blow up, because (brew installed) Boost is in a “non-standard” path.
Agree. Right now a build will success even after sed ’s/ $(BOOST_CPPFLAGS)//g’ through the entire code base.
This isn’t correct. Non-depends builds can/will fail.
As an aside, do any of our c-i runs actually test this? At least for depends, the boost headers are installed to the same prefix as everything else, meaning that $(BOOST_CPPFLAGS) is almost always redundant.
At the moment, atleast a native macOS (M1) build will blow up, because (brew installed) Boost is in a “non-standard” path.
Agree. Right now a build will success even after sed ’s/ $(BOOST_CPPFLAGS)//g’ through the entire code base.
This isn’t correct. Non-depends builds can/will fail.
Agree, but it appears that the only system on which a build will fail is macOS M1 due to the reasons mentioned above.
Since boost is our only remaining external consensus dependency, as a follow-up, I’m wondering if we need a less hackish version of: https://github.com/theuni/bitcoin/commit/e131d8f1e33baa9a9499d2e1a4a99b171566c5a5
Agree, but it appears that the only system on which a build will fail is macOS M1 due to the reasons mentioned above.
I’m happy for us to move in the direction suggested by Cory as a follow up. I think the current set of cpp changes (including the other PRs) are straightforward, and can be reviewed without changing depends (I’m also checking flag usage locally).
14@@ -15,7 +15,6 @@
15 #include <key_io.h>
16 #include <fs.h>
17 #include <policy/policy.h>
18-#include <policy/rbf.h>
iwyu reports:
0bitcoin-tx.cpp should remove these lines:
1- #include <policy/rbf.h> // lines 18-18
2- #include <util/translation.h> // lines 29-29
Since boost is our only remaining external consensus dependency, as a follow-up, I’m wondering if we need a less hackish version of: https://github.com/theuni/bitcoin/commit/e131d8f1e33baa9a9499d2e1a4a99b171566c5a5 @theuni did you want to follow up to this with a PR?
Labels
Build system