here-abarany commented on code in PR #3435:
URL: https://github.com/apache/avro/pull/3435#discussion_r2213840667
##########
lang/c++/CMakeLists.txt:
##########
@@ -56,8 +56,25 @@ set(AVRO_VERSION
"${AVRO_VERSION_MAJOR}.${AVRO_VERSION_MINOR}.${AVRO_VERSION_PAT
project (Avro-cpp)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_SOURCE_DIR})
+# Try to respect BUILD_SHARED_LIBS if set. If not set, then fall back to the
original default of
+# both static and shared.
+if (DEFINED BUILD_SHARED_LIBS)
Review Comment:
`BUILD_SHARED_LIBS` is a standard CMake variable that determines the default
behavior of `add_library()`. [See documentation
here.](https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html)
While you are correct that technically using `BUILD_SHARED_LIBS` isn't
required to cover this use case, the intent is to support reasonable
expectations out of the box for those who have tooling built around standard
CMake behavior. It is generally expected for a "well-behaved" CMake project to
respect `BUILD_SHARED_LIBS` to control the type of linking that is used. For
example, if you have many external dependencies you are building with CMake,
you would ideally apply a common set of options across all of them and only
occasionally need to apply project-specific options. While *technically* always
using the default of "build both" regardless of the value of
`BUILD_SHARED_LIBS` should work as either library will be available, if the
user set the variable it stands to reason that they only care about one or the
other.
I suppose you could make the argument that this isn't quite the same, as the
shared and static targets use different names. (with the `_s` suffix for
static) If you feel that this invalidates my above argument, I will respect
your decision.
As far as inverting the variables with `SKIP`, I can make that change if
you'd prefer. I set it this way initially as it is consistent with
`AVRO_BUILD_EXECUTABLES` and `AVRO_BUILD_TESTS`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@avro.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
