Closed AllanBlanchard closed 2 years ago
@vprevosto I don't know exactly how you proceed for Frama-Clang, so I let you decide whether you want to generate it.
@vprevosto I don't know exactly how you proceed for Frama-Clang, so I let you decide whether you want to generate it.
A trick question :smirk: I guess it would make sense to do the same, except that I'm not sure whether it can be assumed that frama-clang is in ../../src/plugins/frama-clang
to generate a proper version number.
except that I'm not sure whether it can be assumed that frama-clang is in
../../src/plugins/frama-clang
to generate a proper version number.
Yes, this is why I was unsure about this.
This is done for acslpp-implementation as well. There's still one issue left, though. Namely, if one of the version files is created in its "unknown" form, and a new compilation attempt is performed with the corresponding variable correctly set, the file will probably not be generated again, as it is newer than its dependencies (except in the case where you clone frama-c or frama-clang to get said file). Maybe we could make them as .PHONY
targets and let latexmk
decide whether their content has changed.
.PHONY
it is. I've also reworded warning messages and adapted variable names, to be consistent between FC and FCLang. It's fine with me, @AllanBlanchard I let you merge if you're OK with my commits.
It is OK for me, but I do not have the right to merge :sweat_smile:
This point will be fixed soon.
Generate Frama-C version file instead of having to update the file ourselves. If the version cannot be generated (acsl is not in the doc directory of Frama-C), a joker version is generated (XX.X).