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

Reply via email to