eli-schwartz commented on issue #36411: URL: https://github.com/apache/arrow/issues/36411#issuecomment-2727526241
pkg-config works on Windows, and developer tooling such as conan can provide you with a pkg-config binary and integrate with a provided dependency tree. Probably you can do the same with vcpkg too? The main issue for pkg-config on Windows isn't that pkg-config doesn't work there... the main issue is that people are accustomed to unix systems (linux, BSD, macOS if you use a package manager such as macports/fink/homebrew) either having pkg-config preinstalled or having it one click away, together with a globally consistent library install prefix. Since developer tooling in *general* is less robust on Windows, it stands to reason that so is the builtin pkg-config experience lacking as well. At its heart, pkg-config is just a key-value format for specifying where your dependencies are and how to consume them. Like cmake, it supports relocatable installs -- Linux doesn't like relocatable installs, so, many people don't realize pkg-config does support this, but meson will generate relocatable pkg-config files for meson-built software, if you specify `-D pkgconfig.relocatable=true`: https://mesonbuild.com/Builtin-options.html#pkgconfig-module There are a couple implementations of it floating around: - pkg-config (freedesktop, original) - pkgconf (used by most distros today) - https://github.com/skeeto/u-config (claims to be specifically designed for Windows w64devkit) I've never used the third one myself. ... Meson fully supports looking up dependencies using multiple lookup methods. It is understood, but unfortunate, that much cmake-using software exists, which provides foo-config.cmake files (can only be parsed by cmake!) and NOT pkg-config files, which technically means that those libraries forcibly compel all software that wants to use said libraries, to use cmake as well. Ideally, software should ship both, so that they don't restrict their consumers' choice of build systems. Meson handles this, though, by implementing support for looking up `dependency('foo')` and having it find those `foo-config.cmake` files and extract the flag for them. ***This requires cmake to be installed when building***. Which is probably fine, if you installed a dependency using cmake, and doesn't restrict you from using meson.build for yourself, if you happen to prefer it over CMakeLists.txt Similarly, but less reliably, meson's equivalent to cmake `add_subdirectory()` / `ExternalProject` / `FetchContent` (I treat the three interchangeably, since it is usually as clear as mud which one to use and all three perform extremely similar roles) is: ```meson subproject('foo') ``` for native meson projects, and ```meson cmake = import('cmake') cmake.subproject('foo') ``` for cmake ones. This is capable of configuring the dependency by downloading its source code (checksumming it for security) and configuring it using cmake, then hoisting the build rules into meson: https://mesonbuild.com/CMake-module.html It is not guaranteed to work as it depends on how reliably meson can get all needed information from https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html, but many people have had good results with it. Of course, you may always still build and install the dependency in a pre-build script or via conan/vcpkg, and then detect those via pkg-config / cmake. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
