Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

I don't know an easy way to accomplish that.  While app-local deployment is
now supported, the set of deployed dlls depends on the host OS version
(according to this
).
  I've opened a bug  for now.

On Thu, Jan 12, 2017 at 4:12 PM, Reid Kleckner  wrote:

> On Thu, Jan 12, 2017 at 10:18 AM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I was referring to this: https://support.microsof
>> t.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows.
>> Granted, it was probably marked as non-critical, so some users may have
>> skipped it.
>>
>> >  One of the redist options is to include an MSU in your installer that
>> tells Windows Update to add UCRT to the list of components it updates
>>
>> We should figure out how to do that.
>>
>> But meanwhile, do people here agree that LLVM should be built with the
>> /MD flag?
>>
>
> We should do whatever makes it really simple to add clang to path and run
> it without any DLL conflicts. If it's easy to copy the vc runtime DLLs into
> our package in a compatible way, great, so long as users can unzip the
> package and run it from whereever it is without installing any
> dependencies. Static linking just happens to be the easiest way to achieve
> that.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Reid Kleckner via lldb-dev]

On Thu, Jan 12, 2017 at 10:18 AM, Vadim Chugunov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I was referring to this: https://support.microsoft.com/en-us/help/
> 2999226/update-for-universal-c-runtime-in-windows.   Granted, it was
> probably marked as non-critical, so some users may have skipped it.
>
> >  One of the redist options is to include an MSU in your installer that
> tells Windows Update to add UCRT to the list of components it updates
>
> We should figure out how to do that.
>
> But meanwhile, do people here agree that LLVM should be built with the /MD
> flag?
>

We should do whatever makes it really simple to add clang to path and run
it without any DLL conflicts. If it's easy to copy the vc runtime DLLs into
our package in a compatible way, great, so long as users can unzip the
package and run it from whereever it is without installing any
dependencies. Static linking just happens to be the easiest way to achieve
that.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Nico Weber via lldb-dev]

On Thu, Jan 12, 2017 at 1:18 PM, Vadim Chugunov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I was referring to this: https://support.microsoft.com/en-us/help/
> 2999226/update-for-universal-c-runtime-in-windows.   Granted, it was
> probably marked as non-critical, so some users may have skipped it.
>
> >  One of the redist options is to include an MSU in your installer that
> tells Windows Update to add UCRT to the list of components it updates
>
> We should figure out how to do that.
>
> But meanwhile, do people here agree that LLVM should be built with the /MD
> flag?
>

Like Reid said above, clang should statically link the CRT.


>
>
> On Thu, Jan 12, 2017 at 9:36 AM, Adrian McCarthy 
> wrote:
>
>> >  [UCRT] had been pushed to Vista, 7 and 8 via Windows Update
>>
>> I didn't think that was true in general.  One of the redist options is to
>> include an MSU in your installer that tells Windows Update to add UCRT to
>> the list of components it updates.  So some Vista, 7, and 8 users may have
>> received it via Windows Update, but probably not all.
>>
>> That's what all the deployment articles seem to suggest (assuming I've
>> understood them correctly).  I suppose they may have decided to ship UCRT
>> to pre-Windows 10 users anyway, but I haven't come across anything that
>> says that.
>>
>> On Wed, Jan 11, 2017 at 6:48 PM, Vadim Chugunov 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner 
>>> wrote:
>>>
 Ahh, that would make sense as well, since LLDB links against liblldb as
 a dll.  Don't see a good solution to this short of forcing dynamic linking.
  liblldb has to be a dll because it needs to be visible to python as an
 extension module.  And if it's a dll and uses static linking, then we would
 have to require that lldb.exe not pass file handles across the dll
 boundary.  If that's easy then great, but I suspect it probably isn't.

 Honestly dynamic linking was created to solve exactly these kinds of
 problems.  Yes there's the redist issue if on Windows < 10, but it seems
 like a small price to pay for something that doesn't have weird subtle
 bugs.  And as time goes on, more and more people will be on windows 10
 anyway.

 Does the redistributable issue present a challenge for your use case?

>>>
>>> There are actually two part of the MSVC runtime: the Universal C Runtime
>>> (UCRT) and the compiler-specific, VCRUNTIME140.   The former is widely
>>> available (comes with Windows 10, and had been pushed to Vista, 7 and 8 via
>>> Windows Update).  The latter is tied to the compiler version and must still
>>> be redistributed with programs.   Ideally, LLDB would use dynamic UCRT +
>>> static VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported
>>> configuration (discussion of this issue in Python bug tracker
>>> ).   Looks like Python folks opted
>>> for shipping VCRUNTIME140.DLL in their install directory.
>>>
>>>
>>
>
> ___
> 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

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

I was referring to this:
https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows.
  Granted, it was probably marked as non-critical, so some users may have
skipped it.

>  One of the redist options is to include an MSU in your installer that
tells Windows Update to add UCRT to the list of components it updates

We should figure out how to do that.

But meanwhile, do people here agree that LLVM should be built with the /MD
flag?


On Thu, Jan 12, 2017 at 9:36 AM, Adrian McCarthy 
wrote:

> >  [UCRT] had been pushed to Vista, 7 and 8 via Windows Update
>
> I didn't think that was true in general.  One of the redist options is to
> include an MSU in your installer that tells Windows Update to add UCRT to
> the list of components it updates.  So some Vista, 7, and 8 users may have
> received it via Windows Update, but probably not all.
>
> That's what all the deployment articles seem to suggest (assuming I've
> understood them correctly).  I suppose they may have decided to ship UCRT
> to pre-Windows 10 users anyway, but I haven't come across anything that
> says that.
>
> On Wed, Jan 11, 2017 at 6:48 PM, Vadim Chugunov  wrote:
>
>>
>>
>> On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner 
>> wrote:
>>
>>> Ahh, that would make sense as well, since LLDB links against liblldb as
>>> a dll.  Don't see a good solution to this short of forcing dynamic linking.
>>>  liblldb has to be a dll because it needs to be visible to python as an
>>> extension module.  And if it's a dll and uses static linking, then we would
>>> have to require that lldb.exe not pass file handles across the dll
>>> boundary.  If that's easy then great, but I suspect it probably isn't.
>>>
>>> Honestly dynamic linking was created to solve exactly these kinds of
>>> problems.  Yes there's the redist issue if on Windows < 10, but it seems
>>> like a small price to pay for something that doesn't have weird subtle
>>> bugs.  And as time goes on, more and more people will be on windows 10
>>> anyway.
>>>
>>> Does the redistributable issue present a challenge for your use case?
>>>
>>
>> There are actually two part of the MSVC runtime: the Universal C Runtime
>> (UCRT) and the compiler-specific, VCRUNTIME140.   The former is widely
>> available (comes with Windows 10, and had been pushed to Vista, 7 and 8 via
>> Windows Update).  The latter is tied to the compiler version and must still
>> be redistributed with programs.   Ideally, LLDB would use dynamic UCRT +
>> static VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported
>> configuration (discussion of this issue in Python bug tracker
>> ).   Looks like Python folks opted
>> for shipping VCRUNTIME140.DLL in their install directory.
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Adrian McCarthy via lldb-dev]

>  [UCRT] had been pushed to Vista, 7 and 8 via Windows Update

I didn't think that was true in general.  One of the redist options is to
include an MSU in your installer that tells Windows Update to add UCRT to
the list of components it updates.  So some Vista, 7, and 8 users may have
received it via Windows Update, but probably not all.

That's what all the deployment articles seem to suggest (assuming I've
understood them correctly).  I suppose they may have decided to ship UCRT
to pre-Windows 10 users anyway, but I haven't come across anything that
says that.

On Wed, Jan 11, 2017 at 6:48 PM, Vadim Chugunov  wrote:

>
>
> On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner 
> wrote:
>
>> Ahh, that would make sense as well, since LLDB links against liblldb as a
>> dll.  Don't see a good solution to this short of forcing dynamic linking.
>>  liblldb has to be a dll because it needs to be visible to python as an
>> extension module.  And if it's a dll and uses static linking, then we would
>> have to require that lldb.exe not pass file handles across the dll
>> boundary.  If that's easy then great, but I suspect it probably isn't.
>>
>> Honestly dynamic linking was created to solve exactly these kinds of
>> problems.  Yes there's the redist issue if on Windows < 10, but it seems
>> like a small price to pay for something that doesn't have weird subtle
>> bugs.  And as time goes on, more and more people will be on windows 10
>> anyway.
>>
>> Does the redistributable issue present a challenge for your use case?
>>
>
> There are actually two part of the MSVC runtime: the Universal C Runtime
> (UCRT) and the compiler-specific, VCRUNTIME140.   The former is widely
> available (comes with Windows 10, and had been pushed to Vista, 7 and 8 via
> Windows Update).  The latter is tied to the compiler version and must still
> be redistributed with programs.   Ideally, LLDB would use dynamic UCRT +
> static VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported
> configuration (discussion of this issue in Python bug tracker
> ).   Looks like Python folks opted
> for shipping VCRUNTIME140.DLL in their install directory.
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Ted Woodward via lldb-dev]

The compiler redistributable is also widely available:

 

https://www.microsoft.com/en-us/download/details.aspx?id=48145

 

The python 3.5 dll would still use the runtime dll; lldb should do the same. 
I’ve had crashes in the past because lldb and python used different runtimes.

 

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Vadim 
Chugunov via lldb-dev
Sent: Wednesday, January 11, 2017 8:49 PM
To: Zachary Turner <ztur...@google.com>
Cc: LLDB <lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] Prebuilt binary for Windows

 

 

 

On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner <ztur...@google.com 
<mailto:ztur...@google.com> > wrote:

