> On Mar 31, 2020, at 12:25 PM, Blake Bender <bben...@pivotal.io> wrote:
>
> Just want to make sure I understand what you're after here. We should have
> a "ccache" directory or similar in the geode-native repo, where we build C
> bindings for the client, then we should compile them into a shared library
> containing all of the code, and export/make visible only the C interface?
Correct.
> So the geode native installer will contain shared libraries representing 3
> copies of all the code, with the static library in the build tree making a
> total of 4?
Let me see if I am counting the same things you are:
Out of the existing geode-native repo:
1 - C++ dynamic library (only C++ symbols exported)
2 - C dynamic library (only C symbols export)
3 - .NET Framework mixed mode assembly (deprecated, only .NET symbols exported)
Out of the new geode-net repo: (keeping it short, dropping the dot)
4 - .NET Core mixed mode assembly
or
4 - .NET Core assembly with dependency on C dynamic library
This also supposes that we have one installer for all this, maybe we have
multiple installers, maybe we select what we want to install, maybe it doesn’t
matter because in the end Geode doesn’t even produce an installer.
> I'm starting to be concerned with the overall inefficiency of this plan.
> Is this the best we can do?
Can you describe the inefficiency you are thinking about.
I see having the C dynamic library statically linked the C++ bits as a much
smaller footprint to whatever language it is eventually bound to. All the C++
templated symbols that are unused by the C binding layer should be left our by
the linker. I won’t have to copy two dynamic libraries with my C-binding based
application. Think about .NET core, if we can’t do mixed mode assemblies then
it must be dynamically dependent on the C dynamic library, if the C library was
dynamic to the C++ then we have to have that library also in the path. Recall
how hard it is for some to manage having .NET and SSLimpl in the same path, now
it's worse. If the inefficiency is disk space, that’s cheeper than support time
on getting library paths correct.
-Jake
