Re: [lldb-dev] [Release-testers] [4.0 Release] Schedule and call for testers

[Renato Golin via lldb-dev]

On 5 December 2016 at 18:26, Hans Wennborg via Release-testers
 wrote:
> I propose the following schedule for the 4.0 release:
>
> - 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.
>
> - 1 February: Tag RC2. All lose ends should have been tied up by now.
>
> - 21 February: Final tag. Binaries and release announcement a few days later.

LGTM.

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

Re: [lldb-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Renato Golin via lldb-dev]

On 5 December 2016 at 20:07, Hans Wennborg  wrote:
> I'm worried that users will, with some reason, think that the 4.1 and
> 5.1 releases are the same kind as 2.1 and 3.1 :-/

IMO, this is too small of a worry to encumber us for the rest of our
release days with silly zeroes.

I'd rather be redundantly explicit for the next year, than carry that
burden for the next 5 (or more).

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

Re: [lldb-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Hans Wennborg via lldb-dev]

On Mon, Dec 5, 2016 at 11:00 AM, Renato Golin  wrote:
> On 5 December 2016 at 18:56, Hans Wennborg via Release-testers
>  wrote:
>> The idea is that Tom's stable releases will keep incrementing the
>> "patch" part of the version numbers, just as today, so they would be
>> 4.0.1, 4.0.2, etc.
>
> Hum, this looks weird. I was under the impression that we'd do 4.1, 4.2 
> instead.

I'd like to avoid 4.1 because of the potential for confusion about
whether it's a major release (as it would have been under the old
scheme) or a patch release.

> Otherwise, it'll be:
>
> * 3.9.0
> * 3.9.1
> * 4.0.0
> * 4.0.1
> * 5.0.0
> * 5.0.1
>
> With a totally redundant zero in the middle.

Yes, it has a redundant zero in the middle, but I don't think that's a
terrible thing, and it's very clear what the version number means.

The alternative would be:

3.9.0
3.9.1
4.0.0
4.1.0 <-- Can't tell from the version number what kind of release this is.

> Unless we're planning to extend the maintenance of the 5.x branch and
> release 5.1.0 *after* 6.0.0 is out, which would be a major change in
> how we release LLVM. I don't think that's the plan.

Right, not planning to do that.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0 Release] Schedule and call for testers

[Bernhard Rosenkränzer via lldb-dev]

Hi,
plan looks good to me.
At OpenMandriva, we're already on the 4.0 branch (rev. 287544 right now)
because that's what our next major release (expected in late Q2/early Q3
2017) will ship with.

No big issues here so far, except the LLVMAddAttribute removal (Mesa still
relies on that API -- we've solved it for now by patching it back in).
We'll probably upgrade our snapshot one more time in mid to late December,
then package RC1, RC2 and final (and any RC3 or so that might be added).

In the Android world, we're running daily builds of AOSP master with clang
master inside Linaro. No big issues there either (some extra warnings
emitted by 4.0, esp. address-of-packed-member required some code changes
and/or -Wno-error= workarounds, but that's intentional).

ttyl
bero

On 5 December 2016 at 19:26, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Dear everyone,
>
> There's still plenty of time left, but I'd like to get the schedule
> set before folks start disappearing for the holidays.
>
> Note that this release will also switch us to the new versioning
> scheme where the major version is incremented for each major release
> (i.e., when the 4.0 branch is created, trunk will become 5.0).
>
> If you'd like to help providing binaries and testing for your
> favourite platform, please subscribe to the release-testers mailing
> list [1].
>
> I propose the following schedule for the 4.0 release:
>
> - 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.
>
> - 1 February: Tag RC2. All lose ends should have been tied up by now.
>
> - 21 February: Final tag. Binaries and release announcement a few days
> later.
>
> Unless there are any objections, I'll post this on the web page soon.
>
> Cheers,
> Hans
>
>
>   [1] http://lists.llvm.org/mailman/listinfo/release-testers
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Hans Wennborg via lldb-dev]

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] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Hans Wennborg via lldb-dev]

