search

OutpostUniverse / OP2Utility

C++ library for working with Outpost 2 related files and tasks.
MIT License
4 stars 0 forks source link

Static Library Link #328

Open ldicker83 opened 4 years ago

ldicker83 commented 4 years ago

Project settings for OP2Utility uses static linking for the run-time library -- out of curiosity, why was this choice made? It necessitates that other applications developed using OP2Utility also link to the run-time library statically instead of using the DLL versions. While not necessarily the biggest issue in the world, it does create a larger binary file and can cause confusion to users who aren't aware of this option.

DanRStevens commented 4 years ago

No runtimes to distribute is one of the big reasons. If you use dynamic linking, you often end up telling people to go to the Microsoft website to download/install the MSVC runtime separately. Depends a bit on which version of Windows they're using, and which version it was compiled with, which often catches developers by surprise since they're generally using the same version they are compiling on.

I haven't looked much into the issue with downstream project settings.

Brett208 commented 4 years ago

I think @ldicker83 is correct that more often Windows projects use dynamic linking. In my experience, sometimes using static linking has caused complications in linking to other projects since it is less common.

A lot of the early static linking I think was driven by Wine compatibility for missions which was thought to be eased by static linking. I know NetHelper had problems since it targeted a very recent version of the runtime library and would just silently fail if it wasn't present until we switched it to static compilation.

By linking to an old enough runtime library, one may be able to ensure anyone not using a very old machine had the library already installed. I think just statically linking nicely eliminates the problem, especially since executable size matters so little for this type of application. I just wish it were a bit easier to link against.

Many large projects offer both a static and dynamic compilation option. Maybe we want to support both? Ideally OP2Utility should not prevent a downstream application from being either statically or dynamically linked against.

DanRStevens commented 4 years ago

With NuGet packages, I've noticed they are often distributed with a tag for both statically linked runtime and dynamically linked runtime. For libraries, they also vary in another dimension, of being either a static library or a dynamic link library themselves. Hence libraries are often packaged as 4 different variants. Perhaps we should do similar.

ldicker83 commented 1 year ago

Been a few years, wanted to poke this issue again. Since we've been using vcpkg almost exclusively it might be interesting to look into offering that.

In the mean-time I've updated op2-landlord to use OP2Utility as a submodule. In order to get it to build I had to 1) update to vs2022 and 2) change linking to multi-threaded DLL. In a case like this it's an almost trivial process so that might be something to include in the docs.