-
Notifications
You must be signed in to change notification settings - Fork 261
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
Also generate cmake usages for pkgconfig files #1268
Also generate cmake usages for pkgconfig files #1268
Conversation
Before: ``` ➜ vcpkg git:(test-features) ✗ vcpkg x-set-installed --enforce-port-checks 'icu' Detecting compiler hash for triplet arm64-osx... All requested packages are currently installed. Total install time: 1.54 us ``` After: ``` ➜ vcpkg git:(test-features) ✗ vcpkg x-set-installed --enforce-port-checks 'icu' Detecting compiler hash for triplet arm64-osx... All requested packages are currently installed. Total install time: 1.58 us icu can be imported via CMake FindPkgConfig module: find_package(PkgConfig) # International Components for Unicode: Internationalization library pkg_check_modules(icu-i18n REQUIRED IMPORTED_TARGET icu-i18n) target_link_libraries(main PkgConfig::icu-i18n) # International Components for Unicode: Stream and I/O Library pkg_check_modules(icu-io REQUIRED IMPORTED_TARGET icu-io) target_link_libraries(main PkgConfig::icu-io) # International Components for Unicode: Common and Data libraries pkg_check_modules(icu-uc REQUIRED IMPORTED_TARGET icu-uc) target_link_libraries(main PkgConfig::icu-uc) ```
A good occasion to make a conscious decision: Choose the above, or choose:
The first is more legible for the suggested usage. The second makes it clear where the target name comes from, and it is more consistent when also using the variables ( |
Last time the vcpkg maintainers discussed this topic, we opposed adding CMake instructions based on pkgconfig files. For pkgconfig, we should be providing pkgconfig instructions. In particular, using pkgconfig dependencies like this from CMake can create problems for folks who themselves are trying to ship CMake configs, as the pkgconfig dependency space and the CMake dependency space are disjoint. See previous discussion microsoft/vcpkg#33001 (comment) @ras0219-msft suggests that the standard should be:
Also present in discussion: @JavierMatosD @vicroms @data-queue who agreed with the above. Overall though we agree that helping folks use packages that provide pkgconfig is a good thing, thanks for your contribution there! |
Does this imply that |
Does this imply that unofficial cmake config is preferred over official pkgconfig? |
Yes
Sort of – since our tool is largely CMake-based, the unofficial CMake configs just fit into our workflow more smoothly than the official pkgconfig does. (generated usage should give neither preference over the other) |
I'm just worried about the intrusiveness and lock-in effect of unofficial config, and the detrimental effect on installing and fixing official pkgconfig. |
I think the intent is not 'burn pkgconfig', but 'if we are patching a downstream anyway, and we have the choice between unofficial cmake targets and pkgconfig, we want to choose the unofficial targets, because pkgconfig and cmake configs are separate universes that don't join together cleanly'.
Absolutely! |
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.
(See previous comment)
…es` themselves and can't blame vcpkg if `pkg_check_modules` does not work.
Output is now
|
@@ -482,6 +482,7 @@ DECLARE_MESSAGE(CISwitchOptSkipFailures, | |||
"Skips ports marked `=fail` in ci.baseline.txt") | |||
DECLARE_MESSAGE(CISwitchOptXUnitAll, (), "", "Reports unchanged ports in the XUnit output") | |||
DECLARE_MESSAGE(ClearingContents, (msg::path), "", "Clearing contents of {path}") | |||
DECLARE_MESSAGE(CMakePkgConfigTargetsUsage, (msg::package_name), "", "{package_name} provides pkg-config modules:") |
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.
Should pkg-config
be localized as well?
{ | ||
if (Strings::starts_with(line, "Description: ")) | ||
{ | ||
Strings::append(msg, " # ", line.substr(StringLiteral("Description: ").size()), '\n'); |
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.
Strings::append(msg, " # ", line.substr(StringLiteral("Description: ").size()), '\n'); | |
Strings::append(msg, " # ", StringView(line).substr(StringLiteral("Description: ").size()), '\n'); |
Construction of a temporary std::string
can be avoided.
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.
Furthermore, I think it's worth converting the StringLiteral to a static constexpr variable.
Can you add a test with a minimal test port that should engage this logic? (I'll push one for CMake configs here....) |
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.
I added a test for CMake configs; please copy pasta vcpkg-hello-world-1
or vcpkg-empty-port
, make it write a .pc you're looking for here, and add to the lists in usage.ps1
. Then this LGTM I think
The problems I enumerated before got fixed.
Couple of nitpicks / questions: I tried changing your example to and now it says: wrong-pkgconfig provides pkg-config modules:
# Test lib
wrong-pkgconfig
# Test lib
wrong-pkgconfig which seems wrong?
|
Because the features of the port install pkgconfig files in share/pkgconfig and lib/pkgconfig which no normal port do (you get an postbuildcheck error).
But this is not really a heuristic like the cmake one. That are the real pkgconfig modules.
I could do that. As long as the people don't thing that the |
Makes sense. (I kind of just assumed the feature was named good so it must be good)
👍
Up to you. |
I think I prefer the current style :) |
Thanks for the feature! |
Before:
After: