use the utf-8 C++ library as an external (header-only) library #124
Conversation
It might be used as an external package someday. For it's a CMake interface since it's a header only piece of code.
There was a problem hiding this comment.
My initial idea of bundling this was that to avoid having a new external dependency. However, I've changed my mind since then, and I'd really prefer to convert this into a proper dependency & to remove the bundled copy. The usual Linux distros all carry it as a package anyway, and it would cut down on the amount of testing we'd have to do (e.g. only verify using the external one works, not also having to verify the bundled one can still be used).
The bundled copy wasn't modified anyway.
|
External library sounds better. |
|
What happens with an external dependency when I build with MSVC (rather VSCode) and I don't have it on my system ? Or on mac which normally don't have packages ? |
|
add some kind of subproject (no idea how to do that with cmake) and link it statically I guess. |
|
There's nothing to link, it's just a bunch of headers. Also, there's the CI that is a bare environment with no dependencies installed. |
|
right. then I guess add it as a git submodule that gets cloned when host utf8-cpp is missing. |
|
I don't know anything about MSVC packaging. Maybe you could check how VLC does it? In the end I don't really care either way, to be honest. The one thing I'd like to see wrt. to utf8cpp changes is the ability to optionally build against a system-provided utf8cpp if found, fixing #54. I'm fine carrying our bundled copy. Dropping it is a slight preference at most. |
It might be used as an external package someday. For it's a CMake interface since it's a header only piece of code.