sgraenitz added inline comments.
================
Comment at: lldb/cmake/modules/LLDBStandalone.cmake:6
+ # next to LLVM's module directory.
+ set(Clang_DIR ${LLVM_DIR}/../clang)
+ message(STATUS "Inferred Clang_DIR: ${Clang_DIR}")
----------------
labath wrote:
> sgraenitz wrote:
> > compnerd wrote:
> > > sgraenitz wrote:
> > > > compnerd wrote:
> > > > > What happens in the standalone clang build scenario? Can I ask what
> > > > > is the motivation for this change? I think it is better to require
> > > > > that the user pass the path, as that is an explicit dependency of
> > > > > LLDB.
> > > > I don't think there's any side-effects on Clang standalone builds. Is
> > > > that what you mean with "standalone clang build scenario"?
> > > >
> > > > I would like top prevent people from writing custom build scripts on
> > > > top of CMake. Passing a number of very similar paths to CMake, e.g.
> > > > each time we want to generate a Xcode project for development, this
> > > > option seems to become compelling quickly. This patch makes standalone
> > > > configurations simpler. Basically, it provides a default value. I
> > > > doesn't cut down functionality.
> > > >
> > > > You can still explicitly pass any path you want. This branch will then
> > > > not be taken.
> > > I think that the build fragmentation has caused a larger problem, and I
> > > would like to avoid that. The standalone build scenario is:
> > >
> > > build/llvm
> > > build/clang
> > > build/lldb
> > >
> > > In this case, `../clang` does not exist (`../../clang/lib/cmake/clang`
> > > does). I think what I would suggest instead is adding a cache file that
> > > has the configuration parameters setup already.
> > For the scenario you describe, can you point me to any documentation that
> > describes it or a bot that builds it?
> >
> > > I think what I would suggest instead is adding a cache file that has the
> > > configuration parameters setup already.
> >
> > How would your cache file look like?
> > For the scenario you describe, can you point me to any documentation that
> > describes it or a bot that builds it?
>
> I think a lot of linux distributions which want to provide llvm,clang,etc. as
> separate packages build in this way. And those that don't, they'd probably
> want to build it that way, but they can't do it because it doesn't work for
> them for one reason or another (the standalone builds are always a bit
> behind, because the devs usually just build everything monolithically). I
> know at least gentoo builds llvm, clang and lldb standalone. Maybe @mgorny
> has a better overview of what other distros do...
Fair enough. So, in this case we just can't make a reasonable guess right?
Maybe we can still simplify the scenario for a single provided build-tree with
LLVM and Clang? How could we do it?
I changed the comment and the condition to only infer the directory if it
exists. Is that acceptable?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D65798/new/
https://reviews.llvm.org/D65798
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
