New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixing the build and install trees #2051
Fixing the build and install trees #2051
Conversation
@tatsuhiro-t mind taking a look? |
"${CMAKE_CURRENT_SOURCE_DIR}/includes" | ||
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/includes> | ||
$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/includes> | ||
$<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the heart of the issue
Thank you for PR. Merged now. |
@anthonyalayo these pull request changes cause the lib to be built as static on Windows (with Visual Studio) even though The |
With the above change, all is well on Windows with the 1.60.0 release. Have a nice weekend. |
@jmckenna sorry just to make sure I'm following, you're saying the fix is still needed, or not needed? The messaging was a bit mixed there. |
Your changes made through this pull request (that were merged into the 1.60.0 release) cause Windows/Visual Studio to always build static lib. In order to fix that, I described the one line change above. |
@jmckenna I took a look at the changes but I can't see how this regression came around. I simply renamed |
I pointed to the exact lines above |
In your pull request here, you removed that |
Due to the rename, builds that set |
@vszakats Nothing non-default, I am speaking of users who need to set |
ok ok. No worries. Closing here :) |
Nice catch @vszakats , I didn't see the shell script there, that explains it |
Background
Upon trying to use the
nghttp2
target through fetchcontent, I saw the following:Taking a look, I realized that proper generator statements weren't setup for
target_include_directories
. I fixed that, so that both the build and install trees work.While I was at it, I upgraded CMake to 3.14 (released April 2019 so it should be supported by others without issue) to reduce the complexity of the install statements. CMake 3.14 added default destinations for executables, static libraries, and shared libraries.
I added proper export statements to the installations, so that upstream projects don't need to do it themselves. Otherwise, CMake will throw the error
target "nghttp2" that is not in any export set.
Lastly, I addressed issue #2050, where a properly aliased library is emitted from the project. It follows the same pattern that curl has. Using
BUILD_SHARED_LIBS
instead ofENABLE_SHARED_LIB
aligns with CMake's global variable that is used in modern projects.BUILD_STATIC_LIBS
is named for consistency.Testing
Build
Install