Re: [lldb-dev] LLDB build at windows

[Aidan Dodds via lldb-dev]

Just to chip in on this thread.
I regularly build X64 LLDB using Visual Studio, but I only use it for 
debugging remote targets.
I have noticed the gtests linking error, but unfortunately due to tight 
time constraints I've not been free to fix it.
I tend to 'unload' all of the projects in Visual Studio that are not 
directly related to building LLDB, so I don't see the linking error 
often.  Also since its not a direct dependency, LLDB still builds fine 
for me.


Fixes are always nice however :)

Last I checked I was able to build LLDB in VS2013 as well as VS2015 
without problems.


On 11/01/2016 18:48, Zachary Turner via lldb-dev wrote:
Yea, unfortunately the way things work is that the person who is 
affected by the problem and who needs it fixed is usually the one that 
needs to fix it.  Right now we don't have any Windows people building 
inside Visual Studio, so nobody has fixed that.  But you're welcome to 
submit a patch :)


FWIW, I actually generate CMake twice, into two separate folders.  I 
have build/vs and build/ninja.  In the vs directory I generate using 
"Visual Studio 14 2015" generator, and in ninja I generate using Ninja 
generator.  I build from the Ninja folder, and I use the vs folder 
just for opening a solution, source browsing, and debugging (i.e. 
change the Debugger settings to point the executable into the ninja 
folder).


This way you still do everything from vs, just not the compile step.

On Mon, Jan 11, 2016 at 9:16 AM Red Skotina > wrote:


thanks. i build successefuly llvm and lldb with ninja and cl
compiler.

If i build VS solution without options on CMake then i have ever
more errors around unittests in llvm.

like that:

"d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) ->
"d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj.metaproj"
(целевой объект по
 умолчанию) (749) ->
