Include strategy

[HazardyKnusperkeks]

Hi,

I'm starting to use this library, but have some issues with the include strategy. I'd like to have a proper folder for the inclusion, something like: #include <ctre/ctre.hpp> like https://github.com/fmtlib/fmt, boost, or https://github.com/mpusz/units.

If one included some headers directly, we basically have this already. I wanted only ctre::match so I #include <ctre/wrapper.hpp> because it's defined there. But here lies another problem, the headers are not self containing. So I have to ask what is the difference between include/ctre.hpp and single-header/ctre.hpp I always get everything, right?

[hanickadot]

Always include just <ctre.hpp> it's not designed for including only a selected header. Set your include folder to include/ or single-header/ result should be identical.

[Alcaro]

The difference between the two ctre.hpp is whether it's a single header, nothing else. The latter just replaces every #include with the target file's contents, flattening CTRE to a single file and letting you control how you want to arrange your directories.

[HazardyKnusperkeks]

Always include just <ctre.hpp> it's not designed for including only a selected header. Set your include folder to include/ or single-header/ result should be identical.

Yeah, it'd be great, if there was some sort of hierarchy. Of course it's your choice whether to grant such a request or not.

The difference between the two ctre.hpp is whether it's a single header, nothing else. The latter just replaces every #include with the target file's contents, flattening CTRE to a single file and letting you control how you want to arrange your directories.

So basically only for those who want to copy the single-header variant somewhere else? Did not think about such use case.

[Alcaro]

What is your actual goal here? Including half of a library is a good first step toward several plausible goals, but it's not a meaningful operation in itself.

Do the unused parts take too long to compile? Does CTRE pollute the global namespace too much? Did you think that's the correct header to include, and want a #error that tells which header to include instead?

[HazardyKnusperkeks]

This is the 10th 3rd Party library I include in my project tree and the only one which has no path in the actual include statement, so it is the one standing out. I just wanted to know if this is on purpose or if you want to change that. I'm happy either way, I have added a rule to my build process to create forwarding headers with the wanted structure.

The other thing is the single headers, which are part of the include path, I find it odd that they are not meant to include, without at least having some sort of "details", "impl", or something like that to imply that you shouldn't use them directly.

I'm totally fine if there is only one header, but if there are multiple, I always try to include them directly, and only those which I need.