[Tooling] Project Structure P1204R0 Lib Prefix
Tino Didriksen
mail at tinodidriksen.com
Wed Nov 7 14:28:31 CET 2018
G'day...
On initial read, P1204R0 sounded good and makes sensible arguments for its
reasoning that I couldn't argue against at the time. So I figured I'd try
it out on an existing project, and hit one detail that's a complete
showstopper for me: Prefix lib for includes.
A consequence of library target folders being named libfoo is that #include
must also use <libfoo/...>. That's a step too far. #include <> implies it's
a public library and thus implies lib - users should not be required to
write lib here. It's not <libboost/...> or <libiostream> or really
<libanything> - I've never seen prefix lib in public includes, and I don't
want to. Installing a package libfoo gives you <foo/...> - it does not and
should not give you <libfoo/...>. No other language does anything similar
either.
One possible resolution is to have folders at least for target types.
Something like libs/ and bins/ so that we can have libs/foo/ leading to
#include <foo/>. I realize this would be a potential conflict with headers
in bins/foo/ and that the paper has reasons for ""-includes being
problematic, but quite frankly any minor risk with ""-style is worth it to
avoid prefix <lib/>.
-- Tino Didriksen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20181107/eff5c1bc/attachment.html
More information about the Tooling
mailing list