"d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj" (целевой
объект по умолчани
ю) (750) ->
(Целевой объект ClCompile) ->
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
C2327: 'll
vm::PointerEmbeddedInt::Value': is not a type name,
static, or enume
rator (compiling source file
D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedInt
Test.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
C2065: 'Va
lue': undeclared identifier (compiling source file
D:\code\llvm\llvm\unittests\
ADT\PointerEmbeddedIntTest.cpp)
[d:\code\llvm\build\unittests\ADT\ADTTests.vcxp
roj]
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
C2327: 'll
vm::PointerEmbeddedInt::Value': is not a type name, static,
or enumerato
r (compiling source file
D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest
.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(34): error
C2338: Can
not embed more bits than we have in a pointer! (compiling source
file D:\code\l
lvm\llvm\unittests\ADT\PointerEmbeddedIntTest.cpp)
[d:\code\llvm\build\unittest
s\ADT\ADTTests.vcxproj]
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error
C2327: 'll
vm::PointerEmbeddedInt::Value': is not a type name, static,
or enumerato
r (compiling source file
D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest
.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error
C2065: 'Va
lue': undeclared identifier (compiling source file
D:\code\llvm\llvm\unittests\
ADT\PointerEmbeddedIntTest.cpp)
[d:\code\llvm\build\unittests\ADT\ADTTests.vcxp
roj]

2016-01-11 0:56 GMT+03:00 Zachary Turner mailto:ztur...@google.com>>:

I have never built with -DLLVM_INCLUDE_TESTS=OFF
-DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before,
so that could be related.  Can you try removing those options
on CMake to see if that fixes it?

The other thing I do differently is I use ninja generator.  So
I use -G Ninja instead of -G "Visual Studio 14 2015". 
Building from within Visual Studio like you're doing is

supposed to work, I just don't know if anyone tests it.  My
command line is usually:

cmake -G Ninja  -DCMAKE_BUILD_TYPE=Release
-DPYTHON_HOME=
..\llvm

ninja


On Sun, Jan 10, 2016 at 4:02 AM Red Skotina
mailto:red.skot...@gmail.com>> wrote:

thanks.
i still have 5 errors while linking
"d:\code\llvm\build\LLVM.sln" (целевой объект по
умолчанию) (1) ->

"d:\code\llvm\build\tools\lldb\unittests\LLDBUnitTests.vcxproj.metaproj"
(целев
ой объект по умолчанию) (741) ->

"d:\cod

Re: [lldb-dev] LLDB build at windows

[Zachary Turner via lldb-dev]

VS 2013 support is going to be deprecated soon.  At that point it could
break any time, because nobody is going to be making an effort to keep it
working.

On Tue, Jan 12, 2016 at 7:54 AM Aidan Dodds via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Just to chip in on this thread.
> I regularly build X64 LLDB using Visual Studio, but I only use it for
> debugging remote targets.
> I have noticed the gtests linking error, but unfortunately due to tight
> time constraints I've not been free to fix it.
> I tend to 'unload' all of the projects in Visual Studio that are not
> directly related to building LLDB, so I don't see the linking error often.
> Also since its not a direct dependency, LLDB still builds fine for me.
>
> Fixes are always nice however :)
>
> Last I checked I was able to build LLDB in VS2013 as well as VS2015
> without problems.
>
>
> On 11/01/2016 18:48, Zachary Turner via lldb-dev wrote:
>
> Yea, unfortunately the way things work is that the person who is affected
> by the problem and who needs it fixed is usually the one that needs to fix
> it.  Right now we don't have any Windows people building inside Visual
> Studio, so nobody has fixed that.  But you're welcome to submit a patch :)
>
> FWIW, I actually generate CMake twice, into two separate folders.  I have
> build/vs and build/ninja.  In the vs directory I generate using "Visual
> Studio 14 2015" generator, and in ninja I generate using Ninja generator.
> I build from the Ninja folder, and I use the vs folder just for opening a
> solution, source browsing, and debugging (i.e. change the Debugger settings
> to point the executable into the ninja folder).
>
> This way you still do everything from vs, just not the compile step.
>
> On Mon, Jan 11, 2016 at 9:16 AM Red Skotina  wrote:
>
>> thanks. i build successefuly llvm and lldb with ninja and cl compiler.
>>
>> If i build VS solution without options on CMake then i have ever more
>> errors around unittests in llvm.
>>
>> like that:
>>
>> "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) ->
>> "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj.metaproj" (целевой
>> объект по
>>  умолчанию) (749) ->
>> "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj" (целевой объект по
>> умолчани
>> ю) (750) ->
>> (Целевой объект ClCompile) ->
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
>> C2327: 'll
>> vm::PointerEmbeddedInt::Value': is not a type name, static, or
>> enume
>> rator (compiling source file
>> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedInt
>> Test.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
>> C2065: 'Va
>> lue': undeclared identifier (compiling source file
>> D:\code\llvm\llvm\unittests\
>> ADT\PointerEmbeddedIntTest.cpp)
>> [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp
>> roj]
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
>> C2327: 'll
>> vm::PointerEmbeddedInt::Value': is not a type name, static, or
>> enumerato
>> r (compiling source file
>> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest
>> .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(34): error
>> C2338: Can
>> not embed more bits than we have in a pointer! (compiling source file
>> D:\code\l
>> lvm\llvm\unittests\ADT\PointerEmbeddedIntTest.cpp)
>> [d:\code\llvm\build\unittest
>> s\ADT\ADTTests.vcxproj]
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error
>> C2327: 'll
>> vm::PointerEmbeddedInt::Value': is not a type name, static, or
>> enumerato
>> r (compiling source file
>> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest
>> .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error
>> C2065: 'Va
>> lue': undeclared identifier (compiling source file
>> D:\code\llvm\llvm\unittests\
>> ADT\PointerEmbeddedIntTest.cpp)
>> [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp
>> roj]
>>
>>
>> 2016-01-11 0:56 GMT+03:00 Zachary Turner :
>>
>>> I have never built with -DLLVM_INCLUDE_TESTS=OFF
>>> -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before, so that
>>> could be related.  Can you try removing those options on CMake to see if
>>> that fixes it?
>>>
>>> The other thing I do differently is I use ninja generator.  So I use -G
>>> Ninja instead of -G "Visual Studio 14 2015".  Building from within Visual
>>> Studio like you're doing is supposed to work, I just don't know if anyone
>>> tests it.  My command line is usually:
>>>
>>> cmake -G Ninja  -DCMAKE_BUILD_TYPE=Release -DPYTHON_HOME=>> to python\x86 from dest variable> ..\llvm
>>>
>>> ninja
>>>
>>>
>>> On Sun, Jan 10, 2016 at 4:02 AM Red Skotina 
>>> wrote:
>>>
 thanks.
 i still have 5 errors while linking
 "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) ->
 "d:\code\llvm\build\tools\lldb\unittests\LLDBUnitTests.v