Support libraries consisting of various components #48
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
By using the <lowercasePackageName>-config.cmake and <lowercasePackageName>-config-version.cmake naming schemes for the generated CMake config files, we make it possible for these config files to be found, irrespective of the capitalization used in the original find_package call. That is, find_package(NaMe) and find_package(name) will both find the same config file. This is already the case no case-insensitive filesystems (e.g. under Windows). However, on case-sensitive filesystems (e.g. most Linux setups) the used capitalization makes a difference. This can be a source of confusion and annoyance in cross-platform development. With this commit, this platform differences will vanish.
The config file will now detect wrong capitalization of the package name and emit a warning about it. Furthermore, it will try its best to subsequently use the package name in the capitalization as used in the respective find_package call. This should minimize the issues that can arise from wrong capitalization (such as mismatched capitalization in the resulting variables). Nonetheless, there are likely some issues remaining, which is why the warning requests fixing the capitalization of the package name.
Fixes TheLartians#22 Fixes TheLartians#43 (if using multiple targets as components)
Krzmbrzl
force-pushed
the
components-support
branch
from
eb69184 to
4b0a8b2
Compare
This was referenced Jan 7, 2025
|
see my PR Krzmbrzl#1 |
|
Hey, thanks for the PR! I quickly looked at the individual commits and liked the changes so far. However I find the full PR diff hard to overlook. Do you think it would make sense to separate each commit into its own PR? I think that would make it easier to discuss and trace the individual changes. |
Some parts, maybe but other parts are inter-dependent so splitting would probably produce interdependent PRs. Besides, I don't know yet when I might have the time again to do the splitting. If you do the review commit by commit, things should be clearly separated though. I tried to make one commit per logical change group. Maybe that helps? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR does a bit more than "merely" the components support. It improves upon some things that I have noticed along the way. "Unrelated" changes are strictly kept in separate, preceding commits though, so hopefully that's okay...
This PR
Fixes #47
Fixes #22
Fixes #43 (kinda)
TODO:
cmake_parse_argumentsfor more readable function callsOPTIONAL_COMPONENTSoffind_packagecall