I'm testing with the following change.
Should I shove the dependency instead in test/CmakeLists.txt ?
$ git diff HEAD
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c6b082e..b6d24f8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -65,6 +65,7 @@ if(LLDB_INCLUDE_TESTS)
if (TARGET clang)
set(LLDB_DEFAULT_TEST_C_COMPILER
"${LLVM_BINARY_DIR}/bin/clang${CMAKE_EXECUTABLE_SUFFIX}")
set(LLDB_DEFAULT_TEST_CXX_COMPILER
"${LLVM_BINARY_DIR}/bin/clang++${CMAKE_EXECUTABLE_SUFFIX}")
+ add_dependencies(lldb clang)
else()
set(LLDB_DEFAULT_TEST_C_COMPILER "")
set(LLDB_DEFAULT_TEST_CXX_COMPILER "")
Thanks!
--
Davide
On Fri, Oct 27, 2017 at 1:16 PM, Zachary Turner <ztur...@google.com> wrote:
> Agree we should just build clang as a dependency. We're already building
> most of it anyway since we require it for the expression parser, so spitting
> out the executabatle as well should not be too controversial.
>
> On Fri, Oct 27, 2017 at 12:58 PM Davide Italiano via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>>
>> Mind if I try to write a patch for this one or you want to do it?
>>
>> On Fri, Oct 27, 2017 at 12:56 PM, Pavel Labath <lab...@google.com> wrote:
>> > Yes, listing clang as a dependency sounds like a good idea.
>> >
>> > On 27 October 2017 at 12:45, Davide Italiano <dccitali...@gmail.com>
>> > wrote:
>> >> So, I wiped out my directory for the build and then I created it again
>> >> using
>> >> cmake -GNinja ../
>> >>
>> >> I found out what the bug/problem is, BTW (was going to reply to this
>> >> e-mail but you've beaten me to the punch).
>> >> You switched LLDB to build with an in-tree clang, but ninja check-lldb
>> >> doesn't really require clang to be built.
>> >> As such, once I cleaned up my checkout, I ended up typing just `ninja
>> >> check-lldb` and that failed because clang wasn't built.
>> >> I claim that `ninja check-lldb` should list clang as dependency when
>> >> we're running the tests with the in-tree clang.
>> >> WDYT?
>> >>
>> >> Thanks!
>> >>
>> >> --
>> >> Davide
>> >>
>> >>
>> >>
>> >> On Fri, Oct 27, 2017 at 12:41 PM, Pavel Labath <lab...@google.com>
>> >> wrote:
>> >>> Did you clean your cmake cache before runinng this? Does
>> >>> '/home/davide/work/build-lldb/bin/clang' correctly refer to a clang
>> >>> binary you just built?
>> >>>
>> >>> On 27 October 2017 at 12:39, Davide Italiano <dccitali...@gmail.com>
>> >>> wrote:
>> >>>> Yes, it seems `configuration.compiler` is None, so this explodes:
>> >>>>
>> >>>> [...]
>> >>>> if not is_exe(configuration.compiler):
>> >>>>
>> >>>> [...]
>> >>>>
>> >>>> On Fri, Oct 27, 2017 at 12:37 PM, Davide Italiano
>> >>>> <dccitali...@gmail.com> wrote:
>> >>>>> I think that this change (or some change nearby) broke `check-lldb`
>> >>>>> on Fedora.
>> >>>>>
>> >>>>> I'm investigating, but in the meanwhile, here's the log.
>> >>>>>
>> >>>>> $ ninja check-lldb
>> >>>>> [2/2] Testing LLDB (parallel execution, with a separate subprocess
>> >>>>> per test)
>> >>>>> Traceback (most recent call last):
>> >>>>> File "/home/davide/work/llvm-lldb/tools/lldb/test/dotest.py", line
>> >>>>> 7, in <module>
>> >>>>> lldbsuite.test.run_suite()
>> >>>>> File
>> >>>>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
>> >>>>> line 1099, in run_suite
>> >>>>> parseOptionsAndInitTestdirs()
>> >>>>> File
>> >>>>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
>> >>>>> line 282, in parseOptionsAndInitTestdirs
>> >>>>> if not is_exe(configuration.compiler):
>> >>>>> File
>> >>>>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
>> >>>>> line 54, in is_exe
>> >>>>> return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
>> >>>>> File "/usr/lib64/python2.7/genericpath.py", line 37, in isfile
>> >>>>> st = os.stat(path)
>> >>>>> TypeError: coercing to Unicode: need string or buffer, NoneType
>> >>>>> found
>> >>>>> FAILED: cd /home/davide/work/build-lldb/tools/lldb/test &&
>> >>>>> /usr/bin/python2.7
>> >>>>> /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q
>> >>>>> --arch=x86_64
>> >>>>> --executable /home/davide/work/build-lldb/bin/lldb -s
>> >>>>> /home/davide/work/build-lldb/lldb-test-traces -S nm -u CXXFLAGS -u
>> >>>>> CFLAGS -C /home/davide/work/build-lldb/bin/clang --env
>> >>>>> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
>> >>>>> ninja: build stopped: subcommand failed.
>> >>>>>
>> >>>>> On Thu, Oct 26, 2017 at 7:18 PM, Pavel Labath via lldb-dev
>> >>>>> <lldb-dev@lists.llvm.org> wrote:
>> >>>>>> I am going to check in a change (D39215) which causes the
>> >>>>>> check-lldb
>> >>>>>> target to use the just-built clang for compiling the test inferiors
>> >>>>>> (instead of the system compiler, which was the old default). The
>> >>>>>> main
>> >>>>>> reason for this is to provide better reproducibility of test
>> >>>>>> results
>> >>>>>> between different machines/developers, by removing one of the main
>> >>>>>> sources of nondeterminism. This behavior can be overridden by
>> >>>>>> setting
>> >>>>>> the LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER cmake
>> >>>>>> variables.
>> >>>>>>
>> >>>>>> For the change to take effect you will need to clean your build
>> >>>>>> folder
>> >>>>>> (or at least, remove the affected variables from your
>> >>>>>> CMakeCache.txt).
>> >>>>>> After this you may observe a change in the test results from the
>> >>>>>> check-lldb run.
>> >>>>>>
>> >>>>>> Note that this change only affect cmake code -- if you run your
>> >>>>>> tests
>> >>>>>> by running dotest.py directly, nothing will change for you.
>> >>>>>>
>> >>>>>> regards,
>> >>>>>> pavel
>> >>>>>> _______________________________________________
>> >>>>>> lldb-dev mailing list
>> >>>>>> lldb-dev@lists.llvm.org
>> >>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
