You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is a topic starter for a problem of distribution and integration of rd-cpp.
We have had multiple attempts to pack rd-cpp into dll's for easier distribution (and packing into nuget, easy my ass) to be able to use it inside RiderLink project (plugin for Unreal Engine).
We had next number of issues:
Breaking ABI in STL between minor versions of toolchain (I'm looking at you, MSVC). Every breakage means adding new version of rd-cpp distribution;
Need to pack both Release and Debug dll's (so all versions need to multiply by 2);
Different toolchains not compatible between each other (again, need to multiply by N number of supported toolchains, so MSVC, Clang, GCC?)
NUMBER_OF_BUILDS = NumberOfBrokenABIsNumOfToolchains2.
If I recall correctly, dll's for 1 version of toolchain could eat up to 200 MBs which is insane.
Personal opinion, it's a dead end.
If we're accpeting the state that we're not able to distribute rd-cpp in dll's, we need to be able to share it as a source package.
What are the requirements in this case:
Option to add rd-cpp as a submodule w/o dependencies rd-kt, rd-net, rd-xxx
Minimal CMakeLists.txt to add rd-cpp w/o tests
Make it compatible with -no-exceptions and -no-rtti projects
Add option to use custom allocators
Optionals:
Conan/vcxpkg integration
The text was updated successfully, but these errors were encountered:
Leaking STL over a DLL boundary is usually a no-go for a Windows binary DLL distribution IMHO.
A LIB binary distribution is an option, tho you'd have to prepare for all supported toolchain variations of course. But since it's opensource, maybe not a good option anyway, gives about as much trouble as it saves.
Typically, a nice Windows DLL with a small API surface would have COM API or its like along the same lines, something strictly defined and not leaking half the world over the interface, which keeps STL details within the host and the DLL separated (and preferrably statically compiled). Most of the time it's okay (all of the Visual Studio APIs are happy that way, so you can imagine). But I guess the RD specific interaction with tight integration of the models and operations on them with focus on minimal overhead makes this impossible. Or does it not?
RD CPP is meant to be cross-platform, so COM is a no go.
I would say the C API would be the ideal solution. Extra bonus, it can be integrated with other languages as well by writing a small wrapper.
This issue is a topic starter for a problem of distribution and integration of rd-cpp.
We have had multiple attempts to pack rd-cpp into dll's for easier distribution (and packing into nuget, easy my ass) to be able to use it inside RiderLink project (plugin for Unreal Engine).
We had next number of issues:
NUMBER_OF_BUILDS = NumberOfBrokenABIsNumOfToolchains2.
If I recall correctly, dll's for 1 version of toolchain could eat up to 200 MBs which is insane.
Personal opinion, it's a dead end.
If we're accpeting the state that we're not able to distribute rd-cpp in dll's, we need to be able to share it as a source package.
What are the requirements in this case:
Optionals:
The text was updated successfully, but these errors were encountered: