库包装的运行时兼容性

Question

我想将库打包为NuGet本机包。这个问题并不是特定于打包的lib / dll / pdb /包含的方式;但具体来说，我正在考虑CoApp scripts（我希望有更好的东西可以链接到），我的印象是有太多不同的构建目标，组合获得。我试图提出或多或少的最小目标集，这些目标可供依赖于程序包的应用程序使用。对于构建目标，有以下几乎正交的轴：

1. 32位vs 64位。显然，这是合法的。
2. 动态与静态构建。这也是明智的。
3. 调试与发布版本。这也很有意义，因为调试版本引用了调试运行时（libcmtd.lib或msvcdrtd.lib），而版本构建引用了静态运行时（libcmtd.lib或msvcdrtd.lib）。有意义的是包含这些以避免默认库冲突。

以上无疑是好轴。下一个是值得怀疑的，尽管在很多例子中都有提及：

1. _cdecl vs _stdcall vs __fastcall vs __thiscall。我觉得这没什么意义。无论其他链接库如何，都将支持此特定库的调用约定。此外，变量参数仅适用于Win32中的_cdecl，还有64位调用约定different anyway。我的理解是，只要头文件声明与平台兼容的调用约定，我选择的任何内容都可以。在任何情况下，都不会为不同的调用约定提供Microsoft运行时库。

下一个我不知道如何处理。同样，示例声明

1. 由不同的工具集构建的库，它们具有不同的Visual Studio版本：从v100（v10.0，VS 2010）到vs140（v14.0，VS） 2015年）。我的主要问题是，不同Visual C ++库中的运行时库是如何兼容的？这里的问题是我们还使用其他工具集（英特尔C ++就是一个例子），这些在CoApp中通常没有相应的打包案例，同时与Microsoft运行时兼容。

我想避免为特定工具集打包。如果代码使用最旧的vesrion编译并且也没有使用任何更新的运行时函数（例如，v110是支持的最低版本），那怎么可能呢？我担心这里有两个主要的事情（对不起，另一个编号列表从这里开始）：

1. 如果我使用VS 2012编译静态库（提供bithood，静态和调试匹配），我是否能够在VS2013（其libcmt[d].lib）中链接它？
2. 在相同的条件下，我能否在VS2010中链接它？
3. 相同的两个问题，但谈到共享的DLL运行时？
4. 同样的问题，但考虑到库可能引发的运行时库定义的异常：将e。 G。如果我在启用RTTI的情况下编译库，那么std例外可以在编译器的版本链中上下兼容吗？

更一般地说，是否有Microsoft提供的运行时兼容性矩阵？

如果有任何其他编号列表指出，我也想听听。