Why no static build / how to build against static dependencies?

[jdx-john]

I am getting SimpleAmqpClient to work with vcpkg (based on #291) and I have it building using standard options but we use a custom triplet (static build, dynamic linking to CRT).

I get the error:

The SimpleAmqpClient library cannot be built as a static library on Win32.
  Set BUILD_SHARED_LIBS=ON to get around this.

We have dozens of dependencies (including boost, openssl, other common ones) and they all build statically, we can't change our setup to dynamic builds. Is there a way to build this library dynamically but all the dependencies as static?

Why is static building not supported? All the dependencies appear to build just fine including Rabbitmq-c so I'm curious why it is explicitly blocked in CMakeLists in the first place (https://github.com/alanxz/SimpleAmqpClient/blob/e474a062da90e92e459f32a69d2680c975d3a3b2/CMakeLists.txt#L89)

I would have guessed it's due to a dependency but like I say, they all seem to build without problems. @prateek9623 don't suppose you have any ideas since you wrote the PR? I used your PR as a patch in a new vcpkg port.

[jdx-john]

I haven't tested it works but if you disable the explicit check for BULD_SHARED_LIBS and undo this #define it builds... this is pretty similar to GoogleTest which lets you turn dllspec on/off depending if the build is static:

https://github.com/alanxz/SimpleAmqpClient/blob/e474a062da90e92e459f32a69d2680c975d3a3b2/src/SimpleAmqpClient/Util.h#L33

[prateek9623]

@jdx-john I created PR just to support cmake find_package, I didn't target static build. But I don't think there shouldn't be an issue to build static build with your changes. Just make sure dependent lib are also PUBLIC and exposed. @alanxz Do you know why we don't support static build?

[alanxz]

When this was initially written, the intent was for the library to be as plug and play as possible for those using the API, this meant that I wanted as few required #define as necessary to use it, so compiling statically was deliberately not developed for.

If I were to make the same decision today, I would use the utilities provided by CMake to make this as easy as possible for API users to use.

AFAICT: other than the missing #defines to handle building and using the definitions statically, there's nothing that prevents SimpleAmqpClient from supporting a static build.

[jdx-john]

AFAICT: other than the missing #defines to handle building and using the definitions statically, there's nothing that prevents SimpleAmqpClient from supporting a static build.

This ties in with what I'd thought too, I hacked a static build (but didn't test it) with only a couple of lines linked to SIMPLEAMQPCLIENT_EXPORT so it looked like exposing this as a CMake option wouldn't be major. I actually have a working vcpkg port (for Windows at least) locally now BTW

[DraconPern]

Just want to comment that because of this issue I am unable to use this library.

[gitzko]

Any way of going forward with an important legacy Visual Studio 2013 Win32 application expecting a static lib?