Ahh, that would make sense as well, since LLDB links against liblldb as a dll.  
Don't see a good solution to this short of forcing dynamic linking.  liblldb 
has to be a dll because it needs to be visible to python as an extension 
module.  And if it's a dll and uses static linking, then we would have to 
require that lldb.exe not pass file handles across the dll boundary.  If that's 
easy then great, but I suspect it probably isn't.  

 

Honestly dynamic linking was created to solve exactly these kinds of problems.  
Yes there's the redist issue if on Windows < 10, but it seems like a small 
price to pay for something that doesn't have weird subtle bugs.  And as time 
goes on, more and more people will be on windows 10 anyway.

 

Does the redistributable issue present a challenge for your use case?

 

There are actually two part of the MSVC runtime: the Universal C Runtime (UCRT) 
and the compiler-specific, VCRUNTIME140.   The former is widely available 
(comes with Windows 10, and had been pushed to Vista, 7 and 8 via Windows 
Update).  The latter is tied to the compiler version and must still be 
redistributed with programs.   Ideally, LLDB would use dynamic UCRT + static 
VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported configuration 
(discussion of this issue in Python bug tracker 
<https://bugs.python.org/issue24872> ).   Looks like Python folks opted for 
shipping VCRUNTIME140.DLL in their install directory.

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner  wrote:

> Ahh, that would make sense as well, since LLDB links against liblldb as a
> dll.  Don't see a good solution to this short of forcing dynamic linking.
>  liblldb has to be a dll because it needs to be visible to python as an
> extension module.  And if it's a dll and uses static linking, then we would
> have to require that lldb.exe not pass file handles across the dll
> boundary.  If that's easy then great, but I suspect it probably isn't.
>
> Honestly dynamic linking was created to solve exactly these kinds of
> problems.  Yes there's the redist issue if on Windows < 10, but it seems
> like a small price to pay for something that doesn't have weird subtle
> bugs.  And as time goes on, more and more people will be on windows 10
> anyway.
>
> Does the redistributable issue present a challenge for your use case?
>

There are actually two part of the MSVC runtime: the Universal C Runtime
(UCRT) and the compiler-specific, VCRUNTIME140.   The former is widely
available (comes with Windows 10, and had been pushed to Vista, 7 and 8 via
Windows Update).  The latter is tied to the compiler version and must still
be redistributed with programs.   Ideally, LLDB would use dynamic UCRT +
static VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported
configuration (discussion of this issue in Python bug tracker
).   Looks like Python folks opted for
shipping VCRUNTIME140.DLL in their install directory.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

Ahh, that would make sense as well, since LLDB links against liblldb as a
dll.  Don't see a good solution to this short of forcing dynamic linking.
 liblldb has to be a dll because it needs to be visible to python as an
extension module.  And if it's a dll and uses static linking, then we would
have to require that lldb.exe not pass file handles across the dll
boundary.  If that's easy then great, but I suspect it probably isn't.

Honestly dynamic linking was created to solve exactly these kinds of
problems.  Yes there's the redist issue if on Windows < 10, but it seems
like a small price to pay for something that doesn't have weird subtle
bugs.  And as time goes on, more and more people will be on windows 10
anyway.

Does the redistributable issue present a challenge for your use case?

On Wed, Jan 11, 2017 at 3:45 PM Vadim Chugunov  wrote:

> Okay, as far as I can see, the issue is not with Python, but that lldb.exe
> and liblldb.dll have their own private copies of the CRT.
>
> When startup script is given on the command line, lldb.exe creates a pipe,
> writes the script into the write end, wraps a stdio file around the read
> end, and gives the resulting FILE* to SBDebugger::SetInputFileHandle().
> Unfortunately, since SBDebugger lives in liblldb.dll, with its own copy of
> the CRT, that handle is not valid there.  Later, it tries to read from that
> handle, and... boom.
> ​
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

Okay, as far as I can see, the issue is not with Python, but that lldb.exe
and liblldb.dll have their own private copies of the CRT.

When startup script is given on the command line, lldb.exe creates a pipe,
writes the script into the write end, wraps a stdio file around the read
end, and gives the resulting FILE* to SBDebugger::SetInputFileHandle().
Unfortunately, since SBDebugger lives in liblldb.dll, with its own copy of
the CRT, that handle is not valid there.  Later, it tries to read from that
handle, and... boom.
​
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

On Wed, Jan 11, 2017 at 1:47 PM Vadim Chugunov  wrote:

> > Definitely seems CRT / Python related.  The call to fgets indicates that
> it's doing something involving a FILE*.  It's probably a FILE* that refers
> to a file created from within Python's copy of the CRT.
>
> Any idea where in the code would that be?  Would be nice to confirm.
>

Maybe in ScriptInterpreterPython somewhere?  There's a couple of places
where we use FILE* in that file, but it's not easy to tell by inspection
whether the FILE*'s originate from something in Python.

More likely perhaps is to try putting a breakpoint in PythonDataObjects.cpp
line 983 (called when try to create a wrapper around a Python File object
so we can reference it from C++) and Line 1010 (called when we try to
create a Python file object out of a native file descriptor).  These are
the two major API boundaries where we convert between native file
descriptors and python file objects.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

Definitely seems CRT / Python related.  The call to fgets indicates that
it's doing something involving a FILE*.  It's probably a FILE* that refers
to a file created from within Python's copy of the CRT.  Another problem
that dynamic linking would solve.  Can you confirm that the problem does
not occur when LLDB links dynamically?

On Wed, Jan 11, 2017 at 1:14 PM Vadim Chugunov  wrote:

> BTW, here's the call stack at the point of failure.   I don't see anything
> Python-related in it, so maybe it's some other CRT interaction.
>
> liblldb!_invoke_watson(wchar_t * expression = 0x "", wchar_t *
> function_name = 0x "", wchar_t * file_name = 0x "",
> unsigned int line_number = 0, unsigned int reserved = 0)+0xe
> liblldb!_invalid_parameter(wchar_t * expression =  error>, wchar_t * function_name = , wchar_t *
> file_name = , unsigned int line_number =  unavailable error>, unsigned int reserved = )+0x7a
> liblldb!_invalid_parameter_noinfo(void)+0xc
> liblldb!_read(int fh = 0n0, void * buffer = 0x05afbb50, unsigned int
> buffer_size = 0x1000)+0x10a
> liblldb!common_refill_and_read_nolock(class __crt_stdio_stream
> stream = class __crt_stdio_stream)+0x9f
> liblldb!_fgetc_nolock(struct _iobuf * public_stream = 0x05af9c58)+0x2d
> liblldb!__crt_char_traits::getc_nolock+0x8
> liblldb!common_fgets(char * string = 0x019cf41c "b", int count =
> 0n256, class __crt_stdio_stream stream = class __crt_stdio_stream)+0x81
> liblldb!lldb_private::IOHandlerEditline::GetLine(class
> std::basic_string * line
> = 0x019cf548 "", bool * interrupted = 0x019cf537)+0xd6
> liblldb!lldb_private::IOHandlerEditline::Run(void)+0x11a
> liblldb!lldb_private::Debugger::ExecuteIOHandlers(void)+0x35
> liblldb!lldb_private::CommandInterpreter::RunCommandInterpreter(bool
> auto_handle_events = true, bool spawn_thread = false, class
> lldb_private::CommandInterpreterRunOptions * options = 0x05af9ca8)+0x7e
> liblldb!lldb::SBDebugger::RunCommandInterpreter(bool auto_handle_events =
> true, bool spawn_thread = false, class lldb::SBCommandInterpreterRunOptions
> * options = 0x019cf604, int * num_errors = 0x019cf630, bool *
> quit_requested = 0x019cf603, bool * stopped_for_crash = 0x019cf60a)+0x43
> lldb!Driver::MainLoop(void)+0x639
> lldb!wmain(int argc = 0n3, wchar_t ** wargv = 0x01b28c90)+0x249
> lldb!invoke_main+0x1d
> lldb!__scrt_common_main_seh(void)+0xff
> KERNEL32!BaseThreadInitThunk+0x24
> ntdll_76f3!__RtlUserThreadStart+0x2f
> ntdll_76f3!_RtlUserThreadStart+0x1b
>
> On Wed, Jan 11, 2017 at 1:10 PM, Adrian McCarthy via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I agree that linking to them dynamically is safer, but then you get into
> the deployment problem.  You do have to redistribute the DLLs for users
> using anything less than Windows 10.
>
> There are several options for doing that:  VCRedist, MSMs, MSUs, and
> app-local deployment.  They each have drawbacks.
>
> On Wed, Jan 11, 2017 at 1:00 PM, Zachary Turner 
> wrote:
>
> If we do that though, we still get 2 copies of the CRT.  One for python
> and one for LLDB.  While I *think* there is a strong enough API boundary in
> how the application and Python access each others' data structures that it
> doesn't matter, I'm not 100% sure without further research.  It seems safer
> to link dynamically unless there is a strong reason not to.
>
> On Wed, Jan 11, 2017 at 12:41 PM Adrian McCarthy 
> wrote:
>
> I was just reading up on this the other day.  Statically linking to the
> Universal CRT (and related libraries) *is* supported though it's not
> Microsoft's top recommendation.
>
> Initially, they said they weren't going to support app-local deployment,
> but they backed off on that, and it, too, is now supported.
>
> Some details here:
> https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/
>
>
> On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> The purpose of linking the CRT statically was to ensure that clang can run
> on systems that don't have the CRT already installed from some other app or
> by VS itself. As long as that is preserved, feel free to do whatever you
> need.
>
> I think we still want to link vcruntime140 statically and the C++ runtime
> statically, for example.
>
> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Is static CRT even still supported / recommended when using the new
> Universal CRT?  My understanding is the new UCRT is considered a core
> windows component, so we don't ahve to distribute redistributables
> anymore.  Maybe I'm wrong about this.
>
> That said, I think we want dynamic regardless, otherwise we're back in the
> same boat of user having to compile Python, which is the exact thing 3.5+
> is supposed to solve.  We should just always use dynamic so the user
> doesn't have to 

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

BTW, here's the call stack at the point of failure.   I don't see anything
Python-related in it, so maybe it's some other CRT interaction.

liblldb!_invoke_watson(wchar_t * expression = 0x "", wchar_t *
function_name = 0x "", wchar_t * file_name = 0x "",
unsigned int line_number = 0, unsigned int reserved = 0)+0xe
liblldb!_invalid_parameter(wchar_t * expression = , wchar_t * function_name = , wchar_t *
file_name = , unsigned int line_number = , unsigned int reserved = )+0x7a
liblldb!_invalid_parameter_noinfo(void)+0xc
liblldb!_read(int fh = 0n0, void * buffer = 0x05afbb50, unsigned int
buffer_size = 0x1000)+0x10a
liblldb!common_refill_and_read_nolock(class __crt_stdio_stream stream
= class __crt_stdio_stream)+0x9f
liblldb!_fgetc_nolock(struct _iobuf * public_stream = 0x05af9c58)+0x2d
liblldb!__crt_char_traits::getc_nolock+0x8
liblldb!common_fgets(char * string = 0x019cf41c "b", int count =
0n256, class __crt_stdio_stream stream = class __crt_stdio_stream)+0x81
liblldb!lldb_private::IOHandlerEditline::GetLine(class
std::basic_string * line
= 0x019cf548 "", bool * interrupted = 0x019cf537)+0xd6
liblldb!lldb_private::IOHandlerEditline::Run(void)+0x11a
liblldb!lldb_private::Debugger::ExecuteIOHandlers(void)+0x35
liblldb!lldb_private::CommandInterpreter::RunCommandInterpreter(bool
auto_handle_events = true, bool spawn_thread = false, class
lldb_private::CommandInterpreterRunOptions * options = 0x05af9ca8)+0x7e
liblldb!lldb::SBDebugger::RunCommandInterpreter(bool auto_handle_events =
true, bool spawn_thread = false, class lldb::SBCommandInterpreterRunOptions
* options = 0x019cf604, int * num_errors = 0x019cf630, bool *
quit_requested = 0x019cf603, bool * stopped_for_crash = 0x019cf60a)+0x43
lldb!Driver::MainLoop(void)+0x639
lldb!wmain(int argc = 0n3, wchar_t ** wargv = 0x01b28c90)+0x249
lldb!invoke_main+0x1d
lldb!__scrt_common_main_seh(void)+0xff
KERNEL32!BaseThreadInitThunk+0x24
ntdll_76f3!__RtlUserThreadStart+0x2f
ntdll_76f3!_RtlUserThreadStart+0x1b

On Wed, Jan 11, 2017 at 1:10 PM, Adrian McCarthy via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I agree that linking to them dynamically is safer, but then you get into
> the deployment problem.  You do have to redistribute the DLLs for users
> using anything less than Windows 10.
>
> There are several options for doing that:  VCRedist, MSMs, MSUs, and
> app-local deployment.  They each have drawbacks.
>
> On Wed, Jan 11, 2017 at 1:00 PM, Zachary Turner 
> wrote:
>
>> If we do that though, we still get 2 copies of the CRT.  One for python
>> and one for LLDB.  While I *think* there is a strong enough API boundary in
>> how the application and Python access each others' data structures that it
>> doesn't matter, I'm not 100% sure without further research.  It seems safer
>> to link dynamically unless there is a strong reason not to.
>>
>> On Wed, Jan 11, 2017 at 12:41 PM Adrian McCarthy 
>> wrote:
>>
>>> I was just reading up on this the other day.  Statically linking to the
>>> Universal CRT (and related libraries) *is* supported though it's not
>>> Microsoft's top recommendation.
>>>
>>> Initially, they said they weren't going to support app-local deployment,
>>> but they backed off on that, and it, too, is now supported.
>>>
>>> Some details here:  https://blogs.msdn.microsoft.
>>> com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/
>>>
>>>
>>> On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> The purpose of linking the CRT statically was to ensure that clang can
>>> run on systems that don't have the CRT already installed from some other
>>> app or by VS itself. As long as that is preserved, feel free to do whatever
>>> you need.
>>>
>>> I think we still want to link vcruntime140 statically and the C++
>>> runtime statically, for example.
>>>
>>> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Is static CRT even still supported / recommended when using the new
>>> Universal CRT?  My understanding is the new UCRT is considered a core
>>> windows component, so we don't ahve to distribute redistributables
>>> anymore.  Maybe I'm wrong about this.
>>>
>>> That said, I think we want dynamic regardless, otherwise we're back in
>>> the same boat of user having to compile Python, which is the exact thing
>>> 3.5+ is supposed to solve.  We should just always use dynamic so the user
>>> doesn't have to do anything and it just works.
>>>
>>> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov 
>>> wrote:
>>>
>>> Sorry, just found another problem: the installed lldb crashes when given
>>> a script via the command line.  For example, `lldb -O "p 42"` dies with
>>> exception 0xC409.
>>>
>>> It didn't happen with the one I've build locally, so I started
>>> digging... The difference seems to be that 

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

If we do that though, we still get 2 copies of the CRT.  One for python and
one for LLDB.  While I *think* there is a strong enough API boundary in how
the application and Python access each others' data structures that it
doesn't matter, I'm not 100% sure without further research.  It seems safer
to link dynamically unless there is a strong reason not to.

On Wed, Jan 11, 2017 at 12:41 PM Adrian McCarthy 
wrote:

> I was just reading up on this the other day.  Statically linking to the
> Universal CRT (and related libraries) *is* supported though it's not
> Microsoft's top recommendation.
>
> Initially, they said they weren't going to support app-local deployment,
> but they backed off on that, and it, too, is now supported.
>
> Some details here:
> https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/
>
>
> On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> The purpose of linking the CRT statically was to ensure that clang can run
> on systems that don't have the CRT already installed from some other app or
> by VS itself. As long as that is preserved, feel free to do whatever you
> need.
>
> I think we still want to link vcruntime140 statically and the C++ runtime
> statically, for example.
>
> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Is static CRT even still supported / recommended when using the new
> Universal CRT?  My understanding is the new UCRT is considered a core
> windows component, so we don't ahve to distribute redistributables
> anymore.  Maybe I'm wrong about this.
>
> That said, I think we want dynamic regardless, otherwise we're back in the
> same boat of user having to compile Python, which is the exact thing 3.5+
> is supposed to solve.  We should just always use dynamic so the user
> doesn't have to do anything and it just works.
>
> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov  wrote:
>
> Sorry, just found another problem: the installed lldb crashes when given a
> script via the command line.  For example, `lldb -O "p 42"` dies with
> exception 0xC409.
>
> It didn't happen with the one I've build locally, so I started digging...
> The difference seems to be that build_llvm_build_package.bat links CRT
> statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.
>
> The crash kinda makes sense, because python35.dll links CRT dynamically,
> so LLDB ends up with two copies of it in the process, which is known to
> cause all sorts of trouble.
>
> Not sure what to do about this one, - you probably wanted static CRT to
> avoid having to install MSVC redistributable?
>
>
> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov  wrote:
>
> Yes, the new build works!
>
> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>
> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
> Please let me know if that works.
>
> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
> wrote:
> > It sounds like the solution to the problem is to downgrade SWIG on the
> build
> > machine.  If it's using version 3.0.9 or higher, just use whatever the
> last
> > version before that is.  3.0.8, for example.
> >
> > At least there's a good workaround in the interim (i.e. setting
> PYTHONPATH)
> >
> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
> wrote:
> >>
> >> I'll do another snapshot maybe next week or the week after. You can
> >> also ping me if you want it sooner or later.
> >>
> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
> >> fully understand the problem here, but if there's some way to work
> >> around it and get lldb into good shape for the 4.0.0 installer, that
> >> would be great.
> >>
> >> Thanks,
> >> Hans
> >>
> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
> wrote:
> >> > This appears to be a SWIG bug:
> https://github.com/swig/swig/issues/769
> >> >
> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
> >> > wrote:
> >> >>
> >> >> It worked!
> >> >>
> >> >> ...but not before I set PYTHONPATH=C:\Program Files
> >> >> (x86)\LLVM\lib\site-packages\lldb
> >> >> Without that, it couldn't find the _lldb module, so we are not quite
> >> >> out
> >> >> of the woods yet.
> >> >>
> >> >> When are you planning to make the next snapshot build?
> >> >> Thanks!
> >> >>
> >> >>
> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
> >> >> wrote:
> >> >>>
> >> >>> Vadim, it looks like your change was committed in r291291, and I've
> >> >>> built a new snapshot today which includes it. Can you give it a try
> >> >>> and see if everything works?
> >> >>>
> >> >>> Cheers,
> >> >>> Hans
> >> >>>
> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner  >
> >> >>> wrote:
> >> >>> > I will commit it, in the 

