frama-clang Version 0.0.19~beta

[frama-ci-bot]

No description provided.

[zilbuz]

Depend on Frama-C 32.0~beta: #28842

[jmid]

OK, thanks. Like for the other one, we should wait until #28842 is merged and then rerun CI for this PR.

[jmid]

Retriggered a CI run here too, now that #28842 has been merged.

[jmid]

Hm. CI logs is full of conf-libclang failures that I am trying to understand, since it is listing only 6 jobs passed.
This is not a problem with this PR, just a good opportunity to figure out the problem... 🤔

• It is passing on debian-12 with conf-libclang.15 (installing both libclang-14-dev and libclang-dev system packages...)
• It is failing on debian-13 with conf-libclang.12 and llvm_version=19.1.7
• It is failing on debian-testing listing os-version=unknown with conf-libclang.12 and llvm_version=19.1.7
• It is failing on debian-unstable listing os-version=unknown with conf-libclang.15 and llvm_version=19.1.7

There are several things at play here

• For the first one, debian with os-version="12" matches several depexts cases in conf-libclang.15
• The following three fails because llvm 19 is greater than both "at most libclang 12" and "at most libclang 15".
  This should be possible to solve (at least partly) by rolling a new conf-libclang.19
• I still don't understand why some install conf-libclang.12 and others conf-libclang.15...

[vprevosto]

This is indeed

Hm. CI logs is full of conf-libclang failures that I am trying to understand, since it is listing only 6 jobs passed. This is not a problem with this PR, just a good opportunity to figure out the problem... 🤔

This is indeed a recurring problem, and I think the root cause lies in the fact that conf-llvm and conf-libclang have differing views on how to install their external libraries if they are found to be missing. Now, looking at the synopsis of conf-libclang, it says that it is a "virtual package relying on the installation of llvm and clang libraries" (emphasis mine, as I find it a bit counter-intuitive 😅 given the existence of a conf-llvm package), so maybe making frama-clang depend only on conf-libclang might solve some issues. I'll try it.

[vprevosto]

OK, 54f70db should ensure that opam only install one version of the llvm libraries as a system dependency, but we're left with the issue of convincing conf-libclang to accept it. As you noticed @jmid, this probably involves creating conf-libclang.19. However, noting that for a certain number of distros, the default libclang package will install version 20 if not 21, I'm wondering whether the way conf-libclang traces the versions of libclang is really sustainable. This PR is probably not the most appropriate place to have this kind of discussion, but I'd be happy to take part in it, and I can work on an update if a consensus on a new design emerges.

[jmid]

I've now opened #28950 which hopefully should address the conf-libclang errors.

[jmid]

I've repeated the close-open dance and pressed 'rebuild all' in opam-ci now that #28950 has been merged.
Fingers crossed that this will address the many conf-libclang.12 errors... 🤞

[jmid]

Suggested change

	"conf-libclang" {>= "11.0.0" & < "20"}
	"conf-libclang" {>= "11.0.0"}

I now realize a new all-green conf-libclang.21 is not going to help here! 😅
Could you explain why there is such a conservative upper bound here?
We generally try to avoid them unless there is a good reason for it https://github.com/ocaml/opam-repository/tree/master/governance/policies#5-strict-dependency-constraints-should-be-avoided---or-preventive-upper-bounds
Up until #28950 conf-libclang.15 was the repo's max version... 🤔

[vprevosto]

There are known incompatibilities with clang 21. I have a branch to work on that, but it is not planned to be merged for this release of frama-clang, especially as it involves some changes to the architecture of the plug-in to better abide with clang's guidelines. Generally speaking, there are very often a few changes in libclang's API that break frama-clang between two major versions, hence the upper bound.

By the way, thanks for your efforts on this topic!

[jmid]

Ah, thanks for clarrifying! Sounds like we should roll a conf-libclang.19 as we also discussed...

[mseri]

Added in #28968