On Mon, Dec 5, 2016 at 12:02 PM, Renato Golin  wrote:
> On 5 December 2016 at 19:56, Hans Wennborg  wrote:
>> I'd like to avoid 4.1 because of the potential for confusion about
>> whether it's a major release (as it would have been under the old
>> scheme) or a patch release.
>
> But if the versioning scheme is different, users will have to
> understand what it means anyway.
>
> Until now we had a weird and very unique logic, and we're moving to a
> more sensible logic, because it's similar to what some other projects
> are doing.
>
> I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
> that used to be weird before.
>
> After a few releases everything will be clear anyway... I really don't
> want to make the foreseeable future weird again to avoid a potential
> misunderstanding for one or two releases.
>
> Let's just be brutally clear in all release communications and
> hopefully people will understand.
>
>
>> The alternative would be:
>>
>> 3.9.0
>> 3.9.1
>> 4.0.0
>> 4.1.0 <-- Can't tell from the version number what kind of release this is.
>
> No, that has a redundant zero, too.
>
> The alternative is:
>
> 3.9.0
> 3.9.1
> 4.0
> 4.1
> 5.0
> 5.1

I'm worried that users will, with some reason, think that the 4.1 and
5.1 releases are the same kind as 2.1 and 3.1 :-/
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] [4.0 Release] Schedule and call for testers

[Renato Golin via lldb-dev]

On 5 December 2016 at 19:08, Michał Górny via cfe-dev
 wrote:
> Will this new version scheme mean that 4.1 (if ever released) will be
> ABI-compatible with 4.0? If it will be so, we should update SONAMEs
> accordingly.

Yes. All 4.x will be ABI compatible with 4.0, just like any stable
release we do today. Doesn't matter if it's called 4.0.1 or 4.1.

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

[lldb-dev] [Bug 31104] Standalone LLDB build is broken because gtest is defined twice

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=31104

Chris Bieneman  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Chris Bieneman  ---
>From talking to Michael G, I believe I have a handle on the problem, and a
simple fix is landed in r288691.

Please let me know if that resolves your issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

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] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Renato Golin via lldb-dev]

On 5 December 2016 at 19:56, Hans Wennborg  wrote:
> I'd like to avoid 4.1 because of the potential for confusion about
> whether it's a major release (as it would have been under the old
> scheme) or a patch release.

But if the versioning scheme is different, users will have to
understand what it means anyway.

Until now we had a weird and very unique logic, and we're moving to a
more sensible logic, because it's similar to what some other projects
are doing.

I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
that used to be weird before.

After a few releases everything will be clear anyway... I really don't
want to make the foreseeable future weird again to avoid a potential
misunderstanding for one or two releases.

Let's just be brutally clear in all release communications and
hopefully people will understand.


> The alternative would be:
>
> 3.9.0
> 3.9.1
> 4.0.0
> 4.1.0 <-- Can't tell from the version number what kind of release this is.

No, that has a redundant zero, too.

The alternative is:

3.9.0
3.9.1
4.0
4.1
5.0
5.1

etc.

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

Re: [lldb-dev] [llvm-dev] [4.0 Release] Schedule and call for testers

[Michał Górny via lldb-dev]

On Mon, 5 Dec 2016 10:26:33 -0800
Hans Wennborg via llvm-dev  wrote:

> There's still plenty of time left, but I'd like to get the schedule
> set before folks start disappearing for the holidays.
> 
> Note that this release will also switch us to the new versioning
> scheme where the major version is incremented for each major release
> (i.e., when the 4.0 branch is created, trunk will become 5.0).

Will this new version scheme mean that 4.1 (if ever released) will be
ABI-compatible with 4.0? If it will be so, we should update SONAMEs
accordingly.

-- 
Best regards,
Michał Górny



pgpmhdgnHZF_O.pgp
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Hans Wennborg via lldb-dev]

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.

Thanks,
Hans

On Mon, Nov 28, 2016 at 10:17 AM, Zachary Turner  wrote:
> I overlooked that part of it, but yes that is another separate issue.  (BTW,
> _lldb.pyd is simply a symlink to liblldb.dll).
>
> In any case, yea I think the entire lib/site-packages folder needs to be
> included.
>
> On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov  wrote:
>>
>> Please correct me if I'm wrong, but isn't the issue here that LLDB's
>> Python support files don't get packaged into the Windows installer?   Does
>> packaging them somehow depend on knowing what the Python installation path
>> is?
>>
>> On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg  wrote:
>>>
>>> The snapshots are built with the script in
>>> utils/release/build_llvm_package.bat. It's currently passing
>>> -DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.
>>>
>>> I was planning on trying to build a new snapshot today and can add
>>> -DLLDB_DEFAULT_PYTHON_HOME if you think that will help.
>>>
>>> On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner 
>>> wrote:
>>> > So it sounds like you're saying that in order for Python support to
>>> > work as
>>> > part of an LLDB shipped in the installer, we need to do set 3 variables
>>> > at
>>> > CMake time.
>>> >
>>> > 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
>>> > 2) -DPYTHON_HOME = 
>>> > 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
>>> >
>>> > Now because of #3, the lldb shipped in the installer will use the
>>> > PYTHONHOME
>>> > system environment variable to locate python, which must point to a
>>> > valid
>>> > Python 3.5 installation.  Is this correct?
>>> >
>>> > On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward
>>> > 
>>> > wrote:
>>> >>
>>> >> Windows has no concept of a default python installation, and I can’t
>>> >> be
>>> >> sure what version of python my users have, if any, so I need to solve
>>> >> 2
>>> >> problems:
>>> >>
>>> >> 1)  Where is python when I’m building?
>>> >>
>>> >> 2)  Where is python when I’m running?
>>> >>
>>> >>
>>> >>
>>> >> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to
>>> >> my
>>> >> python installation (on our buildbots, c:/python351).
>>> >>
>>> >>
>>> >>
>>> >> #2 only needs to be solved if the machine you’re running on doesn’t
>>> >> have
>>> >> the same python installation, in PYTHON_HOME above. To do that, I’ve
>>> >> added
>>> >> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a
>>> >> macro
>>> >> down to InitializePythonHome in
>>> >> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp,
>>> >> and
>>> >> call Py_SetPythonHome with it. My installations have the python dll
>>> >> and
>>> >> python library directory. We put the library in /lib/python35
>>> >> and
>>> >> the dll in /bin.
>>> >>
>>> >> --
>>> >>
>>> >> Qualcomm Innovation Center, Inc.
>>> >>
>>> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> >> a
>>> >> Linux Foundation Collaborative Project
>>> >>
>>> >>
>>> >>
>>> >> From: Zachary Turner [mailto:ztur...@google.com]
>>> >> Sent: Wednesday, November 23, 2016 12:40 PM
>>> >> To: Vadim Chugunov 
>>> >> Cc: Reid Kleckner ; Hans Wennborg ;
>>> >> LLDB ; Ted Woodward
>>> >> 
>>> >> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>>> >>
>>> >>
>>> >>
>>> >> I believe the way to fix this is going to be building LLDB for the
>>> >> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>>> >>
>>> >>
>>> >>
>>> >> +Ted, since I believe he is one of the few people currently using this
>>> >> flag.
>>> >>
>>> >> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov 
>>> >> wrote:
>>> >>
>>> >> This is still broken in the October snapshot.   Do you know which
>>> >> script
>>> >> is used to build the Windows installer?
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
>>> >> wrote:
>>> >>
>>> >> I think it is a problem with the way we built lldb.  I will look into
>>> >> what
>>> >> additional steps we need to take when making the prebuilt binary so
>>> >> that it
>>> >> works next time.
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov 
>>> >> wrote:
>>> >>
>>> >> Nope, that didn't help.
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
>>> >> wrote:
>>> >>
>>> >> I may know what this is.  Can you try setting PYTHONPATH though to
>>> >> 

Re: [lldb-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Renato Golin via lldb-dev]

On 5 December 2016 at 18:42, Dimitry Andric via Release-testers
 wrote:
> Maybe I didn't pay enough attention, but where is the general outline
> for this versioning scheme documented?  And are we still going to do
> 4.1, 4.2, etc?

This is the thread:

http://lists.llvm.org/pipermail/llvm-dev/2016-June/101044.html


> Note that this is a pretty close follow-up to the 3.9.1 release.  There
> is a minor risk of "release burn-out" here... :)

They're completely different trees, so should only be a problem if we
haven't finished by then.

3.9.1 convergence took a lot longer than expected because of the
number of back-ports. With interest in the point-releases growing, I
think we should try a "half-way" schedule for the point releases, to
make sure that doesn't happen again.

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

[lldb-dev] [4.0 Release] Schedule and call for testers

[Hans Wennborg via lldb-dev]

Dear everyone,

There's still plenty of time left, but I'd like to get the schedule
set before folks start disappearing for the holidays.

Note that this release will also switch us to the new versioning
scheme where the major version is incremented for each major release
(i.e., when the 4.0 branch is created, trunk will become 5.0).

If you'd like to help providing binaries and testing for your
favourite platform, please subscribe to the release-testers mailing
list [1].

I propose the following schedule for the 4.0 release:

- 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.

- 1 February: Tag RC2. All lose ends should have been tied up by now.

- 21 February: Final tag. Binaries and release announcement a few days later.

Unless there are any objections, I'll post this on the web page soon.

Cheers,
Hans


  [1] http://lists.llvm.org/mailman/listinfo/release-testers
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Hans Wennborg via lldb-dev]

On Mon, Dec 5, 2016 at 10:42 AM, Dimitry Andric  wrote:
> On 05 Dec 2016, at 19:26, Hans Wennborg via Openmp-dev 
>  wrote:
>>
>> There's still plenty of time left, but I'd like to get the schedule
>> set before folks start disappearing for the holidays.
>>
>> Note that this release will also switch us to the new versioning
>> scheme where the major version is incremented for each major release
>> (i.e., when the 4.0 branch is created, trunk will become 5.0).
>
> Maybe I didn't pay enough attention, but where is the general outline
> for this versioning scheme documented?  And are we still going to do
> 4.1, 4.2, etc?

There was a long discussion around the time when the 3.9 branch was
created. I'm planning on writing a blog post to make sure everyone is
up to date.

The idea is that Tom's stable releases will keep incrementing the
"patch" part of the version numbers, just as today, so they would be
4.0.1, 4.0.2, etc.

>> If you'd like to help providing binaries and testing for your
>> favourite platform, please subscribe to the release-testers mailing
>> list [1].
>>
>> I propose the following schedule for the 4.0 release:
>>
>> - 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.
>>
>> - 1 February: Tag RC2. All lose ends should have been tied up by now.
>>
>> - 21 February: Final tag. Binaries and release announcement a few days later.
>>
>> Unless there are any objections, I'll post this on the web page soon.
>
> Note that this is a pretty close follow-up to the 3.9.1 release.  There
> is a minor risk of "release burn-out" here... :)

Hopefully 3.9.1 will be done some time before 4.0.0 starts, otherwise
I agree that's not very good for the testers. I don't want to change
the schedule of the major releases though, as we've been on a nice
predictible 6-month cycle for a while now.

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

Re: [lldb-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Renato Golin via lldb-dev]

On 5 December 2016 at 18:56, Hans Wennborg via Release-testers
 wrote:
> The idea is that Tom's stable releases will keep incrementing the
> "patch" part of the version numbers, just as today, so they would be
> 4.0.1, 4.0.2, etc.

Hum, this looks weird. I was under the impression that we'd do 4.1, 4.2 instead.

Otherwise, it'll be:

* 3.9.0
* 3.9.1
* 4.0.0
* 4.0.1
* 5.0.0
* 5.0.1

With a totally redundant zero in the middle.

Unless we're planning to extend the maintenance of the 5.x branch and
release 5.1.0 *after* 6.0.0 is out, which would be a major change in
how we release LLVM. I don't think that's the plan.

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

Re: [lldb-dev] [cfe-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Mehdi Amini via lldb-dev]

> On Dec 5, 2016, at 12:07 PM, Hans Wennborg via cfe-dev 
>  wrote:
> 
> On Mon, Dec 5, 2016 at 12:02 PM, Renato Golin  > wrote:
>> On 5 December 2016 at 19:56, Hans Wennborg  wrote:
>>> I'd like to avoid 4.1 because of the potential for confusion about
>>> whether it's a major release (as it would have been under the old
>>> scheme) or a patch release.
>> 
>> But if the versioning scheme is different, users will have to
>> understand what it means anyway.
>> 
>> Until now we had a weird and very unique logic, and we're moving to a
>> more sensible logic, because it's similar to what some other projects
>> are doing.
>> 
>> I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
>> that used to be weird before.
>> 
>> After a few releases everything will be clear anyway... I really don't
>> want to make the foreseeable future weird again to avoid a potential
>> misunderstanding for one or two releases.
>> 
>> Let's just be brutally clear in all release communications and
>> hopefully people will understand.
>> 
>> 
>>> The alternative would be:
>>> 
>>> 3.9.0
>>> 3.9.1
>>> 4.0.0
>>> 4.1.0 <-- Can't tell from the version number what kind of release this is.
>> 
>> No, that has a redundant zero, too.
>> 
>> The alternative is:
>> 
>> 3.9.0
>> 3.9.1
>> 4.0
>> 4.1
>> 5.0
>> 5.1
> 
> I'm worried that users will, with some reason, think that the 4.1 and
> 5.1 releases are the same kind as 2.1 and 3.1 :-/

