[Lldb-commits] [PATCH] D43096: [lit] Update how clang and other binaries are found in per-configuration directories

Zachary Turner via lldb-commits lldb-commits at lists.llvm.org
Fri Feb 9 12:43:39 PST 2018

On Fri, Feb 9, 2018 at 12:19 PM Stiliyana Stamenova <
stiliyana.stamenova at gmail.com> wrote:

> No, we don't need a switch unless we want to be explicit.
> I am not sure what you mean by "fix that instead" - the VS generator?
What I meant is that if the default behavior (i.e. LLDB_TEST_C_COMPILER and
LLDB_TEST_CXX_COMPILER are not present at CMake configure time) is to use
the just built clang, then there is no need for a flag such as
LLDB_TEST_JUST_BUILT_CLANG.  Because that would be the same as just not
specifying anything.

What I'm trying to avoid is for people who don't use VS generator having to
remember about this in the future.

AFAICT the problem is that CMAKE_CFG_INT_DIR is a string like
"$(Configuration)", but in Python we need the string to be something like
"%(build_mode)s".  Why don't we just make the path have %(build_mode)s in
the first place, instead of making it have $(Configuration)?  Then we don't
have to replace anything.

Specifically, would it make sense to put this logic:

  set(LLVM_BUILD_MODE ".")
else ()
  set(LLVM_BUILD_MODE "%(build_mode)s")
endif ()

higher up in the LLDB CMake (for example near the top of
lldb/CMakeLists.txt), and then don't even use CMAKE_CFG_INT_DIR in the
first place?  For example, we could change this:


to this:


and similarly replace this:


with a similar pattern?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180209/d751320b/attachment.html>

More information about the lldb-commits mailing list