[Lldb-commits] [PATCH] D115211: [lldb] Make the LLDB version a first class citizen

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

In D115211#3175581 <https://reviews.llvm.org/D115211#3175581>, @labath wrote:

> I am definitely not sad to see lldbBase go away, but I am wondering if we really need a separate library for this functionality (function).
>
> The only reason I can think of is that this function forces a dependency on clang. If we put it in say Utility, then all of lldb would depend on a (very tiny) piece of clang. I don't think that most of lldb would care about that, but this isn't technically correct for lldb-server. It doesn't use clang, and only depends on it because of the general tangledness of lldb dependencies. In an ideal world one would even be able to build lldb-server without having clang checked out. However, given that:
>
> - we are pretty far from an ideal world, and if we ever reach it, we could make this small dependency conditional on the existence of clang
> - it's really not clear (to me) what else should belong in the Basic library
>
> I am thinking that we could just put this stuff into Utility. It's true that the clang version stuff lives in a library called "Basic", but that's because this is the name clang chose for its lowest level library. In lldb the lowest level library is Utility.
>
> WDYT?

Yep, the clang dependency is the reason I kept it separate, and the problem gets worse downstream where you might have other compilers (i.e. Swift, but maybe Rust one day :-) that want to be part of the version number string too. Generally speaking we are pretty far from an ideal world dependency-wise, but I think the clang dependencies is one place where Alex has made quite a bit of progress over the past years. If we don't need to have the version be available in the "lowest level library", we can do it relatively nicely by having each TypeSystem provide a compilers-specific version string and incorporating that in the final version. That stuff lives in Target, which is a bit of an awkward place for an LLDB version number. That approach wouldn't work today anyway, because we need the version in Utility for the reproducers, and while I have different plants for those, a version number is going to remain pretty critical. I can imagine other things like Greg's statistics wanting to include a version number too.

What's your main concern about making it a separate library? I'm asking because I think the tradeoff between that and linking clang/swift into Utility leans in favor of a separate library, but I'd like to better understand your perspective.

In D115211#3175792 <https://reviews.llvm.org/D115211#3175792>, @tschuett wrote:

> I believe the `Basic` library in Clang does not depend on other Clang libraries. It is a tail library. Do you envision a Basic, Utility, ... library that does not depend on Clang and provides basic utilities.
>
> Maybe 2 tail libraries with utilities. One with dependencies on Clang and one without.

No, other than the version I can't imagine another utility that would have to rely on clang. I picked Basic just for consistency in the header path, I don't envision it being anything more than the version (which is why I floated Version as an alternative).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115211/new/

https://reviews.llvm.org/D115211