r316800, thanks!
On Fri, Oct 27, 2017 at 2:07 PM, Zachary Turner wrote:
> One more nitpick. Can you make it a dependency of `check-lldb-lit` target
> also? Just for the sake of pedantry.
>
> On Fri, Oct 27, 2017 at 2:04 PM Pavel Labath wrote:
>>
>> Ship it.
>>
>> On 27 October 2017 at 13:56, D
One more nitpick. Can you make it a dependency of `check-lldb-lit` target
also? Just for the sake of pedantry.
On Fri, Oct 27, 2017 at 2:04 PM Pavel Labath wrote:
> Ship it.
>
> On 27 October 2017 at 13:56, Davide Italiano
> wrote:
> > Take 2 (it can't be in the top-level CMakeList because th
Ship it.
On 27 October 2017 at 13:56, Davide Italiano wrote:
> Take 2 (it can't be in the top-level CMakeList because the check-lldb
> target is declared elsewhere).
>
> $ git diff HEAD
> diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
> index d5d71d1..958f9f3 100644
> --- a/test/CMakeList
On 27 October 2017 at 13:23, Sam McCall wrote:
> On Fri, Oct 27, 2017 at 10:06 PM, Pavel Labath wrote:
>>
>> LLDB has a JSON parser/serializer that we'd like to get rid of.
>
> Ah, sorry for missing that!
> What makes you want to get rid of it? Maintenance/duplication, or things you
> don't like
Take 2 (it can't be in the top-level CMakeList because the check-lldb
target is declared elsewhere).
$ git diff HEAD
diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
index d5d71d1..958f9f3 100644
--- a/test/CMakeLists.txt
+++ b/test/CMakeLists.txt
@@ -109,6 +109,12 @@ add_python_test_target(
On 27 October 2017 at 13:28, Zachary Turner wrote:
> Maybe make it a dependency of the `check-lldb` target instead of the `lldb`
> target?
>
+1
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Maybe make it a dependency of the `check-lldb` target instead of the `lldb`
target?
On Fri, Oct 27, 2017 at 1:26 PM Davide Italiano
wrote:
> 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
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)
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.o
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 wrote:
> Yes, listing clang as a dependency sounds like a good idea.
>
> On 27 October 2017 at 12:45, Davide Italiano wrote:
>> So, I wiped out my directory for the build and then I c
On Fri, Oct 27, 2017 at 12:52 PM, Ted Woodward
wrote:
> I think if clang exists in-tree, it should be used. If it doesn't, the
> compiler used to build lldb should be used.
>
> Unless, of course, the compiler is specified with the cmake variables.
>
I think that if the default is to run tests wi
Yes, listing clang as a dependency sounds like a good idea.
On 27 October 2017 at 12:45, Davide Italiano 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
I think if clang exists in-tree, it should be used. If it doesn't, the compiler
used to build lldb should be used.
Unless, of course, the compiler is specified with the cmake variables.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a L
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 requi
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 wrote:
> Yes, it seems `configuration.compiler` is None, so this explodes:
>
> [...]
> if not is
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 wrote:
> I think that this change (or some change nearby) broke `check-lldb` on Fedora.
>
> I'm investigating, but in th
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
It seems that ‘process launch’ tries to launch gdb-server that is already
started manually, try to attach instead.
I also met ‘remote-gdb-server’ platform, maybe it fits your goal better? Didn’t
you try to do something like this?
dotest.py --platform-name=remote-gdb-server
--platfrom-url=connec
18 matches
Mail list logo
