What happened to the yanked versions?

[JoHoenk]

Hi,

first of all, thanks a lot for providing the awesome libclang-sys and also the wrapper!

Currently I´m trying to use the libclang-sys and libclang-rs in a project setup with bazel. This works pretty well so far, and I even managed to use the libclang from the internal bazel toolchain.

So in my setup I use the rust crate for 1.8.1 and maually apply the patches to 1.8.2 and 1.9.0 and an additional small hotfix. With this I can then perfectly use clang-rs using clang-sys 1.9.0. as dependency. I need to update the version from v.1.8.1 since I rely in Bazel on the additional runtime feature which was added in 1.8.2.
But this is a quite "hacky" approach which I just used to get it to work. I would like to use it in an open-source safety critical tooling and therefore I would need the explicit, official dependencies and also figure out the test coverage for the source code. But I don´t get why version 1.8.2 and 1.9.0 have been yanked. Also I can´t find the source for 2.0.0 for the wrapper any more (only as appendix to the crate but not any more in github)

TLDR:

• what was the reason for yanking the version in clang-sys and removing the source from github for Clang-RS 2.0.0?
• could we maybe bring it to a state where I could use "official" versions?

[KyleMayes]

v1.8.2 broke a "bunch" of builds: #181
Yanking v1.9.0 was just collateral damage from yanking v1.8.2 to revert the bad changes I made in v1.8.2.

(I say "bunch" since 7 thumbs up on the issue and several people commenting is more attention then most issues get on this repo)

So I just got kinda burned out on maintaining this crate.

Finding Clang is very platform-dependent, any change to the code for finding instances of Clang will probably break some number of builds in the ecosystem. Even if a new version of clang-sys only finds a different instance of Clang than the previous version then that can be enough to cause problems.

So frequently I'd address someone's problem with a new version of clang-sys, close the issue, feel a nice sense of satisfaction, then get an issue the next day from someone else about how the new version broke their builds.

I have kept meaning to revisit this crate and try to come up with some solutions to this problem, such as a separate crate with separate versioning for the build logic that finds Clang instances. I had tried something like that previously but ran into some problems and shelved the work.

No promises, but I'll make an attempt to sit down and give this repo some much-needed maintenance in the near future.

[KyleMayes]

As for v2.0.0, I dunno.
I can't remember what that was about and haven't found anything searching through the issues.

[JoHoenk]

Thanks a lot already for the detailed explanation!
I completely get your point! But what about some major/minor versioning scheme / defining some common usecases? So if someone wants to use the tool in a specific use case he should submit this usecase then. I know its hard work, but maybe creating a test suite for the usecases you want to support would bring clarity for everyone.

And would you be open to new PRs in general?

[JoHoenk]

@KyleMayes Maybe another Suggestion: In the LLVM Repo there are already python and xml bindings for libclang: https://github.com/llvm/llvm-project/tree/main/clang/bindings

Just wanted to point out that it might also be one possible alternative to put the sources there?