Skip to content
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

Merged

Conversation

autoantwort
Copy link
Contributor

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)

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)

```
@dg0yt
Copy link
Contributor

dg0yt commented Nov 7, 2023

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:

pkg_check_modules(ICU_UC REQUIRED IMPORTED_TARGET icu-uc)
target_link_libraries(main PkgConfig::ICU_UC)

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 (ICU_UC_INCLUDE_DIRS).

@BillyONeal
Copy link
Member

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:

  1. If there are CMake configs present, they should be displayed. (Even if there is pkgconfig)
  2. If there are pkgconfig files present, they should be displayed. (Even if there are CMake configs)
  3. We should not display instructions to try to adapt pkgconfig into CMake.

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!

@dg0yt
Copy link
Contributor

dg0yt commented Nov 8, 2023

Does this imply that usage files should also consider both worlds independently?

@dg0yt
Copy link
Contributor

dg0yt commented Nov 8, 2023

Does this imply that unofficial cmake config is preferred over official pkgconfig?

@JavierMatosD
Copy link
Contributor

Does this imply that usage files should also consider both worlds independently?

Yes

Does this imply that unofficial cmake config is preferred over official pkgconfig?

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)

@dg0yt
Copy link
Contributor

dg0yt commented Nov 9, 2023

I'm just worried about the intrusiveness and lock-in effect of unofficial config, and the detrimental effect on installing and fixing official pkgconfig.
At least please push upstreaming.

@dg0yt dg0yt mentioned this pull request Nov 9, 2023
7 tasks
@BillyONeal
Copy link
Member

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'.

At least please push upstreaming.

Absolutely!

Copy link
Member

@BillyONeal BillyONeal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(See previous comment)

@autoantwort autoantwort marked this pull request as draft November 11, 2023 01:26
@autoantwort autoantwort marked this pull request as ready for review November 12, 2023 02:15
@autoantwort
Copy link
Contributor Author

autoantwort commented Nov 12, 2023

Output is now

➜  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.67 us
icu provides pkg-config modules:

    # International Components for Unicode: Internationalization library
    icu-i18n

    # International Components for Unicode: Stream and I/O Library
    icu-io

    # International Components for Unicode: Common and Data libraries
    icu-uc

locales/messages.json Outdated Show resolved Hide resolved
@@ -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:")
Copy link
Contributor

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');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Contributor

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.

@BillyONeal
Copy link
Member

Can you add a test with a minimal test port that should engage this logic? (I'll push one for CMake configs here....)

@autoantwort autoantwort marked this pull request as draft November 27, 2023 20:59
Copy link
Member

@BillyONeal BillyONeal left a 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

@BillyONeal BillyONeal dismissed their stale review November 27, 2023 23:11

The problems I enumerated before got fixed.

@autoantwort autoantwort marked this pull request as ready for review December 2, 2023 21:22
@BillyONeal
Copy link
Member

Couple of nitpicks / questions:

I tried changing your example to wrong-pkgconfig[core,debug-good,header-only-good,lib-good]

and now it says:

wrong-pkgconfig provides pkg-config modules:

    # Test lib
    wrong-pkgconfig

    # Test lib
    wrong-pkgconfig

which seems wrong?

  • Should we say that this result is a heuristic?
  • Should the comment derived from 'Description' added after the name of the package rather than before?

@autoantwort
Copy link
Contributor Author

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).

Should we say that this result is a heuristic?

But this is not really a heuristic like the cmake one. That are the real pkgconfig modules.

Should the comment derived from 'Description' added after the name of the package rather than before?

I could do that. As long as the people don't thing that the # part is part of the module name :D

@BillyONeal
Copy link
Member

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).

Makes sense. (I kind of just assumed the feature was named good so it must be good)

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 # part is part of the module name :D

Up to you.

@autoantwort
Copy link
Contributor Author

Up to you.

I think I prefer the current style :)

@BillyONeal BillyONeal merged commit 5fbcab7 into microsoft:main Dec 5, 2023
5 checks passed
@BillyONeal
Copy link
Member

Thanks for the feature!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants