cmake: Amend bitcoin_crypto static library
#172
Conversation
hebasto
force-pushed
the
240426-cmake-EF
branch
from
c7cd4a2
to
c115e2d
Compare
Avoid using source-specific compile options. They hard to reason about and error-prone when combining with target-specific compile options. The resulted build logic effectively mirrors the master branch's one.
hebasto
force-pushed
the
240426-cmake-EF
branch
from
c115e2d
to
5ca0799
Compare
| target_compile_definitions(bitcoin_crypto | ||
| PRIVATE | ||
| ENABLE_SSE41 | ||
| add_library(bitcoin_crypto_sse41 STATIC EXCLUDE_FROM_ALL |
There was a problem hiding this comment.
Same comment as #171. Would OBJECT libraries be better here?
There was a problem hiding this comment.
Same as #171 (comment) :)
Yes, it could. But CMake's developers recommend to use STATIC libraries if there is no compelling reasons for OBJECT ones. For example, from Professional CMake: A Practical Guide 18th Edition
Prefer defining static libraries over object libraries. Static libraries are simpler, have more
complete and robust support from earlier CMake versions and they are well understood by most
developers. Object libraries have their uses, but they are also less flexible than static libraries.
There was a problem hiding this comment.
Object libraries have their uses, but they are also less flexible than static libraries.
This is not clear to me. In which ways are they less flexible?
There was a problem hiding this comment.
Object libraries have their uses, but they are also less flexible than static libraries.
This is not clear to me. In which ways are they less flexible?
I think, this part of the quote is not related to us as we use CMake >= 3.22.
Related to https://cmake.org/cmake/help/latest/command/target_link_libraries.html#linking-object-libraries
There was a problem hiding this comment.
The internal CMake code that handles STATIC libraries is older and more robust than code for OBJECT ones. Sticking to the former type only allows us to have predictable behaviour across the whole codebase.
Avoid using source-specific compile options. They hard to reason about and error-prone when combining with target-specific compile options.
The resulted build logic effectively mirrors the master branch's one.
Required for #157.
Similar to #171.