+1, I haven’t seen yet the downside of keeping the minor to 0 and bumping only 
the patch number.

— 
Mehdi


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

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

I am having no luck building LLDB with ninja, and there doesn't seem to be
a "package" target in the generated msbuild solution file, but here's something
interesting

I found in cmake files.  Could this be the reason why Python modules aren't
being installed on Windows?

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] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Michał Górny via lldb-dev]

On Mon, 5 Dec 2016 12:07:25 -0800
Hans Wennborg via lldb-dev  wrote:

> On Mon, Dec 5, 2016 at 12:02 PM, Renato Golin  wrote:
> > On 5 December 2016 at 19:56, Hans Wennborg  wrote:  
> >> I'd like to avoid 4.1 because of the potential for confusion about
> >> whether it's a major release (as it would have been under the old
> >> scheme) or a patch release.  
> >
> > But if the versioning scheme is different, users will have to
> > understand what it means anyway.
> >
> > Until now we had a weird and very unique logic, and we're moving to a
> > more sensible logic, because it's similar to what some other projects
> > are doing.
> >
> > I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
> > that used to be weird before.
> >
> > After a few releases everything will be clear anyway... I really don't
> > want to make the foreseeable future weird again to avoid a potential
> > misunderstanding for one or two releases.
> >
> > Let's just be brutally clear in all release communications and
> > hopefully people will understand.
> >
> >  
> >> The alternative would be:
> >>
> >> 3.9.0
> >> 3.9.1
> >> 4.0.0
> >> 4.1.0 <-- Can't tell from the version number what kind of release this is. 
> >>  
> >
> > No, that has a redundant zero, too.
> >
> > The alternative is:
> >
> > 3.9.0
> > 3.9.1
> > 4.0
> > 4.1
> > 5.0
> > 5.1  
> 
> I'm worried that users will, with some reason, think that the 4.1 and
> 5.1 releases are the same kind as 2.1 and 3.1 :-/

Just do 4a, 4b, 4c ;-). Everyone will be as confused as possible ;-).

-- 
Best regards,
Michał Górny



pgp4HL7kkQRBs.pgp
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Zachary Turner via lldb-dev]

I'm OOO this week, but I can look into that when I get back.  What issues
are you having with building LLDB with Ninja?

On Mon, Dec 5, 2016 at 4:04 PM Vadim Chugunov  wrote:

> I am having no luck building LLDB with ninja, and there doesn't seem to be
> a "package" target in the generated msbuild solution file, but here's 
> something
> interesting
> 
> I found in cmake files.  Could this be the reason why Python modules aren't
> being installed on Windows?
>
> 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] [cfe-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Michal
> Górny via cfe-dev
> Sent: Monday, December 05, 2016 3:33 PM
> To: Hans Wennborg via lldb-dev
> Cc: llvm-dev; Release-testers; openmp-dev (openmp-...@lists.llvm.org);
> cfe-dev
> Subject: Re: [cfe-dev] [lldb-dev] [Release-testers] [Openmp-dev] [4.0
> Release] Schedule and call for testers
> 
> On Mon, 5 Dec 2016 12:07:25 -0800
> Hans Wennborg via lldb-dev  wrote:
> 
> > On Mon, Dec 5, 2016 at 12:02 PM, Renato Golin 
> wrote:
> > > On 5 December 2016 at 19:56, Hans Wennborg  wrote:
> > >> I'd like to avoid 4.1 because of the potential for confusion about
> > >> whether it's a major release (as it would have been under the old
> > >> scheme) or a patch release.
> > >
> > > But if the versioning scheme is different, users will have to
> > > understand what it means anyway.
> > >
> > > Until now we had a weird and very unique logic, and we're moving to a
> > > more sensible logic, because it's similar to what some other projects
> > > are doing.
> > >
> > > I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
> > > that used to be weird before.
> > >
> > > After a few releases everything will be clear anyway... I really don't
> > > want to make the foreseeable future weird again to avoid a potential
> > > misunderstanding for one or two releases.
> > >
> > > Let's just be brutally clear in all release communications and
> > > hopefully people will understand.
> > >
> > >
> > >> The alternative would be:
> > >>
> > >> 3.9.0
> > >> 3.9.1
> > >> 4.0.0
> > >> 4.1.0 <-- Can't tell from the version number what kind of release
> this is.
> > >
> > > No, that has a redundant zero, too.
> > >
> > > The alternative is:
> > >
> > > 3.9.0
> > > 3.9.1
> > > 4.0
> > > 4.1
> > > 5.0
> > > 5.1
> >
> > I'm worried that users will, with some reason, think that the 4.1 and
> > 5.1 releases are the same kind as 2.1 and 3.1 :-/
> 
> Just do 4a, 4b, 4c ;-). Everyone will be as confused as possible ;-).

