build: remove BOOST_CPPFLAGS usage from bitcoin-tx

[fanquake]

The only reason 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.

[theuni]

Nice. ACK f839697.

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: theuni@e131d8f

[hebasto]

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.

[fanquake]

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.

[hebasto]

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.

[fanquake]

Since boost is our only remaining external consensus dependency, as a follow-up, I'm wondering if we need a less hackish version of: theuni@e131d8f

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).

[hebasto]

ACK f839697, tested on Linux x86_64 using theuni's patch with depends.

[hebasto]

iwyu reports:

bitcoin-tx.cpp should remove these lines:
- #include <policy/rbf.h>  // lines 18-18
- #include <util/translation.h>  // lines 29-29

[fanquake]

Going to leave this as is.

[fanquake]

Since boost is our only remaining external consensus dependency, as a follow-up, I'm wondering if we need a less hackish version of: theuni@e131d8f

@theuni did you want to follow up to this with a PR?