On Thu, Jan 30, 2025 at 04:55:34PM +0000, Stuart Henderson wrote:
> On 2025/01/30 15:26, Theo Buehler wrote:
> > On Thu, Jan 30, 2025 at 07:14:11AM +0100, Sebastien Marie wrote:
> > > Theo Buehler <t...@theobuehler.org> writes:
> > >
> > > > I think sthen is right that a variable for this in cargo.port.mk would
> > > > make sense to obviate the need to keep these in sync. On rust updates,
> > > > all rust ports are rebulit anyway, so if rust switches to llvm 19 that
> > > > would be picked up automatically.
> > >
> > > I didn't precisly followed the problem that a variable in cargo.port.mk
> > > should solve.
> >
> > Right.
> >
> > I think we're dealing with two problems and I'm no longer convinced it's
> > modcargo's job to solve either of them:
> >
> > The first problem is one of usability and more related to cargo build
> > scripts than ports: porters run into the verbose cargo output and fail
> > to spot the important bit amidst all the other unreadable noise.
> > I think that is a problem for the rust and cargo developers to solve
> > and I don't think the cargo module can really help.
> >
> > The second problem is more directly related to the two spotify ports and
> > concerns the questions you ask as well:
> >
> > > is it just to have clang-sys crate to have MAKE_ENV +=
> > > LIBCLANG_PATH=/usr/local/llvm18/lib + BUILD_DEPENDS ?
> > >
> > > and what is important ? llvm from ports (base vs ports version, whatever
> > > the llvm version is) ? exact llvm version used in rustc ?
> >
> > For ncspot and spotify-player the reason that clang-sys is built is
> > bindgen, which is required by aws-lc-sys everywhere except on the
> > popular platform rectangle {linux, mac, win} x {amd64, arm64}.
> >
> > Right now the libclang API version required by bindgen is clang_6_0
> > and it is only used to generate ffi bindings and the, the precise
> > version of llvm we pull in does not really matter.
> >
> > However, I think we can improve the situation in the two spotify ports.
> > We can use the ports default clang version, which is much more likely to
> > be present already. The ncspot binary produced with the diff below has
> > nobtcfi set and has text in a load with R E, so I would expect it to
> > work.
>
> I went with "same as used by rust", partly in case it mattered
> (I wasn't sure and it sounds like it doesn't in this case, though
> I noticed it did build ok with the 17 from my old diff before
> updating it to use 18 as per current rust), and partly because
> if rust has already been built, that clang version has also
> definitely been built.
>
I see. I'd really like to avoid hardcoding the clang version in these
two ports that don't need to do so. Which way this is achieved I don't
really care. My diff is a way to do it, but if it's preferable to
somehow export the version from rust via the cargo or the rust module,
I'm game.