Back in the day, every version was identified as "Latest."
No possible confusion there!

I'm fine with "4.0.1" in keeping with the major.minor.patch convention,
given how the in-betweeners are really patch updates not minor versions.
--paulr

> 
> --
> Best regards,
> Michał Górny
> 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Conditionally adding sources to the build

[Pavel Labath via lldb-dev]

Hi,

I am not aware of anyone ever trying that. In theory it should work if you
copy the build and source folders to the other machine and run dotest.py
with the right arguments there, but I guess that is not what you meant by
"easy". The thing that I would try in this situation is to set it up so
that the build actually runs on the target device, but then use some distcc
tricks to offload the compilation to a more powerful machine. I am not sure
how easy would that be to setup though...

pl


On 2 December 2016 at 23:15, Dmitry Mikulin  wrote:

> I have a slightly unrelated question: is there an easy way to cross-build,
> say, an ARM lldb, and run native tests on an ARM board same as what
> check-lldb does? The lldb test page only talks about running remote tests.
> No info on cross testing.
>
> Thanks!
>
>
>
> On Dec 2, 2016, at 2:29 AM, Pavel Labath  wrote:
>
> I am glad to see freebsd is making progress on this front. If you need any
> help with understanding how lldb-server works, feel free to shoot me a
> question.
>
> pl
>
> On 1 December 2016 at 23:00, Dmitry Mikulin  wrote:
>
>> Thanks for the suggestions.
>> I’m working on native support for FreeBSD lldb-server, and wanted to have
>> an option to build it both ways until it’s stable enough to replace current
>> implementation. I’ll have it in a separate directory.
>>
>>
>> On Dec 1, 2016, at 2:55 AM, Pavel Labath  wrote:
>>
>> The way we have done this with Linux native register contexts was to
>> notionally leave the files in the build, but completely #ifdef out their
>> contents (see NativeRegisterConextLinux_arm.cpp).
>> It's not very nice, but I think it's better than having six subfolders,
>> each with a single cpp file. If you'll need to group more than one file
>> this way, then maybe a subfolder would make more sense though.
>>
>> pl
>>
>> On 1 December 2016 at 00:30, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Unfortunately you will need to separate them at the directory levels.
>>>
>>> On Wed, Nov 30, 2016 at 4:29 PM Dmitry Mikulin via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 Hi,

 I’m trying to conditionally add source files to the lldb build based on
 a cmake configure time variable. I get the following type of errors for all
 sources not included in the build:

 CMake Error at cmake/modules/LLVMProcessSources.cmake:83 (message):
   Found unknown source file
   /homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/Pl
 ugins/Process/FreeBSD/FreeBSDThread.cpp

   Please update
   /homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/Pl
 ugins/Process/FreeBSD/CMakeLists.txt

 Is there a way to work around/fix it or do I need to separate the files
 at the directory level?

 Thanks.
 Dmitry.

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

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

[lldb-dev] [Bug 31267] New: Can't reference variable named 'template'

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=31267

Bug ID: 31267
   Summary: Can't reference variable named 'template'
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: m...@xmission.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

In an Objective-C program, a local variable named 'template' is visible in the
local variables list, but can't be referenced by command lines.  For example, 

  po template

gives a cryptic error message rather than printing the value.  I assume the
problem may be related to the fact that 'template' is a reserved word in one of
the other languages supported by lldb (C++), so this may be indicative of a
more general problem of not being able to reference variables which have names
that coincide with reserved words in other supported languages, but I have not
verified this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev