Closed dguittet closed 9 months ago
really not in the plan. AFAIK, It means tagging all methods with the dllexport flags.
I would recommend having a separate library that contains a thin solving API and OR-Tools beneath. You can make that a DLL.
I'm trying to enable linking of ortools as a static library into a separate DLL. The problem I'm running into is for Debug vs Release builds for Windows Visual Studio. Using find_package
to retrieve ortools::ortools doesn't seem to be able to handle Debug vs Release.
When I build with cmake --build build_release --config Release --target install
or cmake --build build_release --config Debug --target install
, the targets have the same name and end up overwriting each other. So then I tried to have different install directories for the Debug and Release build. However, I don't know how to use find_package
to direct to these different install directories for Visual Studio's Debug vs Release configs.
Any suggestions here?
Also, is there perhaps any update on adding dynamic library support?
@Mizux @lperron
What language and solver does this apply to? C++, any solver
Describe the problem you are trying to solve. I have an executable built in C++ that is distributed with a dynamic library. During patching of the executable, the dynamic library is replaced with a new version. We support Linux, Mac and Windows. For Unix, the dynamic library build of or-tools works great. Is there going to be support for a Windows dynamic library build?
Describe the solution you'd like Support for dynamic library build for Windows
Describe alternatives you've considered Adding or-tools as a shared library to the dynamic library we distribute