CMake regression?: default for PA_BUILD_SHARED_LIBS flipped from ON to OFF

[RossBencina]

Regarding PR #765 ("Remove usage of global BUILD_SHARED_LIBS variable" by @bheisch, merged April 1, 2023), @dechamps wrote:

FYI it looks like this patch caused the default for PA_BUILD_SHARED_LIBS to flip from ON to OFF, which surprised me - I ended up accidentally releasing a version of my project with PortAudio statically linked instead of bundling it as a separate DLL. (See dechamps/FlexASIO@42e683b.) Thankfully that's benign in my case, but it might not be for others. Was the change of default value intended?

[RossBencina]

Was the change of default value intended?

Not sure. But was it a change of the default value, or a reversion to the old default behavior that was in place prior to @Be-ing's big refactor?

[syntaro]

well, Im using static Library for My dynamic library.

MXLIB02.dll -> using Portaudio static link.

[RossBencina]

well, Im using static Library for My dynamic library.

MXLIB02.dll -> using Portaudio static link.

On Windows you link with a static library that has stubs to the DLL. That doesn't change the fact that you're using the DLL (i.e. every DLL comes with a static link-library that you use to address the DLL). So this explains why @dechamps had a silent "failure" of switching from dynamic to static.

This is good argument for having a separately named static library, like we used to have before @Be-ing changed everything.

[RossBencina]

@dechamps we want to resolve this before releasing V19.8 but Phil and I are lacking sufficient context to make a decision without your feedback.

To me this sounds like a problem caused by @Be-ing 's rewrite which now uses the same name for the static and dynamic libraries, which is discussed in #486

Maybe there should be no default value for PA_BUILD_SHARED_LIBS because there is no "better" option, the user should be forced to specify?

If it defaults to ON at least the library names are consistent with V19.7

Perhaps a good fix is to make sure that as in V19.7, the static lib is built as portaudio_static as it was in V19.7, that way there is no chance of getting bitten by this issue. We could provide instructions about how to specify a different output name.

[RossBencina]

My proposal:

1. Require PA_BUILD_SHARED_LIBS to be specified by user on command line. No default.

2. Static libs should be output as portaudio_static as in V19.7

Alternative:

Retain V19.7 behavior and always build both static and dynamic versions.

[arkadijs]

The proposal is inconsistent with how other software build libs. The alternative proposal is what most developers would expect - no surprises.

Most build shared on by default and static when requested, or always both on by default (modern OS). Static linking has its own pitfalls and making another name for the static version complicates this even more.

As for linking static libs into a shared object -- hardly a common use case for cross-project linking. Also then -fPIC must be considered. Different platforms, different rules, etc. Build static lib with -fPIC or not, why? 64-bit vs 32-bit, Linux vs Windows vs Mac, just for a start :)

[generic-pers0n]

Here's my 2 cents on the matter:

I feel that PA_BUILD_SHARED_LIBS is more intuitive to be enabled by default. When building a library target, CMake's behavior is to rely on BUILD_SHARED_LIBS if that's set, and if not, it builds a static library by default. I would go against requiring users to specify on the command line since I feel that is unusual practice.

If building shared libraries by default means reverting to the old behavior, then I would support reverting back to the default behavior because I feel that's more intuitive and, according to @arkadijs, what most developers would expect.

[RossBencina]

[comment deleted, moved discussion of library file names to #486]