Re: [lldb-dev] Prebuilt binary for Windows

[Reid Kleckner via lldb-dev]

The purpose of linking the CRT statically was to ensure that clang can run
on systems that don't have the CRT already installed from some other app or
by VS itself. As long as that is preserved, feel free to do whatever you
need.

I think we still want to link vcruntime140 statically and the C++ runtime
statically, for example.

On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Is static CRT even still supported / recommended when using the new
> Universal CRT?  My understanding is the new UCRT is considered a core
> windows component, so we don't ahve to distribute redistributables
> anymore.  Maybe I'm wrong about this.
>
> That said, I think we want dynamic regardless, otherwise we're back in the
> same boat of user having to compile Python, which is the exact thing 3.5+
> is supposed to solve.  We should just always use dynamic so the user
> doesn't have to do anything and it just works.
>
> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov  wrote:
>
>> Sorry, just found another problem: the installed lldb crashes when given
>> a script via the command line.  For example, `lldb -O "p 42"` dies with
>> exception 0xC409.
>>
>> It didn't happen with the one I've build locally, so I started digging...
>> The difference seems to be that build_llvm_build_package.bat links CRT
>> statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.
>>
>> The crash kinda makes sense, because python35.dll links CRT dynamically,
>> so LLDB ends up with two copies of it in the process, which is known to
>> cause all sorts of trouble.
>>
>> Not sure what to do about this one, - you probably wanted static CRT to
>> avoid having to install MSVC redistributable?
>>
>>
>> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov 
>> wrote:
>>
>> Yes, the new build works!
>>
>> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>>
>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>> Please let me know if that works.
>>
>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>> wrote:
>> > It sounds like the solution to the problem is to downgrade SWIG on the
>> build
>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>> last
>> > version before that is.  3.0.8, for example.
>> >
>> > At least there's a good workaround in the interim (i.e. setting
>> PYTHONPATH)
>> >
>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>> wrote:
>> >>
>> >> I'll do another snapshot maybe next week or the week after. You can
>> >> also ping me if you want it sooner or later.
>> >>
>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> >> fully understand the problem here, but if there's some way to work
>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>> >> would be great.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>> wrote:
>> >> > This appears to be a SWIG bug: https://github.com/swig/swig/
>> issues/769
>> >> >
>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> >> > wrote:
>> >> >>
>> >> >> It worked!
>> >> >>
>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> >> (x86)\LLVM\lib\site-packages\lldb
>> >> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> >> out
>> >> >> of the woods yet.
>> >> >>
>> >> >> When are you planning to make the next snapshot build?
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> >> wrote:
>> >> >>>
>> >> >>> Vadim, it looks like your change was committed in r291291, and I've
>> >> >>> built a new snapshot today which includes it. Can you give it a try
>> >> >>> and see if everything works?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Hans
>> >> >>>
>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner <
>> ztur...@google.com>
>> >> >>> wrote:
>> >> >>> > I will commit it, in the meantime can you request commit access
>> so
>> >> >>> > that
>> >> >>> > any
>> >> >>> > future patches you can commit?
>> >> >>> >
>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov > >
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Thanks!
>> >> >>> >>
>> >> >>> >> Would anyone be so kind to commit that?
>> >> >>> >>
>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>> >> >>> >> 
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> Sorry, a combination of national holidays and extended
>> vacations
>> >> >>> >>> happened
>> >> >>> >>> and this fell off my radar.  lgtm
>> >> >>> >>>
>> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov <
>> vadi...@gmail.com>
>> >> >>> >>> wrote:
>> >> >>> 
>> >> >>>  Zachary,
>> >> >>>  Can you please take a look at that change?
>> >> >>>  (https://reviews.llvm.org/D27476)
>> >> >>> 
>> 

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

Is static CRT even still supported / recommended when using the new
Universal CRT?  My understanding is the new UCRT is considered a core
windows component, so we don't ahve to distribute redistributables
anymore.  Maybe I'm wrong about this.

That said, I think we want dynamic regardless, otherwise we're back in the
same boat of user having to compile Python, which is the exact thing 3.5+
is supposed to solve.  We should just always use dynamic so the user
doesn't have to do anything and it just works.

On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov  wrote:

> Sorry, just found another problem: the installed lldb crashes when given a
> script via the command line.  For example, `lldb -O "p 42"` dies with
> exception 0xC409.
>
> It didn't happen with the one I've build locally, so I started digging...
> The difference seems to be that build_llvm_build_package.bat links CRT
> statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.
>
> The crash kinda makes sense, because python35.dll links CRT dynamically,
> so LLDB ends up with two copies of it in the process, which is known to
> cause all sorts of trouble.
>
> Not sure what to do about this one, - you probably wanted static CRT to
> avoid having to install MSVC redistributable?
>
>
> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov  wrote:
>
> Yes, the new build works!
>
> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>
> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
> Please let me know if that works.
>
> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
> wrote:
> > It sounds like the solution to the problem is to downgrade SWIG on the
> build
> > machine.  If it's using version 3.0.9 or higher, just use whatever the
> last
> > version before that is.  3.0.8, for example.
> >
> > At least there's a good workaround in the interim (i.e. setting
> PYTHONPATH)
> >
> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
> wrote:
> >>
> >> I'll do another snapshot maybe next week or the week after. You can
> >> also ping me if you want it sooner or later.
> >>
> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
> >> fully understand the problem here, but if there's some way to work
> >> around it and get lldb into good shape for the 4.0.0 installer, that
> >> would be great.
> >>
> >> Thanks,
> >> Hans
> >>
> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
> wrote:
> >> > This appears to be a SWIG bug:
> https://github.com/swig/swig/issues/769
> >> >
> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
> >> > wrote:
> >> >>
> >> >> It worked!
> >> >>
> >> >> ...but not before I set PYTHONPATH=C:\Program Files
> >> >> (x86)\LLVM\lib\site-packages\lldb
> >> >> Without that, it couldn't find the _lldb module, so we are not quite
> >> >> out
> >> >> of the woods yet.
> >> >>
> >> >> When are you planning to make the next snapshot build?
> >> >> Thanks!
> >> >>
> >> >>
> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
> >> >> wrote:
> >> >>>
> >> >>> Vadim, it looks like your change was committed in r291291, and I've
> >> >>> built a new snapshot today which includes it. Can you give it a try
> >> >>> and see if everything works?
> >> >>>
> >> >>> Cheers,
> >> >>> Hans
> >> >>>
> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner  >
> >> >>> wrote:
> >> >>> > I will commit it, in the meantime can you request commit access so
> >> >>> > that
> >> >>> > any
> >> >>> > future patches you can commit?
> >> >>> >
> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> Thanks!
> >> >>> >>
> >> >>> >> Would anyone be so kind to commit that?
> >> >>> >>
> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
> >> >>> >> 
> >> >>> >> wrote:
> >> >>> >>>
> >> >>> >>> Sorry, a combination of national holidays and extended vacations
> >> >>> >>> happened
> >> >>> >>> and this fell off my radar.  lgtm
> >> >>> >>>
> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov <
> vadi...@gmail.com>
> >> >>> >>> wrote:
> >> >>> 
> >> >>>  Zachary,
> >> >>>  Can you please take a look at that change?
> >> >>>  (https://reviews.llvm.org/D27476)
> >> >>> 
> >> >>>  It'll be sad if another snapshot build gets published with
> broken
> >> >>>  lldb.
> >> >>>  :(
> >> >>> 
> >> >>> 
> >> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
> >> >>>  
> >> >>>  wrote:
> >> >>> >
> >> >>> > This seems to work: https://reviews.llvm.org/D27476
> >> >>> >
> >> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
> >> >>> > 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> The only thing needed to build the installer should be having
> 

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

Sorry, just found another problem: the installed lldb crashes when given a
script via the command line.  For example, `lldb -O "p 42"` dies with
exception 0xC409.

It didn't happen with the one I've build locally, so I started digging...
The difference seems to be that build_llvm_build_package.bat links CRT
statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.

The crash kinda makes sense, because python35.dll links CRT dynamically, so
LLDB ends up with two copies of it in the process, which is known to cause
all sorts of trouble.

Not sure what to do about this one, - you probably wanted static CRT to
avoid having to install MSVC redistributable?


On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov  wrote:

> Yes, the new build works!
>
> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>
>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>> Please let me know if that works.
>>
>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>> wrote:
>> > It sounds like the solution to the problem is to downgrade SWIG on the
>> build
>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>> last
>> > version before that is.  3.0.8, for example.
>> >
>> > At least there's a good workaround in the interim (i.e. setting
>> PYTHONPATH)
>> >
>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>> wrote:
>> >>
>> >> I'll do another snapshot maybe next week or the week after. You can
>> >> also ping me if you want it sooner or later.
>> >>
>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> >> fully understand the problem here, but if there's some way to work
>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>> >> would be great.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>> wrote:
>> >> > This appears to be a SWIG bug: https://github.com/swig/swig/i
>> ssues/769
>> >> >
>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> >> > wrote:
>> >> >>
>> >> >> It worked!
>> >> >>
>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> >> (x86)\LLVM\lib\site-packages\lldb
>> >> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> >> out
>> >> >> of the woods yet.
>> >> >>
>> >> >> When are you planning to make the next snapshot build?
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> >> wrote:
>> >> >>>
>> >> >>> Vadim, it looks like your change was committed in r291291, and I've
>> >> >>> built a new snapshot today which includes it. Can you give it a try
>> >> >>> and see if everything works?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Hans
>> >> >>>
>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner <
>> ztur...@google.com>
>> >> >>> wrote:
>> >> >>> > I will commit it, in the meantime can you request commit access
>> so
>> >> >>> > that
>> >> >>> > any
>> >> >>> > future patches you can commit?
>> >> >>> >
>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov > >
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Thanks!
>> >> >>> >>
>> >> >>> >> Would anyone be so kind to commit that?
>> >> >>> >>
>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>> >> >>> >> 
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> Sorry, a combination of national holidays and extended
>> vacations
>> >> >>> >>> happened
>> >> >>> >>> and this fell off my radar.  lgtm
>> >> >>> >>>
>> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov <
>> vadi...@gmail.com>
>> >> >>> >>> wrote:
>> >> >>> 
>> >> >>>  Zachary,
>> >> >>>  Can you please take a look at that change?
>> >> >>>  (https://reviews.llvm.org/D27476)
>> >> >>> 
>> >> >>>  It'll be sad if another snapshot build gets published with
>> broken
>> >> >>>  lldb.
>> >> >>>  :(
>> >> >>> 
>> >> >>> 
>> >> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
>> >> >>>  
>> >> >>>  wrote:
>> >> >>> >
>> >> >>> > This seems to work: https://reviews.llvm.org/D27476
>> >> >>> >
>> >> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
>> >> >>> > 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> The only thing needed to build the installer should be
>> having
>> >> >>> >> NSIS
>> >> >>> >> installed and building the "package" target generated by
>> CMake.
>> >> >>> >> The
>> >> >>> >> other prerequisites are mostly for building the visual
>> studio
>> >> >>> >> clang-format plugin.
>> >> >>> >>
>> >> >>> >> Having said that, you don't even have to build the
>> installer to
>> >> >>> >> see
>> >> >>> >> what goes in it. Just building the "install" target
>> generated
>> >> >>> >> by
>> >> >>> >> CMake
>> 

Re: [lldb-dev] Prebuilt binary for Windows

[Hans Wennborg via lldb-dev]

Great! Thanks for pushing this.

On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov  wrote:
> Yes, the new build works!
>
> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>>
>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>> Please let me know if that works.
>>
>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>> wrote:
>> > It sounds like the solution to the problem is to downgrade SWIG on the
>> > build
>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>> > last
>> > version before that is.  3.0.8, for example.
>> >
>> > At least there's a good workaround in the interim (i.e. setting
>> > PYTHONPATH)
>> >
>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>> > wrote:
>> >>
>> >> I'll do another snapshot maybe next week or the week after. You can
>> >> also ping me if you want it sooner or later.
>> >>
>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> >> fully understand the problem here, but if there's some way to work
>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>> >> would be great.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>> >> wrote:
>> >> > This appears to be a SWIG bug:
>> >> > https://github.com/swig/swig/issues/769
>> >> >
>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> >> > wrote:
>> >> >>
>> >> >> It worked!
>> >> >>
>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> >> (x86)\LLVM\lib\site-packages\lldb
>> >> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> >> out
>> >> >> of the woods yet.
>> >> >>
>> >> >> When are you planning to make the next snapshot build?
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> >> wrote:
>> >> >>>
>> >> >>> Vadim, it looks like your change was committed in r291291, and I've
>> >> >>> built a new snapshot today which includes it. Can you give it a try
>> >> >>> and see if everything works?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Hans
>> >> >>>
>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner
>> >> >>> 
>> >> >>> wrote:
>> >> >>> > I will commit it, in the meantime can you request commit access
>> >> >>> > so
>> >> >>> > that
>> >> >>> > any
>> >> >>> > future patches you can commit?
>> >> >>> >
>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Thanks!
>> >> >>> >>
>> >> >>> >> Would anyone be so kind to commit that?
>> >> >>> >>
>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>> >> >>> >> 
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> Sorry, a combination of national holidays and extended
>> >> >>> >>> vacations
>> >> >>> >>> happened
>> >> >>> >>> and this fell off my radar.  lgtm
>> >> >>> >>>
>> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov
>> >> >>> >>> 
>> >> >>> >>> wrote:
>> >> >>> 
>> >> >>>  Zachary,
>> >> >>>  Can you please take a look at that change?
>> >> >>>  (https://reviews.llvm.org/D27476)
>> >> >>> 
>> >> >>>  It'll be sad if another snapshot build gets published with
>> >> >>>  broken
>> >> >>>  lldb.
>> >> >>>  :(
>> >> >>> 
>> >> >>> 
>> >> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
>> >> >>>  
>> >> >>>  wrote:
>> >> >>> >
>> >> >>> > This seems to work: https://reviews.llvm.org/D27476
>> >> >>> >
>> >> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
>> >> >>> > 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> The only thing needed to build the installer should be
>> >> >>> >> having
>> >> >>> >> NSIS
>> >> >>> >> installed and building the "package" target generated by
>> >> >>> >> CMake.
>> >> >>> >> The
>> >> >>> >> other prerequisites are mostly for building the visual
>> >> >>> >> studio
>> >> >>> >> clang-format plugin.
>> >> >>> >>
>> >> >>> >> Having said that, you don't even have to build the installer
>> >> >>> >> to
>> >> >>> >> see
>> >> >>> >> what goes in it. Just building the "install" target
>> >> >>> >> generated
>> >> >>> >> by
>> >> >>> >> CMake
>> >> >>> >> will install the same set of files.
>> >> >>> >>
>> >> >>> >> I'm not sure how LLDB's cmake files are organized, but in
>> >> >>> >> the
>> >> >>> >> end
>> >> >>> >> what's required is invoking the install() command:
>> >> >>> >> https://cmake.org/cmake/help/v3.0/command/install.html  In
>> >> >>> >> LLVM,
>> >> >>> >> this
>> >> >>> >> is done automatically by macros such as add_llvm_executale,
>> >> >>> >> etc.
>> >> >>> >>
>> >> >>> >> On Mon, Dec 5, 

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

Yes, the new build works!

On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:

> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
> Please let me know if that works.
>
> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
> wrote:
> > It sounds like the solution to the problem is to downgrade SWIG on the
> build
> > machine.  If it's using version 3.0.9 or higher, just use whatever the
> last
> > version before that is.  3.0.8, for example.
> >
> > At least there's a good workaround in the interim (i.e. setting
> PYTHONPATH)
> >
> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
> wrote:
> >>
> >> I'll do another snapshot maybe next week or the week after. You can
> >> also ping me if you want it sooner or later.
> >>
> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
> >> fully understand the problem here, but if there's some way to work
> >> around it and get lldb into good shape for the 4.0.0 installer, that
> >> would be great.
> >>
> >> Thanks,
> >> Hans
> >>
> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
> wrote:
> >> > This appears to be a SWIG bug: https://github.com/swig/swig/
> issues/769
> >> >
> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
> >> > wrote:
> >> >>
> >> >> It worked!
> >> >>
> >> >> ...but not before I set PYTHONPATH=C:\Program Files
> >> >> (x86)\LLVM\lib\site-packages\lldb
> >> >> Without that, it couldn't find the _lldb module, so we are not quite
> >> >> out
> >> >> of the woods yet.
> >> >>
> >> >> When are you planning to make the next snapshot build?
> >> >> Thanks!
> >> >>
> >> >>
> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
> >> >> wrote:
> >> >>>
> >> >>> Vadim, it looks like your change was committed in r291291, and I've
> >> >>> built a new snapshot today which includes it. Can you give it a try
> >> >>> and see if everything works?
> >> >>>
> >> >>> Cheers,
> >> >>> Hans
> >> >>>
> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner  >
> >> >>> wrote:
> >> >>> > I will commit it, in the meantime can you request commit access so
> >> >>> > that
> >> >>> > any
> >> >>> > future patches you can commit?
> >> >>> >
> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> Thanks!
> >> >>> >>
> >> >>> >> Would anyone be so kind to commit that?
> >> >>> >>
> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
> >> >>> >> 
> >> >>> >> wrote:
> >> >>> >>>
> >> >>> >>> Sorry, a combination of national holidays and extended vacations
> >> >>> >>> happened
> >> >>> >>> and this fell off my radar.  lgtm
> >> >>> >>>
> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov <
> vadi...@gmail.com>
> >> >>> >>> wrote:
> >> >>> 
> >> >>>  Zachary,
> >> >>>  Can you please take a look at that change?
> >> >>>  (https://reviews.llvm.org/D27476)
> >> >>> 
> >> >>>  It'll be sad if another snapshot build gets published with
> broken
> >> >>>  lldb.
> >> >>>  :(
> >> >>> 
> >> >>> 
> >> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
> >> >>>  
> >> >>>  wrote:
> >> >>> >
> >> >>> > This seems to work: https://reviews.llvm.org/D27476
> >> >>> >
> >> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
> >> >>> > 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> The only thing needed to build the installer should be having
> >> >>> >> NSIS
> >> >>> >> installed and building the "package" target generated by
> CMake.
> >> >>> >> The
> >> >>> >> other prerequisites are mostly for building the visual studio
> >> >>> >> clang-format plugin.
> >> >>> >>
> >> >>> >> Having said that, you don't even have to build the installer
> to
> >> >>> >> see
> >> >>> >> what goes in it. Just building the "install" target generated
> >> >>> >> by
> >> >>> >> CMake
> >> >>> >> will install the same set of files.
> >> >>> >>
> >> >>> >> I'm not sure how LLDB's cmake files are organized, but in the
> >> >>> >> end
> >> >>> >> what's required is invoking the install() command:
> >> >>> >> https://cmake.org/cmake/help/v3.0/command/install.html  In
> >> >>> >> LLVM,
> >> >>> >> this
> >> >>> >> is done automatically by macros such as add_llvm_executale,
> >> >>> >> etc.
> >> >>> >>
> >> >>> >> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov
> >> >>> >> 
> >> >>> >> wrote:
> >> >>> >> > Hi Hans,
> >> >>> >> >
> >> >>> >> > I'd love to help, but I don't have half the tools that
> >> >>> >> > build_llvm_package.bat requires installed on my machine.
> My
> >> >>> >> > setup
> >> >>> >> > is to
> >> >>> >> > build llvm with msbuild.   Is it possible to build the
> 

Re: [lldb-dev] Prebuilt binary for Windows

[Hans Wennborg via lldb-dev]

I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
Please let me know if that works.

On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner  wrote:
> It sounds like the solution to the problem is to downgrade SWIG on the build
> machine.  If it's using version 3.0.9 or higher, just use whatever the last
> version before that is.  3.0.8, for example.
>
> At least there's a good workaround in the interim (i.e. setting PYTHONPATH)
>
> On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg  wrote:
>>
>> I'll do another snapshot maybe next week or the week after. You can
>> also ping me if you want it sooner or later.
>>
>> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> fully understand the problem here, but if there's some way to work
>> around it and get lldb into good shape for the 4.0.0 installer, that
>> would be great.
>>
>> Thanks,
>> Hans
>>
>> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov  wrote:
>> > This appears to be a SWIG bug: https://github.com/swig/swig/issues/769
>> >
>> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> > wrote:
>> >>
>> >> It worked!
>> >>
>> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> (x86)\LLVM\lib\site-packages\lldb
>> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> out
>> >> of the woods yet.
>> >>
>> >> When are you planning to make the next snapshot build?
>> >> Thanks!
>> >>
>> >>
>> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> wrote:
>> >>>
>> >>> Vadim, it looks like your change was committed in r291291, and I've
>> >>> built a new snapshot today which includes it. Can you give it a try
>> >>> and see if everything works?
>> >>>
>> >>> Cheers,
>> >>> Hans
>> >>>
>> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner 
>> >>> wrote:
>> >>> > I will commit it, in the meantime can you request commit access so
>> >>> > that
>> >>> > any
>> >>> > future patches you can commit?
>> >>> >
>> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
>> >>> > wrote:
>> >>> >>
>> >>> >> Thanks!
>> >>> >>
>> >>> >> Would anyone be so kind to commit that?
>> >>> >>
>> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>> >>> >> 
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Sorry, a combination of national holidays and extended vacations
>> >>> >>> happened
>> >>> >>> and this fell off my radar.  lgtm
>> >>> >>>
>> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov 
>> >>> >>> wrote:
>> >>> 
>> >>>  Zachary,
>> >>>  Can you please take a look at that change?
>> >>>  (https://reviews.llvm.org/D27476)
>> >>> 
>> >>>  It'll be sad if another snapshot build gets published with broken
>> >>>  lldb.
>> >>>  :(
>> >>> 
>> >>> 
>> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
>> >>>  
>> >>>  wrote:
>> >>> >
>> >>> > This seems to work: https://reviews.llvm.org/D27476
>> >>> >
>> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> The only thing needed to build the installer should be having
>> >>> >> NSIS
>> >>> >> installed and building the "package" target generated by CMake.
>> >>> >> The
>> >>> >> other prerequisites are mostly for building the visual studio
>> >>> >> clang-format plugin.
>> >>> >>
>> >>> >> Having said that, you don't even have to build the installer to
>> >>> >> see
>> >>> >> what goes in it. Just building the "install" target generated
>> >>> >> by
>> >>> >> CMake
>> >>> >> will install the same set of files.
>> >>> >>
>> >>> >> I'm not sure how LLDB's cmake files are organized, but in the
>> >>> >> end
>> >>> >> what's required is invoking the install() command:
>> >>> >> https://cmake.org/cmake/help/v3.0/command/install.html  In
>> >>> >> LLVM,
>> >>> >> this
>> >>> >> is done automatically by macros such as add_llvm_executale,
>> >>> >> etc.
>> >>> >>
>> >>> >> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov
>> >>> >> 
>> >>> >> wrote:
>> >>> >> > Hi Hans,
>> >>> >> >
>> >>> >> > I'd love to help, but I don't have half the tools that
>> >>> >> > build_llvm_package.bat requires installed on my machine.  My
>> >>> >> > setup
>> >>> >> > is to
>> >>> >> > build llvm with msbuild.   Is it possible to build the
>> >>> >> > installer
>> >>> >> > this way
>> >>> >> > too?
>> >>> >> >
>> >>> >> > Can you point me to the specific CMake source that determines
>> >>> >> > what's
>> >>> >> > included in the package?   At a glance, everything from
>> >>> >> > %LLVM%/lib/site-packages is missing.
>> >>> >> >
>> >>> >> > Vadim
>> >>> >> >
>> >>> >> > On 

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

It sounds like the solution to the problem is to downgrade SWIG on the
build machine.  If it's using version 3.0.9 or higher, just use whatever
the last version before that is.  3.0.8, for example.

At least there's a good workaround in the interim (i.e. setting PYTHONPATH)

On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg  wrote:

> I'll do another snapshot maybe next week or the week after. You can
> also ping me if you want it sooner or later.
>
> We're kicking off the release process for 4.0.0 on Thursday. I don't
> fully understand the problem here, but if there's some way to work
> around it and get lldb into good shape for the 4.0.0 installer, that
> would be great.
>
> Thanks,
> Hans
>
> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov  wrote:
> > This appears to be a SWIG bug: https://github.com/swig/swig/issues/769
> >
> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
> wrote:
> >>
> >> It worked!
> >>
> >> ...but not before I set PYTHONPATH=C:\Program Files
> >> (x86)\LLVM\lib\site-packages\lldb
> >> Without that, it couldn't find the _lldb module, so we are not quite out
> >> of the woods yet.
> >>
> >> When are you planning to make the next snapshot build?
> >> Thanks!
> >>
> >>
> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
> wrote:
> >>>
> >>> Vadim, it looks like your change was committed in r291291, and I've
> >>> built a new snapshot today which includes it. Can you give it a try
> >>> and see if everything works?
> >>>
> >>> Cheers,
> >>> Hans
> >>>
> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner 
> >>> wrote:
> >>> > I will commit it, in the meantime can you request commit access so
> that
> >>> > any
> >>> > future patches you can commit?
> >>> >
> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
> >>> > wrote:
> >>> >>
> >>> >> Thanks!
> >>> >>
> >>> >> Would anyone be so kind to commit that?
> >>> >>
> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner  >
> >>> >> wrote:
> >>> >>>
> >>> >>> Sorry, a combination of national holidays and extended vacations
> >>> >>> happened
> >>> >>> and this fell off my radar.  lgtm
> >>> >>>
> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov 
> >>> >>> wrote:
> >>> 
> >>>  Zachary,
> >>>  Can you please take a look at that change?
> >>>  (https://reviews.llvm.org/D27476)
> >>> 
> >>>  It'll be sad if another snapshot build gets published with broken
> >>>  lldb.
> >>>  :(
> >>> 
> >>> 
> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov <
> vadi...@gmail.com>
> >>>  wrote:
> >>> >
> >>> > This seems to work: https://reviews.llvm.org/D27476
> >>> >
> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg <
> h...@chromium.org>
> >>> > wrote:
> >>> >>
> >>> >> The only thing needed to build the installer should be having
> NSIS
> >>> >> installed and building the "package" target generated by CMake.
> >>> >> The
> >>> >> other prerequisites are mostly for building the visual studio
> >>> >> clang-format plugin.
> >>> >>
> >>> >> Having said that, you don't even have to build the installer to
> >>> >> see
> >>> >> what goes in it. Just building the "install" target generated by
> >>> >> CMake
> >>> >> will install the same set of files.
> >>> >>
> >>> >> I'm not sure how LLDB's cmake files are organized, but in the
> end
> >>> >> what's required is invoking the install() command:
> >>> >> https://cmake.org/cmake/help/v3.0/command/install.html  In
> LLVM,
> >>> >> this
> >>> >> is done automatically by macros such as add_llvm_executale, etc.
> >>> >>
> >>> >> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov
> >>> >> 
> >>> >> wrote:
> >>> >> > Hi Hans,
> >>> >> >
> >>> >> > I'd love to help, but I don't have half the tools that
> >>> >> > build_llvm_package.bat requires installed on my machine.  My
> >>> >> > setup
> >>> >> > is to
> >>> >> > build llvm with msbuild.   Is it possible to build the
> installer
> >>> >> > this way
> >>> >> > too?
> >>> >> >
> >>> >> > Can you point me to the specific CMake source that determines
> >>> >> > what's
> >>> >> > included in the package?   At a glance, everything from
> >>> >> > %LLVM%/lib/site-packages is missing.
> >>> >> >
> >>> >> > Vadim
> >>> >> >
> >>> >> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg
> >>> >> > 
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> Is anyone working on this?
> >>> >> >>
> >>> >> >> I'm happy to include LLDB in the installer, but I'm really
> not
> >>> >> >> the
> >>> >> >> best person to be debugging it.
> >>> >> >>
> >>> >> >> If more files need to be included in the install, that's
> >>> >> >> 

Re: [lldb-dev] Prebuilt binary for Windows

[Hans Wennborg via lldb-dev]

I'll do another snapshot maybe next week or the week after. You can
also ping me if you want it sooner or later.

We're kicking off the release process for 4.0.0 on Thursday. I don't
fully understand the problem here, but if there's some way to work
around it and get lldb into good shape for the 4.0.0 installer, that
would be great.

Thanks,
Hans

On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov  wrote:
> This appears to be a SWIG bug: https://github.com/swig/swig/issues/769
>
> On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov  wrote:
>>
>> It worked!
>>
>> ...but not before I set PYTHONPATH=C:\Program Files
>> (x86)\LLVM\lib\site-packages\lldb
>> Without that, it couldn't find the _lldb module, so we are not quite out
>> of the woods yet.
>>
>> When are you planning to make the next snapshot build?
>> Thanks!
>>
>>
>> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg  wrote:
>>>
>>> Vadim, it looks like your change was committed in r291291, and I've
>>> built a new snapshot today which includes it. Can you give it a try
>>> and see if everything works?
>>>
>>> Cheers,
>>> Hans
>>>
>>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner 
>>> wrote:
>>> > I will commit it, in the meantime can you request commit access so that
>>> > any
>>> > future patches you can commit?
>>> >
>>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
>>> > wrote:
>>> >>
>>> >> Thanks!
>>> >>
>>> >> Would anyone be so kind to commit that?
>>> >>
>>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner 
>>> >> wrote:
>>> >>>
>>> >>> Sorry, a combination of national holidays and extended vacations
>>> >>> happened
>>> >>> and this fell off my radar.  lgtm
>>> >>>
>>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov 
>>> >>> wrote:
>>> 
>>>  Zachary,
>>>  Can you please take a look at that change?
>>>  (https://reviews.llvm.org/D27476)
>>> 
>>>  It'll be sad if another snapshot build gets published with broken
>>>  lldb.
>>>  :(
>>> 
>>> 
>>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov 
>>>  wrote:
>>> >
>>> > This seems to work: https://reviews.llvm.org/D27476
>>> >
>>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg 
>>> > wrote:
>>> >>
>>> >> The only thing needed to build the installer should be having NSIS
>>> >> installed and building the "package" target generated by CMake.
>>> >> The
>>> >> other prerequisites are mostly for building the visual studio
>>> >> clang-format plugin.
>>> >>
>>> >> Having said that, you don't even have to build the installer to
>>> >> see
>>> >> what goes in it. Just building the "install" target generated by
>>> >> CMake
>>> >> will install the same set of files.
>>> >>
>>> >> I'm not sure how LLDB's cmake files are organized, but in the end
>>> >> what's required is invoking the install() command:
>>> >> https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM,
>>> >> this
>>> >> is done automatically by macros such as add_llvm_executale, etc.
>>> >>
>>> >> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov
>>> >> 
>>> >> wrote:
>>> >> > Hi Hans,
>>> >> >
>>> >> > I'd love to help, but I don't have half the tools that
>>> >> > build_llvm_package.bat requires installed on my machine.  My
>>> >> > setup
>>> >> > is to
>>> >> > build llvm with msbuild.   Is it possible to build the installer
>>> >> > this way
>>> >> > too?
>>> >> >
>>> >> > Can you point me to the specific CMake source that determines
>>> >> > what's
>>> >> > included in the package?   At a glance, everything from
>>> >> > %LLVM%/lib/site-packages is missing.
>>> >> >
>>> >> > Vadim
>>> >> >
>>> >> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg
>>> >> > 
>>> >> > wrote:
>>> >> >>
>>> >> >> Is anyone working on this?
>>> >> >>
>>> >> >> I'm happy to include LLDB in the installer, but I'm really not
>>> >> >> the
>>> >> >> best person to be debugging it.
>>> >> >>
>>> >> >> If more files need to be included in the install, that's
>>> >> >> configured
>>> >> >> in
>>> >> >> the CMake files (what's installed by the 'install' build target
>>> >> >> is
>>> >> >> also what ends up going into the installer). If it needs more
>>> >> >> build
>>> >> >> flags, patches to build_llvm_package.bat are welsome.
>>> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>> 
>>> >>
>>> >
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

This appears to be a SWIG bug: https://github.com/swig/swig/issues/769

On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov  wrote:

> It worked!
>
> ...but not before I set PYTHONPATH=C:\Program Files
> (x86)\LLVM\lib\site-packages\lldb
> Without that, it couldn't find the _lldb module, so we are not quite out
> of the woods yet.
>
> When are you planning to make the next snapshot build?
> Thanks!
>
>
> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg  wrote:
>
>> Vadim, it looks like your change was committed in r291291, and I've
>> built a new snapshot today which includes it. Can you give it a try
>> and see if everything works?
>>
>> Cheers,
>> Hans
>>
>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner 
>> wrote:
>> > I will commit it, in the meantime can you request commit access so that
>> any
>> > future patches you can commit?
>> >
>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
>> wrote:
>> >>
>> >> Thanks!
>> >>
>> >> Would anyone be so kind to commit that?
>> >>
>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner 
>> >> wrote:
>> >>>
>> >>> Sorry, a combination of national holidays and extended vacations
>> happened
>> >>> and this fell off my radar.  lgtm
>> >>>
>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov 
>> wrote:
>> 
>>  Zachary,
>>  Can you please take a look at that change?
>>  (https://reviews.llvm.org/D27476)
>> 
>>  It'll be sad if another snapshot build gets published with broken
>> lldb.
>>  :(
>> 
>> 
>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov 
>>  wrote:
>> >
>> > This seems to work: https://reviews.llvm.org/D27476
>> >
>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg 
>> > wrote:
>> >>
>> >> The only thing needed to build the installer should be having NSIS
>> >> installed and building the "package" target generated by CMake. The
>> >> other prerequisites are mostly for building the visual studio
>> >> clang-format plugin.
>> >>
>> >> Having said that, you don't even have to build the installer to see
>> >> what goes in it. Just building the "install" target generated by
>> CMake
>> >> will install the same set of files.
>> >>
>> >> I'm not sure how LLDB's cmake files are organized, but in the end
>> >> what's required is invoking the install() command:
>> >> https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM,
>> this
>> >> is done automatically by macros such as add_llvm_executale, etc.
>> >>
>> >> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov > >
>> >> wrote:
>> >> > Hi Hans,
>> >> >
>> >> > I'd love to help, but I don't have half the tools that
>> >> > build_llvm_package.bat requires installed on my machine.  My
>> setup
>> >> > is to
>> >> > build llvm with msbuild.   Is it possible to build the installer
>> >> > this way
>> >> > too?
>> >> >
>> >> > Can you point me to the specific CMake source that determines
>> what's
>> >> > included in the package?   At a glance, everything from
>> >> > %LLVM%/lib/site-packages is missing.
>> >> >
>> >> > Vadim
>> >> >
>> >> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg <
>> h...@chromium.org>
>> >> > wrote:
>> >> >>
>> >> >> Is anyone working on this?
>> >> >>
>> >> >> I'm happy to include LLDB in the installer, but I'm really not
>> the
>> >> >> best person to be debugging it.
>> >> >>
>> >> >> If more files need to be included in the install, that's
>> configured
>> >> >> in
>> >> >> the CMake files (what's installed by the 'install' build target
>> is
>> >> >> also what ends up going into the installer). If it needs more
>> build
>> >> >> flags, patches to build_llvm_package.bat are welsome.
>> >> >
>> >> >
>> >> >
>> >
>> >
>> 
>> >>
>> >
>>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

It worked!

...but not before I set PYTHONPATH=C:\Program Files
(x86)\LLVM\lib\site-packages\lldb
Without that, it couldn't find the _lldb module, so we are not quite out of
the woods yet.

When are you planning to make the next snapshot build?
Thanks!


On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg  wrote:

> Vadim, it looks like your change was committed in r291291, and I've
> built a new snapshot today which includes it. Can you give it a try
> and see if everything works?
>
> Cheers,
> Hans
>
> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner 
> wrote:
> > I will commit it, in the meantime can you request commit access so that
> any
> > future patches you can commit?
> >
> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov  wrote:
> >>
> >> Thanks!
> >>
> >> Would anyone be so kind to commit that?
> >>
> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner 
> >> wrote:
> >>>
> >>> Sorry, a combination of national holidays and extended vacations
> happened
> >>> and this fell off my radar.  lgtm
> >>>
> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov 
> wrote:
> 
>  Zachary,
>  Can you please take a look at that change?
>  (https://reviews.llvm.org/D27476)
> 
>  It'll be sad if another snapshot build gets published with broken
> lldb.
>  :(
> 
> 
>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov 
>  wrote:
> >
> > This seems to work: https://reviews.llvm.org/D27476
> >
> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg 
> > wrote:
> >>
> >> The only thing needed to build the installer should be having NSIS
> >> installed and building the "package" target generated by CMake. The
> >> other prerequisites are mostly for building the visual studio
> >> clang-format plugin.
> >>
> >> Having said that, you don't even have to build the installer to see
> >> what goes in it. Just building the "install" target generated by
> CMake
> >> will install the same set of files.
> >>
> >> I'm not sure how LLDB's cmake files are organized, but in the end
> >> what's required is invoking the install() command:
> >> https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM,
> this
> >> is done automatically by macros such as add_llvm_executale, etc.
> >>
> >> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov 
> >> wrote:
> >> > Hi Hans,
> >> >
> >> > I'd love to help, but I don't have half the tools that
> >> > build_llvm_package.bat requires installed on my machine.  My setup
> >> > is to
> >> > build llvm with msbuild.   Is it possible to build the installer
> >> > this way
> >> > too?
> >> >
> >> > Can you point me to the specific CMake source that determines
> what's
> >> > included in the package?   At a glance, everything from
> >> > %LLVM%/lib/site-packages is missing.
> >> >
> >> > Vadim
> >> >
> >> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg  >
> >> > wrote:
> >> >>
> >> >> Is anyone working on this?
> >> >>
> >> >> I'm happy to include LLDB in the installer, but I'm really not
> the
> >> >> best person to be debugging it.
> >> >>
> >> >> If more files need to be included in the install, that's
> configured
> >> >> in
> >> >> the CMake files (what's installed by the 'install' build target
> is
> >> >> also what ends up going into the installer). If it needs more
> build
> >> >> flags, patches to build_llvm_package.bat are welsome.
> >> >
> >> >
> >> >
> >
> >
> 
> >>
> >
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Hans Wennborg via lldb-dev]

Vadim, it looks like your change was committed in r291291, and I've
built a new snapshot today which includes it. Can you give it a try
and see if everything works?

Cheers,
Hans

On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner  wrote:
> I will commit it, in the meantime can you request commit access so that any
> future patches you can commit?
>
> On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov  wrote:
>>
>> Thanks!
>>
>> Would anyone be so kind to commit that?
>>
>> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner 
>> wrote:
>>>
>>> Sorry, a combination of national holidays and extended vacations happened
>>> and this fell off my radar.  lgtm
>>>
>>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov  wrote:

 Zachary,
 Can you please take a look at that change?
 (https://reviews.llvm.org/D27476)

 It'll be sad if another snapshot build gets published with broken lldb.
 :(


 On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov 
 wrote:
>
> This seems to work: https://reviews.llvm.org/D27476
>
> On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg 
> wrote:
>>
>> The only thing needed to build the installer should be having NSIS
>> installed and building the "package" target generated by CMake. The
>> other prerequisites are mostly for building the visual studio
>> clang-format plugin.
>>
>> Having said that, you don't even have to build the installer to see
>> what goes in it. Just building the "install" target generated by CMake
>> will install the same set of files.
>>
>> I'm not sure how LLDB's cmake files are organized, but in the end
>> what's required is invoking the install() command:
>> https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM, this
>> is done automatically by macros such as add_llvm_executale, etc.
>>
>> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov 
>> wrote:
>> > Hi Hans,
>> >
>> > I'd love to help, but I don't have half the tools that
>> > build_llvm_package.bat requires installed on my machine.  My setup
>> > is to
>> > build llvm with msbuild.   Is it possible to build the installer
>> > this way
>> > too?
>> >
>> > Can you point me to the specific CMake source that determines what's
>> > included in the package?   At a glance, everything from
>> > %LLVM%/lib/site-packages is missing.
>> >
>> > Vadim
>> >
>> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg 
>> > wrote:
>> >>
>> >> Is anyone working on this?
>> >>
>> >> I'm happy to include LLDB in the installer, but I'm really not the
>> >> best person to be debugging it.
>> >>
>> >> If more files need to be included in the install, that's configured
>> >> in
>> >> the CMake files (what's installed by the 'install' build target is
>> >> also what ends up going into the installer). If it needs more build
>> >> flags, patches to build_llvm_package.bat are welsome.
>> >
>> >
>> >
>
>

>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

I will commit it, in the meantime can you request commit access so that any
future patches you can commit?

On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov  wrote:

> Thanks!
>
> Would anyone be so kind to commit that?
>
> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner 
> wrote:
>
> Sorry, a combination of national holidays and extended vacations happened
> and this fell off my radar.  lgtm
>
> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov  wrote:
>
> Zachary,
> Can you please take a look at that change? (
> https://reviews.llvm.org/D27476)
>
> It'll be sad if another snapshot build gets published with broken lldb. :(
>
>
> On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov  wrote:
>
> This seems to work: https://reviews.llvm.org/D27476
>
> On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg  wrote:
>
> The only thing needed to build the installer should be having NSIS
> installed and building the "package" target generated by CMake. The
> other prerequisites are mostly for building the visual studio
> clang-format plugin.
>
> Having said that, you don't even have to build the installer to see
> what goes in it. Just building the "install" target generated by CMake
> will install the same set of files.
>
> I'm not sure how LLDB's cmake files are organized, but in the end
> what's required is invoking the install() command:
> https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM, this
> is done automatically by macros such as add_llvm_executale, etc.
>
> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov  wrote:
> > Hi Hans,
> >
> > I'd love to help, but I don't have half the tools that
> > build_llvm_package.bat requires installed on my machine.  My setup is to
> > build llvm with msbuild.   Is it possible to build the installer this way
> > too?
> >
> > Can you point me to the specific CMake source that determines what's
> > included in the package?   At a glance, everything from
> > %LLVM%/lib/site-packages is missing.
> >
> > Vadim
> >
> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg 
> wrote:
> >>
> >> Is anyone working on this?
> >>
> >> I'm happy to include LLDB in the installer, but I'm really not the
> >> best person to be debugging it.
> >>
> >> If more files need to be included in the install, that's configured in
> >> the CMake files (what's installed by the 'install' build target is
> >> also what ends up going into the installer). If it needs more build
> >> flags, patches to build_llvm_package.bat are welsome.
> >
> >
> >
>
>
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

Thanks!

Would anyone be so kind to commit that?

On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner  wrote:

> Sorry, a combination of national holidays and extended vacations happened
> and this fell off my radar.  lgtm
>
> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov  wrote:
>
>> Zachary,
>> Can you please take a look at that change? (https://reviews.llvm.org/
>> D27476)
>>
>> It'll be sad if another snapshot build gets published with broken lldb. :(
>>
>>
>> On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov 
>> wrote:
>>
>> This seems to work: https://reviews.llvm.org/D27476
>>
>> On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg  wrote:
>>
>> The only thing needed to build the installer should be having NSIS
>> installed and building the "package" target generated by CMake. The
>> other prerequisites are mostly for building the visual studio
>> clang-format plugin.
>>
>> Having said that, you don't even have to build the installer to see
>> what goes in it. Just building the "install" target generated by CMake
>> will install the same set of files.
>>
>> I'm not sure how LLDB's cmake files are organized, but in the end
>> what's required is invoking the install() command:
>> https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM, this
>> is done automatically by macros such as add_llvm_executale, etc.
>>
>> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov 
>> wrote:
>> > Hi Hans,
>> >
>> > I'd love to help, but I don't have half the tools that
>> > build_llvm_package.bat requires installed on my machine.  My setup is to
>> > build llvm with msbuild.   Is it possible to build the installer this
>> way
>> > too?
>> >
>> > Can you point me to the specific CMake source that determines what's
>> > included in the package?   At a glance, everything from
>> > %LLVM%/lib/site-packages is missing.
>> >
>> > Vadim
>> >
>> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg 
>> wrote:
>> >>
>> >> Is anyone working on this?
>> >>
>> >> I'm happy to include LLDB in the installer, but I'm really not the
>> >> best person to be debugging it.
>> >>
>> >> If more files need to be included in the install, that's configured in
>> >> the CMake files (what's installed by the 'install' build target is
>> >> also what ends up going into the installer). If it needs more build
>> >> flags, patches to build_llvm_package.bat are welsome.
>> >
>> >
>> >
>>
>>
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

Sorry, a combination of national holidays and extended vacations happened
and this fell off my radar.  lgtm

On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov  wrote:

> Zachary,
> Can you please take a look at that change? (
> https://reviews.llvm.org/D27476)
>
> It'll be sad if another snapshot build gets published with broken lldb. :(
>
>
> On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov  wrote:
>
> This seems to work: https://reviews.llvm.org/D27476
>
> On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg  wrote:
>
> The only thing needed to build the installer should be having NSIS
> installed and building the "package" target generated by CMake. The
> other prerequisites are mostly for building the visual studio
> clang-format plugin.
>
> Having said that, you don't even have to build the installer to see
> what goes in it. Just building the "install" target generated by CMake
> will install the same set of files.
>
> I'm not sure how LLDB's cmake files are organized, but in the end
> what's required is invoking the install() command:
> https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM, this
> is done automatically by macros such as add_llvm_executale, etc.
>
> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov  wrote:
> > Hi Hans,
> >
> > I'd love to help, but I don't have half the tools that
> > build_llvm_package.bat requires installed on my machine.  My setup is to
> > build llvm with msbuild.   Is it possible to build the installer this way
> > too?
> >
> > Can you point me to the specific CMake source that determines what's
> > included in the package?   At a glance, everything from
> > %LLVM%/lib/site-packages is missing.
> >
> > Vadim
> >
> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg 
> wrote:
> >>
> >> Is anyone working on this?
> >>
> >> I'm happy to include LLDB in the installer, but I'm really not the
> >> best person to be debugging it.
> >>
> >> If more files need to be included in the install, that's configured in
> >> the CMake files (what's installed by the 'install' build target is
> >> also what ends up going into the installer). If it needs more build
> >> flags, patches to build_llvm_package.bat are welsome.
> >
> >
> >
>
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

Zachary,
Can you please take a look at that change? (https://reviews.llvm.org/D27476)

It'll be sad if another snapshot build gets published with broken lldb. :(


On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov  wrote:

> This seems to work: https://reviews.llvm.org/D27476
>
> On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg  wrote:
>
>> The only thing needed to build the installer should be having NSIS
>> installed and building the "package" target generated by CMake. The
>> other prerequisites are mostly for building the visual studio
>> clang-format plugin.
>>
>> Having said that, you don't even have to build the installer to see
>> what goes in it. Just building the "install" target generated by CMake
>> will install the same set of files.
>>
>> I'm not sure how LLDB's cmake files are organized, but in the end
>> what's required is invoking the install() command:
>> https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM, this
>> is done automatically by macros such as add_llvm_executale, etc.
>>
>> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov 
>> wrote:
>> > Hi Hans,
>> >
>> > I'd love to help, but I don't have half the tools that
>> > build_llvm_package.bat requires installed on my machine.  My setup is to
>> > build llvm with msbuild.   Is it possible to build the installer this
>> way
>> > too?
>> >
>> > Can you point me to the specific CMake source that determines what's
>> > included in the package?   At a glance, everything from
>> > %LLVM%/lib/site-packages is missing.
>> >
>> > Vadim
>> >
>> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg 
>> wrote:
>> >>
>> >> Is anyone working on this?
>> >>
>> >> I'm happy to include LLDB in the installer, but I'm really not the
>> >> best person to be debugging it.
>> >>
>> >> If more files need to be included in the install, that's configured in
>> >> the CMake files (what's installed by the 'install' build target is
>> >> also what ends up going into the installer). If it needs more build
>> >> flags, patches to build_llvm_package.bat are welsome.
>> >
>> >
>> >
>>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev