On 6/4/21 6:27 PM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
I don't think globbing would be a particularly good practice in this case, but whatever floats your boat, I suppose. I will continue hardcoding the required include directories.
To put this in perspective, since winapi only depends on config and predef, and those depend on nothing else, you only need three include
On 6/4/21 5:26 PM, Peter Dimov via Boost wrote: directories:
"../config/include" "../predef/include" "../winapi/include"
Globbing, in contrast, would add 141 include directories.
The number of include directories doesn't really matter, as long as they don't cause conflicts (they shouldn't). The performance hit is unfortunate, and as I said, I would have liked to avoid it. This is ugly, I get it, and I fully agree, but I don't see a better way.
I fail to see how the latter can in any way be considered a superior solution.
It is superior as it does not require active maintenance. Especially given that a failed configure check because of a missing dependency might not be noticeable in CI.
We're talking about one of your libraries depending on another one of your libraries.
I can't be held to remember which of my libraries depend on what. My memory isn't that good, sorry. And I'm not immortal, you know. One day there will be another maintainer (hopefully), and the less work he has to do the better.
The dependencies of winapi aren't going to suddenly change.
Well, I wouldn't bet on that. I'm not going to add dependencies just because, but I want to be able to should I need it without silently breaking someone's configure checks.
And no, config and predef aren't going to acquire secondary dependencies either.
Checking that winapi can't be included isn't hard; add another check that only includes it and checks nothing and message(AUTHOR_WARNING when it fails.
Eh, that's still brittle and requires intervention...