Issues when including as cmake subproject

[mpapierski]

I'm adding fruit project as a subdirectory in my project with add_subdirectory(fruit EXCLUDE_FROM_ALL) and from now on all library targets are building as shared as well.

This is related to #7, and #8 especially this change in main CMakeLists.txt:

option(BUILD_SHARED_LIBS "Build shared library" ON)

As according to cmake-variables(7) this variable is global and will propagate to all library targets defined after including fruit. My best guess is that mentioned change was just to add some kind of compatiblity (previously the library was SHARED). Manual says that the typical usage of this variable is through an option.

I'd suggest removing mentioned change, as according to cmake-variables(7). If there is a need for shared library in CI you can always specify -DBUILD_SHARED_LIBS=ON to produce .so, but by default it would be a static one.

If there isn't any side effects that I didn't think of I'll be happy to prepare a pull request.

[poletti-marco]

by default it would be a static one.

I think that this is a significant behavior change that would happen with this proposed change.
Of course I can easily modify the setting used for CI, that's not a problem; however, I want to make shared libraries the default for Fruit users, while still giving the option to build Fruit as a static library if desired.

One possible way around this could be to rename the CMake option to e.g. FRUIT_AS_STATIC_LIB or something like that. However this change might break some users that are currently passing -DBUILD_SHARED_LIBS, and it might do so silently (Fruit will still build; if their project's build doesn't break they would end up silently switching to using a shared library).
Do you see any alternative fix that would not cause this?

I'm adding fruit project as a subdirectory in my project

Maybe I should have asked earlier, but could you please explain better your use case? Why do you do that instead of downloading the latest Fruit version and compiling that once (as a static or shared library, and with any other flags you might want) and then linking against it from your project?
This way to build Fruit is not officially supported (still, I'm still happy to discuss and merge any change that makes your life easier in this use case without negatively impacting other Fruit users).

[poletti-marco]

Note: I'm still interested in understanding and addressing your use case, but without more information it's hard for me to suggest alternative solutions to your problem, or to be convinced that we should do the change you propose.
Please provide additional information on your use case.

[poletti-marco]

Without additional information, I'm afraid there is little I can do here.
Feel free to re-open if you're still interested in this; in that case please provide the information above.