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."
I saw that, but it also uses the term "atoms" which, given cygport's
mentioning of being based on ebuilds, put the ebuild definition of atoms
in my head, which can include version constraints (and slots, which would
be a better fit for this).
https://dev.gentoo.org/~zmedico/portage/doc/man/ebuild.5.html
but reading more closely, I guess the more general "atoms" can only be
used in this context if they're in PROVIDES, otherwise they are restricted
to "actual package names".
> 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.
Then again, it does say I can use an "atom" here rather than a bare
package name, so maybe I could specify a version constraint as long as
it's a PROVIDES instead of the actual name of a package?
