On Wed, 13 Aug 2025, Jeremy Drake via Cygwin-apps wrote: > On Tue, 12 Aug 2025, Brian Inglis via Cygwin-apps wrote: > > > On 2025-08-12 14:07, Jeremy Drake via Cygwin-apps wrote: > > > On Mon, 11 Aug 2025, Jeremy Drake via Cygwin-apps wrote: > > > > > > > clang and lld require the matching version of llvm to build against. > > > > The > > > > named libllvm20.1 package for the library itself is nice for runtime, > > > > but > > > > how do I ensure that scallywag pulls in the correct libllvm-devel (and > > > > libpolly-devel), especially while they are still test versions? > > > > > > It seems like scallywag accepts BUILD_REQUIRES with package=version > > > format, but only if the version is the full "${PVR}" format (I first used > > > "${PV}" and that didn't work). It seems like cygport isn't as happy with > > > that, it warns that the packages are not installed even if they are. > > > > > > I did see a "testpackages" scallywag token, but that would install *all* > > > test packages, not just the ones it needs (so would link against a newer > > > cygwin dll for instance). > > > > > > Also, is there a version constraint for binary package dependencies? I > > > had to explicitly add a BUILD_REQUIRES to lld for llvm=${PVR} due to the > > > libllvm_devel_REQUIRES having just llvm in it, and that pulled in llvm 8 > > > instead of llvm 20. Obviously, libllvm_devel 20 requires llvm 20, not > > > llvm 8. > > > > /usr/share/doc/cygport/html/manual/check_funcs_cygpart.html#BUILD_REQUIRES: > > > > BUILD_REQUIRES ..."only actual package names, or atoms that are listed > > PROVIDES of other packages, may be used in this variable." > > > So one option often used for language products is a setup provides keyword, > > where each llvm dependent component may need its own custom provides, e.g. > > > > gcc-core > > .... > > version: 13.4.0-1 > > .... > > provides: gcc13 > > .... > > This could work. Any package which doesn't have the soversion in its name > would "provides" itself with the soversion appended. Then any of the > packages that "require" a corresponding version would require that > provided name instead of the generic base name. I think I'll try that and > make sure it works out in practice.
This worked out well, and I built and uploaded -2 revisions of llvm and clang (plus lld, which I didn't upload before).