I was looking into enabling exceptions and interface_wrappers tests for Windows and I'm struggling to find a clear way to do this - being a bit afraid of the #import test_lib.dll and #include "test_lib.h" conflicting with each other.
While it would be possible to have all of these tests under the same project/solution/whatever you want to call it, I would prefer the clarity of having every test in cpp-raw come with the same prelude and having the same support classes available to it - instead of opening a random.cpp file and then having to scan includes to see whether that specific file has stuff like CreateInstance available to it or whether it should use ClassFactory::create.
I'm proposing the following:
cpp-raw
Minimal "external" requirements. (InitializeRuntime, UninitializeRuntime and CreateInstance).
Use of raw interfaces in all of their terrible usability with raw HRESULT values, out parameters, etc.
Goal is to ensure the Rust-C++ bridge works on a binary level.
Compilation for as many targets as possible: Visual Studio C++, cmake GCC, possibly cmake llvm and cmake Visual Studio in the future.
Intercom linkage in various ways: Visual studio #import, Intercom generated headers with dynamic loading, Intercom generated headers with static lib.
This is not the "This is how we expect you to use Intercom" scenario. Instead this is the "If this doesn't work, then the nicer things don't work either" scenario.
Perhaps platform specific code, such as ensuring GetErrorInfo/SetErrorInfo work on Windows, malloc works on Linux.
cpp-wrapper
The full intercom-cpp dependency.
Might be limited to "supported" use cases, such as inability to pass BStrs to wchar_t arguments (if BStrs are even supported through intercom-cpp).
Compilation primarily through CMake - both for gcc and Visual Studio. We might provide a native VIsual Studio solution, but I don't see a need for it at the moment. We've already proven that native visual studio solution works with cpp-raw. Including a header shouldn't matter.
Preferrably no platform specific code. The goal of intercom-cpp is to work on every platform.
Small bits like string handling might still be there since those seem to be inherently platform specific and we don't really want to prevent the platform specific use.
Stuff like GetErrorInfo/SetErrorInfo should be hidden behind a cross platform API under intercom-cpp which would use those methods for exceptions on Windows while something else would get used on Linux/elsewhere.
I was looking into enabling
exceptions
andinterface_wrappers
tests for Windows and I'm struggling to find a clear way to do this - being a bit afraid of the#import test_lib.dll
and#include "test_lib.h"
conflicting with each other.While it would be possible to have all of these tests under the same project/solution/whatever you want to call it, I would prefer the clarity of having every test in
cpp-raw
come with the same prelude and having the same support classes available to it - instead of opening arandom.cpp
file and then having to scan includes to see whether that specific file has stuff likeCreateInstance
available to it or whether it should useClassFactory::create
.I'm proposing the following:
cpp-raw
InitializeRuntime
,UninitializeRuntime
andCreateInstance
).HRESULT
values, out parameters, etc.#import
, Intercom generated headers with dynamic loading, Intercom generated headers with staticlib
.GetErrorInfo
/SetErrorInfo
work on Windows,malloc
works on Linux.cpp-wrapper
intercom-cpp
dependency.BStr
s towchar_t
arguments (ifBStr
s are even supported throughintercom-cpp
).cpp-raw
. Including a header shouldn't matter.intercom-cpp
is to work on every platform.GetErrorInfo
/SetErrorInfo
should be hidden behind a cross platform API underintercom-cpp
which would use those methods for exceptions on Windows while something else would get used on Linux/elsewhere.@Fluxie Opinions?