Windows dynamically linked lib builds

[speratni]

I was wondering if there is a Windows build that includes the lib for dynamic linking, I've downloaded both w64-msvc16 and 17 releases and I can't seem to find the matching files. If not, could you explain why the windows releases just include the statically linked libraries?

Both Linux and Mac releases include the corresponding .so/.dylib files. I haven't got a Windows machine available where I could install MSVC compiler to build it on my own and I actually wanted to migrate from a solution that included making our own builds to just using prebuild lib's.

[jhmgoossens]

The master Windows builds (Windows-ci) do include the dlls and libs for the msvc16 and 17 builds. See the recent artefacts for Action builds for Windows of master branch. In the artefact bin folder you will find Cbc-0.dll, etc., while in the lib folder there is Cbc.dll.lib. Similar files are included in the mingw64 build artefact.

The stable Windows builds--used for Releases--indeed do not include the dlls and libs.
Does this help?

Future releases may start to include the dlls and libs. This requires the configure file to be updated, etc.

[speratni]

Yes thank you, didn't know about the action builds!

In the meantime I have managed to get an older windows machine, where I installed VS Community and opened the VS solution and did the following changes to get the dll built:

• Added a new configuration, changed the target to dll for the libCbc and Clp project (that include the C API files)
• Manually added the CBCLIB_EXPORT macro insided the C export files (couldn't get it working by just adding the DLL_EXPORT macro - too many linker errors expecting the statically linked libraries, could have been fixed easily probably but wasn't my goal).
• Disabled several solutions and tests that also got linker errors expecting the static libs

For now I got what I needed (both dll exporting the C API) but somewhat "hacky"

I guess if i would spend some time fixing the linker errors I could provide a new configuration that successfully outputs the dll's without any linker issues or manually macro adjustments - the question for me is, is it worth getting it there? are you accepting PR's from new contributors?

[jhmgoossens]

I use the Visual Studio solutions and projects, but always only to include Cbc (etc.) as static libraries into another project. The Visual Studio solutions are used in the Windows MSVS build and test actions. On the other hand, the Windows build and test actions use coinbrew and the makefiles etc., not the Visual Studio solutions and projects.

An 'issue' with all the MSVC builds (using Visual Studio (MSVS), or via coinbrew) is that these build only single-threaded CBC, because they don't use a pthreads library (out of the box). See also the comments in BUILDING Cbc .. With Microsoft Visual Studio and the ReleaseParallel configuration. When building from source, you can quite easily add an external pthreads library, but the binaries released here don't include those builds and external pthreads libraries. As such, I expect that users of the Windows builds rebuild from source and add a pthread library (I do)--or use the gcc-based Windows builds (not MSVC) which do come with pthreads included.

the question for me is, is it worth getting it there?

Good question. The coinbrew-based builds can already build shared libraries without the solutions and projects. At the same time, every added Configuration in the Visual Studio solutions and projects needs maintenance.

are you accepting PR's from new contributors?

Yes, of course! As long as those PRs are well written, complete, include tests etc., etc., etc. ;-)
As you say, for this we're talking about multiple PRs (one or more for every project), with update project files for for every dependency.

[tkralphs]

I wouldn't spend a lot of time on a PR related to building DLLs for the current stable/2.10 branch. When we create stable/3.0 from what is currently in master, a big part of that will be specifically about supporting DLLs and there are a lot of moving parts. I wouldn't want to make that kind of change in a patch releases. There's way too that depends on details of the way the (now very old) stable/2.10 build system works to risk upsetting that apple cart.