I think the port must now explicitly control interaction with PKGCONFIG when the build looks for dependencies. Disable it, or provide the program

Still valid.

I think the port must now explicitly control interaction with PKGCONFIG when the build looks for dependencies. Disable it, or provide the program

Still valid.

the port generated a pkg-config file but didn't use PKGCONFIG to find deps. I've removed the generation of the pkg-config file. The only reference to PKGCONFIG is in the Makefile, that isn't used to build the library when using CMake as build system.

This is not what was asked for.
We had working pc files and CMake config, and there is no reson to damage that.

This is not what was asked for. We had working pc files and CMake config, and there is no reson to damage that.

Hmm... It works just fine now. When I updated the version to 1.1.8 it didn't build, because the old patches didn't work.
Could you please explain to me what you ment with:

I think the port must now explicitly control interaction with PKGCONFIG when the build looks for dependencies. Disable it, or provide the program.

PKGCONFIG seems to be a optional feature introduced in 1.1.8. It's not used in building the library at all. I don't think it's necessary to provide pkg-config with the lib. I'm confused

• CMakeLists.txt has find_package(PkgConfig). If it results in PKG_CONFIG_FOUND, it will configure using pkg-config, otherwise using CMake.
• This is bad: On systems without pre-installed pkg-config, it may change the configuration result when port pkgconf is installed before libxlsxwriter.
• So the task is to force exactly one behavior which works for all systems.
  • The pkg-config approach may work (with limited won't support for downstream multiconfig usage). It requires that portfile uses vcpkg_find_acquire_program(PKGCONFIG) and passes "-DPKG_CONFIG_EXECUTABLE=${PKGCONFIG}" via cmake OPTIONS.
  • CMake may be enforced with -DCMAKE_DISABLE_FIND_PACKAGE_PkgConfig=1. It probably requires an adaptation of the original patching, for using unofficial packages and targets which carry complete transitive usage requirements.

IMO CMake is preferred when building with, and export config for, CMake.

Ah, now I get the confusion.
I recon you looked at the main branch f the libxlsxwriter repository. Then you're correct, they seem to be working on PkgCongi integration for the next release.
But if you look at the v1.1.8 tag, you'll find there is no find_package(PkgConfig) in the CMakeLists.txt:

CMakeLists.txt from v1.1.8

Indeed. Usually updates are very close to master.
So updating our CMake patches might be even more relevant. Using unofficial exported CMake config from dependencies might be more maintainable for us. minizip may come with a bzip2 link dependency.

I see... I've readded the unofficial::minizip patch

So #41217 (comment) was left unresolved.
-> #41317