Re: [lldb-dev] [cfe-dev] GitHub anyone?

[NAKAMURA Takumi via lldb-dev]

TL;DR :-)

Git-submodules works fine for bisecting for read-only use. I have the repo
to do that.
https://github.com/llvm-project/llvm-project-submodule

With a simple hooks/post-checkout, It should help effective bisecting.
https://github.com/chapuni/llvm-project-scripts/blob/master/hooks/post-checkout

It has refs/notes/commits, aka git-notes.

That said, I am afraid that submodules would lead us to the hell for
committers.
More discussions would be required to manage multiple git repos.

FYI, I have been using the unified repo,
https://github.com/llvm-project/llvm-project , for years.
It requires a wrapper script to invoke git-svn commit-diff.
___
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] GitHub anyone?

[Douglas Gregor via lldb-dev]

> On May 31, 2016, at 1:16 PM, Chris Lattner via cfe-dev 
>  wrote:
> 
>> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev 
>>  wrote:
>> There has been some discussion on IRC about SVN hosting and the perils
>> of doing it ourselves. The consensus on the current discussion was
>> that moving to a Git-only solution would have some disvantages, but
>> many advantages. Furthermore, not hosting our own repos would save us
>> a lot of headaches, admin costs and timed out connections.
> 
> Personally, I’m hugely in favor of moving llvm’s source hosting to github at 
> some point, despite the fact that I continue to dislike git as a tool and 
> consider monotonicly increasing version numbers to be hugely beneficial.
> 
> The killer feature to me is the community aspects of github, allowing people 
> to get involved in the project more easily and make “drive by” contributions 
> through the pull request model.  Github also has a very scriptable interface, 
> allowing integration of external bug trackers etc into the workflow (which is 
> good, because its bugtracker is anemic).

Full agreed.

> 
>> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
>> etc. Not only this incurs in additional admin cost, but it also gets
>> outdated, locally modified, and it needs to be backed up, etc. GitHub
>> gives all that for us for free.
> 
> Yes, it would be great to get out of this business.

Yep.

>> 6. GitHub has automated testing of merge requests, meaning we can have
>> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
>> own validation hooks.
> 
> This works pretty well.  The major problem is with tests that are flakey.

Performance can also be an issue; it takes a bunch of fast bots to keep up with 
developers testing their pull requests, especially when what you’re testing is 
a very large C++ code base. That said, “test and merge on success” workflows 
are *wonderful* for keeping the buildbots happy.

- Doug

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Saleem Abdulrasool via lldb-dev]

On Tue, May 31, 2016 at 12:51 PM, Tim Northover via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 31 May 2016 at 12:31, Renato Golin via cfe-dev
>  wrote:
> > What do people think? Any issue not covered that we should?
>
> I'm in favour of the move. Git-svn just about works most of the time,
> but I find it makes committing to release branches particularly
> painful. It also randomly corrupts its database occasionally, just for
> the giggles I assume.
>

I get hit by that every so often :-(.

As others have mentioned, the monotonically incrementing ids are extremely
useful, particularly when bisecting across clang/llvm.  I think that
Medhi's suggestion may be a viable solution.

As long as a mechanism for bisecting across the repositories is worked out,
definitely a +1 from me.


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



-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
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] GitHub anyone?

[Tom Honermann via lldb-dev]

On 5/31/2016 4:46 PM, Mehdi Amini via cfe-dev wrote:
> Apparently I wasn't very clear: llvm and clang (and the others projects) 
> would be simple decoupled, individual git repositories. You would be able to 
> check them out however you want and commit to them individually.
> There would be an extra "integration repository" on top that would only 
> provide the service that tells "r12345 is llvm:36c941c clang:eaf492b 
> compiler-rt:6d77ea5". This repository should be managed transparently by some 
> server-side integration.
> The provided scripting I was referring to would just be a convenience that is 
> using this extra layer of metadata ("integration repository") to be able 
> checkout the other individual repositories together at the right "rev-lock" 
> revision.
> This is not on your way if you don't want to use it, but it provides this 
> "single increase monotonic revision number across multiple repository" that 
> is convenient for some people.
>
> Makes sense?

Yes, makes sense; we have been doing exactly this for the last few 
months.  We created our own integration repo (to host our own build 
integration scripts) and cloned the llvm and clang repos from (I assume) 
https://github.com/llvm-mirror as sub-modules within it.  We're just 
using the native git command line to manage things and, so far, so good.

We're still working on getting a full continuous integration process in 
place (right now we manually pull periodically), but expect to have that 
soon.  The CI process is just to inform us of conflicts and allow us to 
resolve them proactively; we don't release product based on trunk.

Tom.

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Mehdi
> Amini via llvm-dev
> Sent: Tuesday, May 31, 2016 2:38 PM
> To: Bill Kelly
> Cc: LLVM Dev; Clang Dev; LLDB Dev
> Subject: Re: [llvm-dev] GitHub anyone?
> 
> 
> > On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev  d...@lists.llvm.org> wrote:
> >
> > Chris Lattner via llvm-dev wrote:
> >> Personally, I’m hugely in favor of moving llvm’s source hosting to
> github at
> >> some point, despite the fact that I continue to dislike git as a tool
> and
> >> consider monotonicly increasing version numbers to be hugely
> beneficial.
> >
> > For whatever it's worth, our projects define a `buildnum` git alias:
> >
> >  alias.buildnum=!sh -c "git rev-list --all | wc -l"

Or the cheaper "git rev-list --count --all" if your git is new enough.
We do something like this as well.

> >
> > So from the shell:
> >
> >  $ git buildnum
> >  17475
> >
> > This number increases monotonically per commit.
> 
> It does not work with branches though (we're not really planning to have
> branches I believe), 

You can get a per-branch unique number with this tactic.  On our local
branches we use "rev-list origin/master.." which is the number of commits
since branching from master, and that's enough for our local purposes.

> but more importantly it won't handle cross-repository
> versioning (how do you relate the number this command prints in the llvm
> repo to the number it'll print in the clang repo?), which I believe is
> something important considering our setup.

Is it really that important?  Or are we just used to the convenience?
If the Clang build number is a tuple (cfe-number, llvm-number) instead
of a single number, how horrible is that really?  If you consider what
an out-of-tree front end probably does, it's exactly the same thing.

(I admit that locally we mush cfe+llvm into a single branch and do the
rev-list count to get a single number. But that's more for our own
convenience than anything else.)
--paulr

> 
> --
> Mehdi
> 
> 
> 
> >
> >
> > Our build scripts make this number available in various #define forms.
> >
> > (We use a little extra scripting logic to also determine whether there
> > are currently any unmerged or uncommitted changes, and add an annotation
> > to the program version in that case, e.g.  "9.3.17475 [unmerged]")
> >
> >
> > It's all stupidly simple, but seems to work well enough for us.
> >
> >
> >
> > Regards,
> >
> > Bill
> >
> > ___
> > LLVM Developers mailing list
> > llvm-...@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: mehdi.am...@apple.com [mailto:mehdi.am...@apple.com]
> Sent: Tuesday, May 31, 2016 3:54 PM
> To: Robinson, Paul
> Cc: Bill Kelly; Clang Dev; LLDB Dev; llvm-...@lists.llvm.org
> Subject: Re: [llvm-dev] GitHub anyone?
> 
> 
> > On May 31, 2016, at 3:38 PM, Robinson, Paul 
> wrote:
> >
> >
> >
> >> -Original Message-
> >> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
> Mehdi
> >> Amini via llvm-dev
> >> Sent: Tuesday, May 31, 2016 2:38 PM
> >> To: Bill Kelly
> >> Cc: LLVM Dev; Clang Dev; LLDB Dev
> >> Subject: Re: [llvm-dev] GitHub anyone?
> >>
> >>
> >>> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev  >> d...@lists.llvm.org> wrote:
> >>>
> >>> Chris Lattner via llvm-dev wrote:
>  Personally, I’m hugely in favor of moving llvm’s source hosting to
> >> github at
>  some point, despite the fact that I continue to dislike git as a tool
> >> and
>  consider monotonicly increasing version numbers to be hugely
> >> beneficial.
> >>>
> >>> For whatever it's worth, our projects define a `buildnum` git alias:
> >>>
> >>> alias.buildnum=!sh -c "git rev-list --all | wc -l"
> >
> > Or the cheaper "git rev-list --count --all" if your git is new enough.
> > We do something like this as well.
> >
> >>>
> >>> So from the shell:
> >>>
> >>> $ git buildnum
> >>> 17475
> >>>
> >>> This number increases monotonically per commit.
> >>
> >> It does not work with branches though (we're not really planning to
> have
> >> branches I believe),
> >
> > You can get a per-branch unique number with this tactic.  On our local
> > branches we use "rev-list origin/master.." which is the number of
> commits
> > since branching from master, and that's enough for our local purposes.
> >
> >> but more importantly it won't handle cross-repository
> >> versioning (how do you relate the number this command prints in the
> llvm
> >> repo to the number it'll print in the clang repo?), which I believe is
> >> something important considering our setup.
> >
> > Is it really that important?  Or are we just used to the convenience?
> 
> I don't know how important it is. How would you bisect without this
> "convenience" for instance?
> (There is nothing like "push date" in git)

I know that on a single branch, "git bisect" deals with that for you.
I've seen the talk about submodules but I have no clue how that works
or whether git-bisect can operate cleanly in that situation.
--paulr

> 
> --
> Mehdi
> 
> 
> > If the Clang build number is a tuple (cfe-number, llvm-number) instead
> > of a single number, how horrible is that really?  If you consider what
> > an out-of-tree front end probably does, it's exactly the same thing.
> >
> > (I admit that locally we mush cfe+llvm into a single branch and do the
> > rev-list count to get a single number. But that's more for our own
> > convenience than anything else.)
> > --paulr
> >
> >>
> >> --
> >> Mehdi
> >>
> >>
> >>
> >>>
> >>>
> >>> Our build scripts make this number available in various #define forms.
> >>>
> >>> (We use a little extra scripting logic to also determine whether there
> >>> are currently any unmerged or uncommitted changes, and add an
> annotation
> >>> to the program version in that case, e.g.  "9.3.17475 [unmerged]")
> >>>
> >>>
> >>> It's all stupidly simple, but seems to work well enough for us.
> >>>
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Bill
> >>>
> >>> ___
> >>> LLVM Developers mailing list
> >>> llvm-...@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >> ___
> >> LLVM Developers mailing list
> >> llvm-...@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

[lldb-dev] June LLVM bay-area social is this Thursday!

[George Burgess IV via lldb-dev]

We'll be at Tied House as usual, starting on Thursday the 2nd at 7pm!
If you can, please help us plan and RSVP here: http://meetu.ps/2XyCml
See everyone there!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On May 31, 2016, at 4:06 PM, Robinson, Paul  wrote:
> 
> 
> 
>> -Original Message-
>> From: mehdi.am...@apple.com [mailto:mehdi.am...@apple.com]
>> Sent: Tuesday, May 31, 2016 3:54 PM
>> To: Robinson, Paul
>> Cc: Bill Kelly; Clang Dev; LLDB Dev; llvm-...@lists.llvm.org
>> Subject: Re: [llvm-dev] GitHub anyone?
>> 
>> 
>>> On May 31, 2016, at 3:38 PM, Robinson, Paul 
>> wrote:
>>> 
>>> 
>>> 
 -Original Message-
 From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
>> Mehdi
 Amini via llvm-dev
 Sent: Tuesday, May 31, 2016 2:38 PM
 To: Bill Kelly
 Cc: LLVM Dev; Clang Dev; LLDB Dev
 Subject: Re: [llvm-dev] GitHub anyone?
 
 
> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev >>> d...@lists.llvm.org> wrote:
> 
> Chris Lattner via llvm-dev wrote:
>> Personally, I’m hugely in favor of moving llvm’s source hosting to
 github at
>> some point, despite the fact that I continue to dislike git as a tool
 and
>> consider monotonicly increasing version numbers to be hugely
 beneficial.
> 
> For whatever it's worth, our projects define a `buildnum` git alias:
> 
> alias.buildnum=!sh -c "git rev-list --all | wc -l"
>>> 
>>> Or the cheaper "git rev-list --count --all" if your git is new enough.
>>> We do something like this as well.
>>> 
> 
> So from the shell:
> 
> $ git buildnum
> 17475
> 
> This number increases monotonically per commit.
 
 It does not work with branches though (we're not really planning to
>> have
 branches I believe),
>>> 
>>> You can get a per-branch unique number with this tactic.  On our local
>>> branches we use "rev-list origin/master.." which is the number of
>> commits
>>> since branching from master, and that's enough for our local purposes.
>>> 
 but more importantly it won't handle cross-repository
 versioning (how do you relate the number this command prints in the
>> llvm
 repo to the number it'll print in the clang repo?), which I believe is
 something important considering our setup.
>>> 
>>> Is it really that important?  Or are we just used to the convenience?
>> 
>> I don't know how important it is. How would you bisect without this
>> "convenience" for instance?
>> (There is nothing like "push date" in git)
> 
> I know that on a single branch, "git bisect" deals with that for you.

Sure, but our case is worse than branches: it is *cross repositories rev-locks".

> I've seen the talk about submodules but I have no clue how that works
> or whether git-bisect can operate cleanly in that situation.

Submodules is one solution, I gave some other pointers in this thread 
previously.

-- 
Mehdi


>> 
>> 
>> 
>>> If the Clang build number is a tuple (cfe-number, llvm-number) instead
>>> of a single number, how horrible is that really?  If you consider what
>>> an out-of-tree front end probably does, it's exactly the same thing.
>>> 
>>> (I admit that locally we mush cfe+llvm into a single branch and do the
>>> rev-list count to get a single number. But that's more for our own
>>> convenience than anything else.)
>>> --paulr
>>> 
 
 --
 Mehdi
 
 
 
> 
> 
> Our build scripts make this number available in various #define forms.
> 
> (We use a little extra scripting logic to also determine whether there
> are currently any unmerged or uncommitted changes, and add an
>> annotation
> to the program version in that case, e.g.  "9.3.17475 [unmerged]")
> 
> 
> It's all stupidly simple, but seems to work well enough for us.
> 
> 
> 
> Regards,
> 
> Bill
> 
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
 
 ___
 LLVM Developers mailing list
 llvm-...@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On May 31, 2016, at 3:38 PM, Robinson, Paul  wrote:
> 
> 
> 
>> -Original Message-
>> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Mehdi
>> Amini via llvm-dev
>> Sent: Tuesday, May 31, 2016 2:38 PM
>> To: Bill Kelly
>> Cc: LLVM Dev; Clang Dev; LLDB Dev
>> Subject: Re: [llvm-dev] GitHub anyone?
>> 
>> 
>>> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev > d...@lists.llvm.org> wrote:
>>> 
>>> Chris Lattner via llvm-dev wrote:
 Personally, I’m hugely in favor of moving llvm’s source hosting to
>> github at
 some point, despite the fact that I continue to dislike git as a tool
>> and
 consider monotonicly increasing version numbers to be hugely
>> beneficial.
>>> 
>>> For whatever it's worth, our projects define a `buildnum` git alias:
>>> 
>>> alias.buildnum=!sh -c "git rev-list --all | wc -l"
> 
> Or the cheaper "git rev-list --count --all" if your git is new enough.
> We do something like this as well.
> 
>>> 
>>> So from the shell:
>>> 
>>> $ git buildnum
>>> 17475
>>> 
>>> This number increases monotonically per commit.
>> 
>> It does not work with branches though (we're not really planning to have
>> branches I believe), 
> 
> You can get a per-branch unique number with this tactic.  On our local
> branches we use "rev-list origin/master.." which is the number of commits
> since branching from master, and that's enough for our local purposes.
> 
>> but more importantly it won't handle cross-repository
>> versioning (how do you relate the number this command prints in the llvm
>> repo to the number it'll print in the clang repo?), which I believe is
>> something important considering our setup.
> 
> Is it really that important?  Or are we just used to the convenience?

I don't know how important it is. How would you bisect without this 
"convenience" for instance?
(There is nothing like "push date" in git)

-- 
Mehdi


> If the Clang build number is a tuple (cfe-number, llvm-number) instead
> of a single number, how horrible is that really?  If you consider what
> an out-of-tree front end probably does, it's exactly the same thing.
> 
> (I admit that locally we mush cfe+llvm into a single branch and do the
> rev-list count to get a single number. But that's more for our own
> convenience than anything else.)
> --paulr
> 
>> 
>> --
>> Mehdi
>> 
>> 
>> 
>>> 
>>> 
>>> Our build scripts make this number available in various #define forms.
>>> 
>>> (We use a little extra scripting logic to also determine whether there
>>> are currently any unmerged or uncommitted changes, and add an annotation
>>> to the program version in that case, e.g.  "9.3.17475 [unmerged]")
>>> 
>>> 
>>> It's all stupidly simple, but seems to work well enough for us.
>>> 
>>> 
>>> 
>>> Regards,
>>> 
>>> Bill
>>> 
>>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Matthias Braun via lldb-dev]

> On May 31, 2016, at 3:01 PM, Joerg Sonnenberger via llvm-dev 
>  wrote:
> 
> On Tue, May 31, 2016 at 02:43:02PM -0700, Matthias Braun wrote:
>> 
>>> On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev 
>>>  wrote:
>>> 
>>> On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote:
 To be more exact here: I usually do not checkout llvm svn at a higher
 level because that forces me back to svn (which last time I used it did
 not have built-in support for bisection, not sure if that changed
 recently).
>>> 
>>> svn-bisect is a trival tool and should be part of every good svn
>>> installation. While I never got around to script the part of "update all
>>> subrepos to the same revision", it certainly doesn't involve any
>>> addition checks. From what I can tell, git submodules don't even support
>>> that easily. I might be wrong though.
>> 
>> In a nutshell:
>> git-submodules basically records a git revision of your submodules with the 
>> commits.
>> You can make such revision switches a natural part of commits.
>> "git submodule update [--recursive]" will bring your submodule checkouts in 
>> sync with what the toplevel repository expects.
>> 
>> In any way we can have this discussion separate from the discussion of 
>> moving to git. We can stay with our current ways of matching same date for 
>> now.
> 
> But the move to git introduces the UI regression in first place. No date
> matching and the like is necessary with subversion.

True to some extend, though I know several people (myself included) that rather 
use the git-svn inconvenience today simply because git-bisect exists and git 
being a lot faster at switching revisions than subversion. This tactic also 
starts failing once you work with custom release branches outside of llvm.org's 
control.
In principle you could also put the toplevel llvm svn into a git-svn repository 
to fix the problems and I think there is some repository out there who does 
that, but IMO that just brings back part of the problem of slow checkouts (a 
few gigabytes of extra disk space required per checkout as well).

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

Re: [lldb-dev] Inquiry regarding AddOneMoreFrame function in UnWindLLDB

[Jason Molenda via lldb-dev]

> On May 31, 2016, at 11:31 AM, jing...@apple.com wrote:
> 
> 
>> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev 
>>  wrote:
>> 
>> Hello,
>>  I posted this query a while ago, i still have no answers, I am 
>> currently working on Bug 27687 (PrintStackTraces), so the reason for the 
>> failure is the erroneous unwinding of the frames from the zeroth frame. The 
>> error is not detected in AddOneMoreFrame, since it only checks for 2 more 
>> frames, if it was checking more frames in AddOneMoreFrame, it would have 
>> detected the error. Now my questions are ->
>> 
>> ->  is that is there any specific reason for only checking 2 frames instead 
>> of more ?
> 
> The stepping machinery uses the unwinder on each stop to figure out whether 
> it has stepped in or out, which is fairly performance sensitive, so we don't 
> want AddOneMoreFrame to do more work than it has to.  


Most common case for a bad unwind, where the unwinder is stuck in a loop, is a 
single stack frame repeating.  I've seen loops as much as six frames repeating 
(which are not actually a series of recursive calls) but it's less common.

> 
>> ->  Why no make the EH CFI based unwinder the default one and make the 
>> assembly the fallback ?


Sources of unwind information fall into two categories.  They can describe the 
unwind state at every instruction of a function (asynchronous) or they can 
describe the unwind state only at function call boundaries (synchronous).

Think of "asynchronous" here as the fact that the debugger can interrupt the 
program at any point in time.

Most unwind information is designed for exception handling -- it is 
synchronous, it can only throw an exception in the body of the function, or an 
exception is passed up through it when it is calling another function.  

For exception handling, there is no need/requirement to describe the prologue 
or epilogue instructions, for instance.

eh_frame (and DWARF's debug_frame from which it derives) splits the difference 
and makes things quite unclear.  It is guaranteed to be correct for exception 
handling -- it is synchronous, and is valid in the middle of the function and 
when it is calling other functions -- but it is a general format that CAN be 
asynchronous if the emitter includes information about the prologue or epilogue 
or mid-function stack changes.  But eh_frame is not guaranteed to be that way, 
and in fact there's no way for it to indicate what it describes, beyond the 
required unwind info for exception handling.

On x86, gcc and clang have always described the prologue unwind info in their 
eh_frame.  gcc has recently started describing the epilogue too (clang does 
not).  There's code in lldb (e.g. 
UnwindAssembly_x86::AugmentUnwindPlanFromCallSite) written by Tong Shen when 
interning at Google which will try to detect if the eh_frame describes the 
prologue and epilogue.  If it does, it will use eh_frame for frame 0.  If it 
only describes the prologue, it will use the instruction emulation code to add 
epilogue instructions and use that at frame 0.


There are other sources of unwind information similar to eh_frame that are only 
for exception handling.  Tamas added ArmUnwindInfo last year which reads the 
.ARM.exidx unwind tables.  I added compact unwind importing - an Apple specific 
format that uses a single 4-byte word to describe the unwind state for each 
function, which can't describe anything in the prologue/epilogue.  These 
formats definitely can't be used to unwind at frame 0 because we could be 
stopped anywhere in the prologue/epilogue where they are not accurate.


It's unfortunate that eh_frame doesn't include a way for the producer to 
declare how async the unwind info is, it makes the debugger's job a lot more 
difficult.


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

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Joerg Sonnenberger via lldb-dev]

On Tue, May 31, 2016 at 02:43:02PM -0700, Matthias Braun wrote:
> 
> > On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev 
> >  wrote:
> > 
> > On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote:
> >> To be more exact here: I usually do not checkout llvm svn at a higher
> >> level because that forces me back to svn (which last time I used it did
> >> not have built-in support for bisection, not sure if that changed
> >> recently).
> > 
> > svn-bisect is a trival tool and should be part of every good svn
> > installation. While I never got around to script the part of "update all
> > subrepos to the same revision", it certainly doesn't involve any
> > addition checks. From what I can tell, git submodules don't even support
> > that easily. I might be wrong though.
> 
> In a nutshell:
> git-submodules basically records a git revision of your submodules with the 
> commits.
> You can make such revision switches a natural part of commits.
> "git submodule update [--recursive]" will bring your submodule checkouts in 
> sync with what the toplevel repository expects.
> 
> In any way we can have this discussion separate from the discussion of moving 
> to git. We can stay with our current ways of matching same date for now.

But the move to git introduces the UI regression in first place. No date
matching and the like is necessary with subversion.

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Matthias Braun via lldb-dev]

> On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev 
>  wrote:
> 
> On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote:
>> To be more exact here: I usually do not checkout llvm svn at a higher
>> level because that forces me back to svn (which last time I used it did
>> not have built-in support for bisection, not sure if that changed
>> recently).
> 
> svn-bisect is a trival tool and should be part of every good svn
> installation. While I never got around to script the part of "update all
> subrepos to the same revision", it certainly doesn't involve any
> addition checks. From what I can tell, git submodules don't even support
> that easily. I might be wrong though.

In a nutshell:
git-submodules basically records a git revision of your submodules with the 
commits.
You can make such revision switches a natural part of commits.
"git submodule update [--recursive]" will bring your submodule checkouts in 
sync with what the toplevel repository expects.

In any way we can have this discussion separate from the discussion of moving 
to git. We can stay with our current ways of matching same date for now.

- Matthias

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

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[Florent Castelli via lldb-dev]

My company is using submodules for the better or worse. It's not a perfect
solution but it can work when using a version of git recent enough and some
tooling.

The magic command to update everything to the current commit pointed by
each submodule : git submodules update --init --recursive
To get the latest version you can do: git submodules --init --recursive
--remote
This by default will get the latest version of master, but a change in the
.gitmodules file can make it point to release branches.

If you want a stable version from days ago, you can have a bot updating the
submodules everyday and pushing the submodules update, then use that
commit.
With a bot like this, manual submodule bumps should be rare and people non
familiar with git will soon forget about those.

For a linear history, you can have GitHub doing a rebase when merging the
changes instead of a merge. I would recommend to do that to keep the
history clean and have less "fixup" or "wip" commits in the history.

For the people who want to keep SVN, I've tried the compatibility layer
from GitHub and it worked well enough for me in the past. But I would
recommend to write a cheat sheet to help people migrate to Git long-term.
Recent versions of git are not as hard to use as the old versions of git
and it doesn't have to be more complicated than SVN.

/Florent
On May 31, 2016 22:43, "Aaron Ballman via cfe-dev" 
wrote:

> On Tue, May 31, 2016 at 4:27 PM, Renato Golin 
> wrote:
> > On 31 May 2016 at 21:24, Aaron Ballman  wrote:
> >> Are we sure that github's svn integration works with common tools on
> >> Windows, like TortoiseSVN?
> >
> > That's a good question. Can you try them out and report back?
>
> From my very simple testing, yes. However, since I don't use github
> for much, it's hard to feel comfortable with my level of testing. I'm
> sure for read-only access, this will be sufficient. For read/write
> access, I am less confident, so if others have had more experience
> with this on Windows, I would appreciate hearing about it.
>
> ~Aaron
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Mehmet Erol Sanliturk via lldb-dev]

On Tue, May 31, 2016 at 1:23 PM, Reid Kleckner via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> I'm in favor of both going to git as the source of truth, and then
> switching the hosting to github.
>
> Echoing everyone else, this unlocks a lot of good stuff that I won't
> repeat, and most of it can be handled independently from the VCS move.
>
> The major blocker I see for the move is figuring out how we want to
> coordinate versions between the related LLVM projects. I hear *terrible*
> things about submodules, so I'd prefer a different sync mechanism, even if
> it is a bad reimplementation of repo, gclient, submodules, and all the
> other multi-repo sync tools.
>
>



In previous months , I have studied many thousands of Github repositories ,
and cloned many of them locally to compile and run .


The following difficulties may exist during LLVM works :


If a directory contains large number ( approximately more than thousand )
of files , only a part of these files are displayed and others are not
allowed to view . You may check this from OS repositories .


During cloning , if there is a reference to another repository , clone
--recursive are giving errors about contained @ sign . In that case it is
necessary to enter into sub-directories and manually clone that referenced
sub-module ( or a script should do this ) . Instead of --recursive , the
other statements may be used , but all of them have
advantages/disadvantages .


When "Download" is selected for repository , sub-modules are not downloaded
into respective sub-directories . It is necessary to visit such directories
manually one by one and download , expand , and adjust these directory
contents .


When a file is viewed in Github and returned back , Github is switching to
the top of the directory , not aligning the page at the current cursor
position . When there are large number of files in a directory , it is
causing difficulty to go down to the current cursor position  again and
continue from there .


A limited kind and size of files are shown to the user . There are many
kinds that it is possible to only viewing the content is to save repository
locally . To my experience , any single file in a repository directory is
not permitted to download to view it in that case .


I consider revision numbers as only a disastrous design : A very long
number conveying nothing other than inconvenience . Therefore it will not
be possible to specify "revert to _a_simple_number_"  elegantly . I do not
know what will be shown to say "revert to _a_cryptic_number_" .


Previously it was possible to search Github for repositories on supplied
keywords . Now , they have disabled that feature . Now , it seems only
Internet searches may find a repository ( to my experience , only very few
of them are found ) , or it may be listed in their category lists to find
only ones selected by Github .


 The most affecting points are the above ones for me as a "visitor user" of
Github repositories .
I do not have any experience as "developer user"  of Github .


Mehmet Erol Sanliturk







> On Tue, May 31, 2016 at 12:31 PM, Renato Golin via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> Folks,
>>
>> There has been some discussion on IRC about SVN hosting and the perils
>> of doing it ourselves. The consensus on the current discussion was
>> that moving to a Git-only solution would have some disvantages, but
>> many advantages. Furthermore, not hosting our own repos would save us
>> a lot of headaches, admin costs and timed out connections.
>>
>> TL;DR: GitHub + git submodules [1] could replace all the functionality
>> we have currently with SVN.
>>
>> (also GitLab, BitBucketc, etc).
>>
>> Here are some of the arguments made on IRC...
>>
>> 1. Due to SVN, we can't re-write history. If we use some GitHub
>> properties [2], we could have the same effect.
>>
>> 2. Due to SVN, we have a mandatory time sequence, so commits go first
>> in LLVM, then Clang (for example), and buildbots don't get lost. If we
>> use submodules [1], we can have a similar relationship, but in a more
>> explicit way, and the problem could be solved elegantly.
>>
>> 3. Some people still can only use SVN. For that, GitHub has an SVN
>> interface [3] to the repositories.
>>
>> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
>> etc. Not only this incurs in additional admin cost, but it also gets
>> outdated, locally modified, and it needs to be backed up, etc. GitHub
>> gives all that for us for free.
>>
>> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
>> we can also use GitHub's system to manage releases (it's actually
>> quite good for that).
>>
>> 6. GitHub has automated testing of merge requests, meaning we can have
>> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
>> own validation hooks. Even though that wouldn't cover everything,
>> having a few pre-commit bots would considerably reduce the need to
>> revert patches [citation needed]

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Bill Kelly via lldb-dev]

Chris Lattner via llvm-dev wrote:
> Personally, I’m hugely in favor of moving llvm’s source hosting to github at
> some point, despite the fact that I continue to dislike git as a tool and
> consider monotonicly increasing version numbers to be hugely beneficial.

For whatever it's worth, our projects define a `buildnum` git alias:

  alias.buildnum=!sh -c "git rev-list --all | wc -l"

So from the shell:

  $ git buildnum
  17475

This number increases monotonically per commit.


Our build scripts make this number available in various #define forms.

(We use a little extra scripting logic to also determine whether there
are currently any unmerged or uncommitted changes, and add an annotation
to the program version in that case, e.g.  "9.3.17475 [unmerged]")


It's all stupidly simple, but seems to work well enough for us.



Regards,

Bill

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Matthias Braun via lldb-dev]

> On May 31, 2016, at 1:42 PM, Matthias Braun  wrote:
> 
>> 
>> On May 31, 2016, at 1:31 PM, Joerg Sonnenberger via llvm-dev 
>>  wrote:
>> 
>> On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote:
>>> On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev
>>>  wrote:
 Folks,
 
 There has been some discussion on IRC about SVN hosting and the perils
 of doing it ourselves. The consensus on the current discussion was
 that moving to a Git-only solution would have some disvantages, but
 many advantages. Furthermore, not hosting our own repos would save us
 a lot of headaches, admin costs and timed out connections.
>>> 
>>> Not everyone thinks git is a step forward. Please do not force people
>>> to use a "git-only" solution.
>> 
>> Amen.
>> 
 2. Due to SVN, we have a mandatory time sequence, so commits go first
 in LLVM, then Clang (for example), and buildbots don't get lost. If we
 use submodules [1], we can have a similar relationship, but in a more
 explicit way, and the problem could be solved elegantly.
>>> 
>>> I actually consider the monotonically increasing revisions to be a
>>> feature, but not sufficient to warrant a decision one way or the
>>> other.
>> 
>> Has the situation with git-submodules and bisect improved at all or is
>> bisecting clang+llvm going to be manual mess?
> I found bisecting with submodules (in another project) far superior to the 
> manual mess I have to do in clang+llvm today.
To be more exact here: I usually do not checkout llvm svn at a higher level 
because that forces me back to svn (which last time I used it did not have 
built-in support for bisection, not sure if that changed recently). So while I 
have a consistent state in svn I spend the time manually calculating the next 
commit to checkout. So what I do instead is using git for bisecting and having 
some (brittle) scripts that sync multiple git repositories to use a commit from 
the same time!

- Matthias

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

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[Alexey Bataev via lldb-dev]

+1 for git

Best regards,
Alexey Bataev

> 31 мая 2016 г., в 22:31, Renato Golin via cfe-dev  
> написал(а):
> 
> Folks,
> 
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solution would have some disvantages, but
> many advantages. Furthermore, not hosting our own repos would save us
> a lot of headaches, admin costs and timed out connections.
> 
> TL;DR: GitHub + git submodules [1] could replace all the functionality
> we have currently with SVN.
> 
> (also GitLab, BitBucketc, etc).
> 
> Here are some of the arguments made on IRC...
> 
> 1. Due to SVN, we can't re-write history. If we use some GitHub
> properties [2], we could have the same effect.
> 
> 2. Due to SVN, we have a mandatory time sequence, so commits go first
> in LLVM, then Clang (for example), and buildbots don't get lost. If we
> use submodules [1], we can have a similar relationship, but in a more
> explicit way, and the problem could be solved elegantly.
> 
> 3. Some people still can only use SVN. For that, GitHub has an SVN
> interface [3] to the repositories.
> 
> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
> etc. Not only this incurs in additional admin cost, but it also gets
> outdated, locally modified, and it needs to be backed up, etc. GitHub
> gives all that for us for free.
> 
> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
> we can also use GitHub's system to manage releases (it's actually
> quite good for that).
> 
> 6. GitHub has automated testing of merge requests, meaning we can have
> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
> own validation hooks. Even though that wouldn't cover everything,
> having a few pre-commit bots would considerably reduce the need to
> revert patches [citation needed].
> 
> 7. With git submodules, we'd probably want to follow the same style we
> have today (llvm-projects/) instead of modelling how they look in
> tree (llvm/tools/clang still as a symlink).
> 
> 8. Once we're solo Git, we can shop around *much* more easily. By
> using SVN, we're basically forced to host, or choose Source Forge.
> Using just Git, we can choose GitLab, BitBucket and many others, if
> GitHub is not appealing enough. Essentially, it doesn't matter where
> you are, the tools are good, there and largely replaceable [citation
> needed].
> 
> What do people think? Any issue not covered that we should? How would
> that disrupt downstream users? Would it be a temporary disruption, but
> with long lasting benefits? Or will it just break everything for you?
> 
> cheers,
> --renato
> 
> 
> [1] https://git-scm.com/book/en/v2/Git-Tools-Submodules
> [2] 
> https://help.github.com/articles/defining-the-mergeability-of-pull-requests/
> [3] https://help.github.com/articles/support-for-subversion-clients/
> 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Matthias Braun via lldb-dev]

> On May 31, 2016, at 1:31 PM, Joerg Sonnenberger via llvm-dev 
>  wrote:
> 
> On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote:
>> On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev
>>  wrote:
>>> Folks,
>>> 
>>> There has been some discussion on IRC about SVN hosting and the perils
>>> of doing it ourselves. The consensus on the current discussion was
>>> that moving to a Git-only solution would have some disvantages, but
>>> many advantages. Furthermore, not hosting our own repos would save us
>>> a lot of headaches, admin costs and timed out connections.
>> 
>> Not everyone thinks git is a step forward. Please do not force people
>> to use a "git-only" solution.
> 
> Amen.
> 
>>> 2. Due to SVN, we have a mandatory time sequence, so commits go first
>>> in LLVM, then Clang (for example), and buildbots don't get lost. If we
>>> use submodules [1], we can have a similar relationship, but in a more
>>> explicit way, and the problem could be solved elegantly.
>> 
>> I actually consider the monotonically increasing revisions to be a
>> feature, but not sufficient to warrant a decision one way or the
>> other.
> 
> Has the situation with git-submodules and bisect improved at all or is
> bisecting clang+llvm going to be manual mess?
I found bisecting with submodules (in another project) far superior to the 
manual mess I have to do in clang+llvm today.

- Matthias

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Matthias Braun via lldb-dev]

Strong +1 to move to an external hosted git sooner rather than later!

1) I personally had very good experiences with git submodules. They are 
certainly harder to get used to as you have to learn a bunch of extra magic on 
top of the already magical git: i.e. "git clone --recurse-submodules", then 
learn how to have your submodules point to different commits locally sometimes, 
etc.
I have had very good experience in another project that used to do llvm/clang 
style "just checkout those two project at the same date" and I found submodules 
more stable and robust and technically superior solution at the cost of a 
higher bar learning curve for new contributors.

So in this context I would recommend to change one thing at a time and only 
switch svn->git in step 1 and leave the switch to submodules as a 2nd step (or 
not do it at all if that is community consensus).

2) As far as the "increasing revision" numbers go: In my opinion this is about:
 - We really should stay with a linear history and not introduce merge 
commits.
 - As long as we do not move to submodules we need a solution to enforce 
"CommitDate"s (or also "AuthorDate"s) to be the time a commit was pushed to the 
server so our current workflow of checking out llvm/clang at the same time 
still works.
   I believe that those two points to be solvable with some server side 
scripting. With those two properties in place actual increasing numeric 
revision numbers bring that much value to the table and I would assume we can 
go without them.

- Matthias

> On May 31, 2016, at 1:28 PM, Mehdi Amini via llvm-dev 
>  wrote:
> 
>> 
>> On May 31, 2016, at 1:16 PM, Chris Lattner via llvm-dev 
>> mailto:llvm-...@lists.llvm.org>> wrote:
>> 
>>> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev 
>>> mailto:llvm-...@lists.llvm.org>> wrote:
>>> There has been some discussion on IRC about SVN hosting and the perils
>>> of doing it ourselves. The consensus on the current discussion was
>>> that moving to a Git-only solution would have some disvantages, but
>>> many advantages. Furthermore, not hosting our own repos would save us
>>> a lot of headaches, admin costs and timed out connections.
>> 
>> Personally, I’m hugely in favor of moving llvm’s source hosting to github at 
>> some point, despite the fact that I continue to dislike git as a tool and 
>> consider monotonicly increasing version numbers to be hugely beneficial.
> 
> Getting a monotonically increasing revision number seems doable in git with 
> some server-side scripting using git notes or named tags (yet to be seen is 
> how to achieve it *reliably* with github hosting).
> However the challenge is more about sharing this number across repositories 
> (i.e. having clang and llvm in sync). I can imagine some tooling for that, 
> but with a github hosting it may still be fragile.
> 
> Ideally, I'd prefer the cross-repository to be handled with an extra layer, 
> in a way similar as described in: 
> https://gerrit-review.googlesource.com/Documentation/user-submodules.htm 
>  
> (somehow conceptually similar to Android manifests XML files). 
> It would be easy to have tooling/scripts for llvm that would easily say 
> "checkout llvm+clang+compiler-rt+libcxx+clang-extra here", or "update all 
> llvm subproject under this root", or "checkout this specific revision for all 
> these" (with a monotonic number for the revision).
> 
> (+1 to all the rest of what you wrote)
> 
> -- 
> Mehdi
> 
> 
>> The killer feature to me is the community aspects of github, allowing people 
>> to get involved in the project more easily and make “drive by” contributions 
>> through the pull request model.  Github also has a very scriptable 
>> interface, allowing integration of external bug trackers etc into the 
>> workflow (which is good, because its bugtracker is anemic).
>> 
>>> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
>>> etc. Not only this incurs in additional admin cost, but it also gets
>>> outdated, locally modified, and it needs to be backed up, etc. GitHub
>>> gives all that for us for free.
>> 
>> Yes, it would be great to get out of this business.
>> 
>>> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
>>> we can also use GitHub's system to manage releases (it's actually
>>> quite good for that).
>> 
>> If we made this change, I think we should only change one thing at a time: 
>> change source hosting, but not phabricator or the bug tracker.  We could 
>> then discuss moving off phabricator to the github PR model, etc.
>> 
>>> 6. GitHub has automated testing of merge requests, meaning we can have
>>> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
>>> own validation hooks.
>> 
>> This works pretty well.  The major problem is with tests that are flakey.
>> 
>> -Chris
>> ___
>> LLVM Developers mailing list
>> llvm-.

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev 
>  wrote:
> 
> Chris Lattner via llvm-dev wrote:
>> Personally, I’m hugely in favor of moving llvm’s source hosting to github at
>> some point, despite the fact that I continue to dislike git as a tool and
>> consider monotonicly increasing version numbers to be hugely beneficial.
> 
> For whatever it's worth, our projects define a `buildnum` git alias:
> 
>  alias.buildnum=!sh -c "git rev-list --all | wc -l"
> 
> So from the shell:
> 
>  $ git buildnum
>  17475
> 
> This number increases monotonically per commit.

It does not work with branches though (we're not really planning to have 
branches I believe), but more importantly it won't handle cross-repository 
versioning (how do you relate the number this command prints in the llvm repo 
to the number it'll print in the clang repo?), which I believe is something 
important considering our setup.

-- 
Mehdi



> 
> 
> Our build scripts make this number available in various #define forms.
> 
> (We use a little extra scripting logic to also determine whether there
> are currently any unmerged or uncommitted changes, and add an annotation
> to the program version in that case, e.g.  "9.3.17475 [unmerged]")
> 
> 
> It's all stupidly simple, but seems to work well enough for us.
> 
> 
> 
> Regards,
> 
> Bill
> 
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On May 31, 2016, at 2:07 PM, Tim Northover  wrote:
> 
> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
>  wrote:
>> Apparently I wasn't very clear: llvm and clang (and the others projects) 
>> would be simple decoupled, individual git repositories. You would be able to 
>> check them out however you want and commit to them individually.
>> There would be an extra "integration repository" on top that would only 
>> provide the service that tells "r12345 is llvm:36c941c clang:eaf492b 
>> compiler-rt:6d77ea5". This repository should be managed transparently by 
>> some server-side integration.
> 
> This actually sounds like a really good idea even if a full move to
> git gets blocked for some reason. It seems like it could be a fairly
> common requirement: I don't suppose you know of an existing script
> that could do it? If not, I may take a stab.

I don't know of a script that would update this automatically, but the Gerrit 
feature seems pretty close: 
https://gerrit-review.googlesource.com/Documentation/user-submodules.html ; and 
it is possible that some Android tooling exists around the repo tool: 
https://source.android.com/source/developing.html

I think it is fairly easy to setup tools that do that, it is harder to do it 
reliably (i.e. handle concurrent push in clang and llvm for instance), or what 
if the server-side script fails the update because of a network issue?  Maybe 
it is not very important and one commit won't be part of the "global 
numbering"? Alternatively the push can be "failed" in such cases?

-- 
Mehdi

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Tim Northover via lldb-dev]

On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
 wrote:
> Apparently I wasn't very clear: llvm and clang (and the others projects) 
> would be simple decoupled, individual git repositories. You would be able to 
> check them out however you want and commit to them individually.
> There would be an extra "integration repository" on top that would only 
> provide the service that tells "r12345 is llvm:36c941c clang:eaf492b 
> compiler-rt:6d77ea5". This repository should be managed transparently by some 
> server-side integration.

This actually sounds like a really good idea even if a full move to
git gets blocked for some reason. It seems like it could be a fairly
common requirement: I don't suppose you know of an existing script
that could do it? If not, I may take a stab.

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Joerg Sonnenberger via lldb-dev]

On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote:
> To be more exact here: I usually do not checkout llvm svn at a higher
> level because that forces me back to svn (which last time I used it did
> not have built-in support for bisection, not sure if that changed
> recently).

svn-bisect is a trival tool and should be part of every good svn
installation. While I never got around to script the part of "update all
subrepos to the same revision", it certainly doesn't involve any
addition checks. From what I can tell, git submodules don't even support
that easily. I might be wrong though.

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On May 31, 2016, at 1:31 PM, Renato Golin  wrote:
> 
> On 31 May 2016 at 21:28, Mehdi Amini  wrote:
>> Ideally, I'd prefer the cross-repository to be handled with an extra layer, 
>> in a way similar as described in: 
>> https://gerrit-review.googlesource.com/Documentation/user-submodules.htm 
>> (somehow conceptually similar to Android manifests XML files).
>> It would be easy to have tooling/scripts for llvm that would easily say 
>> "checkout llvm+clang+compiler-rt+libcxx+clang-extra here", or "update all 
>> llvm subproject under this root", or "checkout this specific revision for 
>> all these" (with a monotonic number for the revision).
> 
> At Linaro, we already have a set of scripts that do that. We're now
> moving to git worktree, and I think it's going to simplify our work
> considerably. But honestly, I'd rather not force anyone to use any set
> of scripts, and let people work directly with git, so I'd be more in
> favour of having a server-side solution, if at all possible.

Apparently I wasn't very clear: llvm and clang (and the others projects) would 
be simple decoupled, individual git repositories. You would be able to check 
them out however you want and commit to them individually.
There would be an extra "integration repository" on top that would only provide 
the service that tells "r12345 is llvm:36c941c clang:eaf492b 
compiler-rt:6d77ea5". This repository should be managed transparently by some 
server-side integration.
The provided scripting I was referring to would just be a convenience that is 
using this extra layer of metadata ("integration repository") to be able 
checkout the other individual repositories together at the right "rev-lock" 
revision.
This is not on your way if you don't want to use it, but it provides this 
"single increase monotonic revision number across multiple repository" that is 
convenient for some people.

Makes sense?

-- 
Medhi

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

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[Aaron Ballman via lldb-dev]

On Tue, May 31, 2016 at 4:27 PM, Renato Golin  wrote:
> On 31 May 2016 at 21:24, Aaron Ballman  wrote:
>> Are we sure that github's svn integration works with common tools on
>> Windows, like TortoiseSVN?
>
> That's a good question. Can you try them out and report back?

From my very simple testing, yes. However, since I don't use github
for much, it's hard to feel comfortable with my level of testing. I'm
sure for read-only access, this will be sufficient. For read/write
access, I am less confident, so if others have had more experience
with this on Windows, I would appreciate hearing about it.

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

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[Joerg Sonnenberger via lldb-dev]

On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote:
> On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev
>  wrote:
> > Folks,
> >
> > There has been some discussion on IRC about SVN hosting and the perils
> > of doing it ourselves. The consensus on the current discussion was
> > that moving to a Git-only solution would have some disvantages, but
> > many advantages. Furthermore, not hosting our own repos would save us
> > a lot of headaches, admin costs and timed out connections.
> 
> Not everyone thinks git is a step forward. Please do not force people
> to use a "git-only" solution.

Amen.

> > 2. Due to SVN, we have a mandatory time sequence, so commits go first
> > in LLVM, then Clang (for example), and buildbots don't get lost. If we
> > use submodules [1], we can have a similar relationship, but in a more
> > explicit way, and the problem could be solved elegantly.
> 
> I actually consider the monotonically increasing revisions to be a
> feature, but not sufficient to warrant a decision one way or the
> other.

Has the situation with git-submodules and bisect improved at all or is
bisecting clang+llvm going to be manual mess?

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Renato Golin via lldb-dev]

On 31 May 2016 at 21:28, Mehdi Amini  wrote:
> Ideally, I'd prefer the cross-repository to be handled with an extra layer, 
> in a way similar as described in: 
> https://gerrit-review.googlesource.com/Documentation/user-submodules.htm 
> (somehow conceptually similar to Android manifests XML files).
> It would be easy to have tooling/scripts for llvm that would easily say 
> "checkout llvm+clang+compiler-rt+libcxx+clang-extra here", or "update all 
> llvm subproject under this root", or "checkout this specific revision for all 
> these" (with a monotonic number for the revision).

At Linaro, we already have a set of scripts that do that. We're now
moving to git worktree, and I think it's going to simplify our work
considerably. But honestly, I'd rather not force anyone to use any set
of scripts, and let people work directly with git, so I'd be more in
favour of having a server-side solution, if at all possible.

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

Re: [lldb-dev] TODAY! Updating to CMake 3.4.3

[Kate Stone via lldb-dev]

Have you investigated the impact of the merge downstream to the Swift enabled 
LLDB in GitHub?  It's staged, so we shouldn't do it immediately but it would be 
helpful to know what to expect.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On May 31, 2016, at 12:12 PM, Chris Bieneman via lldb-dev 
>  wrote:
> 
> One more thing I want to note on this thread.
> 
> For anyone looking at the patches. I’ve intentionally tried to make them 
> minimal. After the patches have landed and stayed on trunk without issue for 
> a while I’ll start doing cleanup around all the CMake version checks.
> 
> I’d like to not open the flood gates on those kinds of cascading changes in 
> case these patches need to be reverted for some reason.
> 
> Thanks,
> -Chris
> 
>> On May 31, 2016, at 11:22 AM, Chris Bieneman via lldb-dev 
>>  wrote:
>> 
>> Just an FYI. Later today I’ll be updating the CMake minimum version to 
>> 3.4.3. In advance of the transition I’ve posted a bunch of patches:
>> 
>> LLVM: http://reviews.llvm.org/D20822
>> Clang: http://reviews.llvm.org/D20823
>> Compiler-RT: http://reviews.llvm.org/D20824
>> LLDB: http://reviews.llvm.org/D20826
>> libcxx: http://reviews.llvm.org/D20828
>> libcxxabi: http://reviews.llvm.org/D20829
>> 
>> I will commit the patches early this afternoon. 
>> 
>> I received a lot of responses from bot owners on my last thread 
>> (http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html), so I think 
>> we’ll be in good shape, but I will be watching closely.
>> 
>> If you maintain a bot that *hasn’t* yet been updated please contact me right 
>> away so that we can coordinate.
>> 
>> Thanks,
>> -Chris
>> ___
>> 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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On May 31, 2016, at 1:16 PM, Chris Lattner via llvm-dev 
>  wrote:
> 
>> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev 
>>  wrote:
>> There has been some discussion on IRC about SVN hosting and the perils
>> of doing it ourselves. The consensus on the current discussion was
>> that moving to a Git-only solution would have some disvantages, but
>> many advantages. Furthermore, not hosting our own repos would save us
>> a lot of headaches, admin costs and timed out connections.
> 
> Personally, I’m hugely in favor of moving llvm’s source hosting to github at 
> some point, despite the fact that I continue to dislike git as a tool and 
> consider monotonicly increasing version numbers to be hugely beneficial.

Getting a monotonically increasing revision number seems doable in git with 
some server-side scripting using git notes or named tags (yet to be seen is how 
to achieve it *reliably* with github hosting).
However the challenge is more about sharing this number across repositories 
(i.e. having clang and llvm in sync). I can imagine some tooling for that, but 
with a github hosting it may still be fragile.

Ideally, I'd prefer the cross-repository to be handled with an extra layer, in 
a way similar as described in: 
https://gerrit-review.googlesource.com/Documentation/user-submodules.htm 
(somehow conceptually similar to Android manifests XML files). 
It would be easy to have tooling/scripts for llvm that would easily say 
"checkout llvm+clang+compiler-rt+libcxx+clang-extra here", or "update all llvm 
subproject under this root", or "checkout this specific revision for all these" 
(with a monotonic number for the revision).

(+1 to all the rest of what you wrote)

-- 
Mehdi


> The killer feature to me is the community aspects of github, allowing people 
> to get involved in the project more easily and make “drive by” contributions 
> through the pull request model.  Github also has a very scriptable interface, 
> allowing integration of external bug trackers etc into the workflow (which is 
> good, because its bugtracker is anemic).
> 
>> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
>> etc. Not only this incurs in additional admin cost, but it also gets
>> outdated, locally modified, and it needs to be backed up, etc. GitHub
>> gives all that for us for free.
> 
> Yes, it would be great to get out of this business.
> 
>> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
>> we can also use GitHub's system to manage releases (it's actually
>> quite good for that).
> 
> If we made this change, I think we should only change one thing at a time: 
> change source hosting, but not phabricator or the bug tracker.  We could then 
> discuss moving off phabricator to the github PR model, etc.
> 
>> 6. GitHub has automated testing of merge requests, meaning we can have
>> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
>> own validation hooks.
> 
> This works pretty well.  The major problem is with tests that are flakey.
> 
> -Chris
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[Renato Golin via lldb-dev]

On 31 May 2016 at 21:24, Aaron Ballman  wrote:
> Are we sure that github's svn integration works with common tools on
> Windows, like TortoiseSVN?

That's a good question. Can you try them out and report back?

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] GitHub anyone?

[Kate Stone via lldb-dev]

Likewise, I'd definitely be in favor of doing so.  It would be great to have 
the entire LLDB development community on GitHub instead of the current story.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On May 31, 2016, at 1:16 PM, Chris Lattner via lldb-dev 
>  wrote:
> 
>> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev 
>>  wrote:
>> There has been some discussion on IRC about SVN hosting and the perils
>> of doing it ourselves. The consensus on the current discussion was
>> that moving to a Git-only solution would have some disvantages, but
>> many advantages. Furthermore, not hosting our own repos would save us
>> a lot of headaches, admin costs and timed out connections.
> 
> Personally, I’m hugely in favor of moving llvm’s source hosting to github at 
> some point, despite the fact that I continue to dislike git as a tool and 
> consider monotonicly increasing version numbers to be hugely beneficial.
> 
> The killer feature to me is the community aspects of github, allowing people 
> to get involved in the project more easily and make “drive by” contributions 
> through the pull request model.  Github also has a very scriptable interface, 
> allowing integration of external bug trackers etc into the workflow (which is 
> good, because its bugtracker is anemic).
> 
>> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
>> etc. Not only this incurs in additional admin cost, but it also gets
>> outdated, locally modified, and it needs to be backed up, etc. GitHub
>> gives all that for us for free.
> 
> Yes, it would be great to get out of this business.
> 
>> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
>> we can also use GitHub's system to manage releases (it's actually
>> quite good for that).
> 
> If we made this change, I think we should only change one thing at a time: 
> change source hosting, but not phabricator or the bug tracker.  We could then 
> discuss moving off phabricator to the github PR model, etc.
> 
>> 6. GitHub has automated testing of merge requests, meaning we can have
>> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
>> own validation hooks.
> 
> This works pretty well.  The major problem is with tests that are flakey.
> 
> -Chris
> ___
> 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] [cfe-dev] GitHub anyone?

[Aaron Ballman via lldb-dev]

On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev
 wrote:
> Folks,
>
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solution would have some disvantages, but
> many advantages. Furthermore, not hosting our own repos would save us
> a lot of headaches, admin costs and timed out connections.

Not everyone thinks git is a step forward. Please do not force people
to use a "git-only" solution.

> TL;DR: GitHub + git submodules [1] could replace all the functionality
> we have currently with SVN.
>
> (also GitLab, BitBucketc, etc).
>
> Here are some of the arguments made on IRC...
>
> 1. Due to SVN, we can't re-write history. If we use some GitHub
> properties [2], we could have the same effect.
>
> 2. Due to SVN, we have a mandatory time sequence, so commits go first
> in LLVM, then Clang (for example), and buildbots don't get lost. If we
> use submodules [1], we can have a similar relationship, but in a more
> explicit way, and the problem could be solved elegantly.

I actually consider the monotonically increasing revisions to be a
feature, but not sufficient to warrant a decision one way or the
other.

> 3. Some people still can only use SVN. For that, GitHub has an SVN
> interface [3] to the repositories.

Are we sure that github's svn integration works with common tools on
Windows, like TortoiseSVN?

> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
> etc. Not only this incurs in additional admin cost, but it also gets
> outdated, locally modified, and it needs to be backed up, etc. GitHub
> gives all that for us for free.
>
> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
> we can also use GitHub's system to manage releases (it's actually
> quite good for that).
>
> 6. GitHub has automated testing of merge requests, meaning we can have
> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
> own validation hooks. Even though that wouldn't cover everything,
> having a few pre-commit bots would considerably reduce the need to
> revert patches [citation needed].
>
> 7. With git submodules, we'd probably want to follow the same style we
> have today (llvm-projects/) instead of modelling how they look in
> tree (llvm/tools/clang still as a symlink).
>
> 8. Once we're solo Git, we can shop around *much* more easily. By
> using SVN, we're basically forced to host, or choose Source Forge.
> Using just Git, we can choose GitLab, BitBucket and many others, if
> GitHub is not appealing enough. Essentially, it doesn't matter where
> you are, the tools are good, there and largely replaceable [citation
> needed].
>
> What do people think? Any issue not covered that we should? How would
> that disrupt downstream users? Would it be a temporary disruption, but
> with long lasting benefits? Or will it just break everything for you?

I'm not opposed to moving to GitHub, provided its svn interface proves
to meet our needs. I am opposed to switching to a git-only solution,
but I'm unclear whether that's currently on the table or not.

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

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[Reid Kleckner via lldb-dev]

I'm in favor of both going to git as the source of truth, and then
switching the hosting to github.

Echoing everyone else, this unlocks a lot of good stuff that I won't
repeat, and most of it can be handled independently from the VCS move.

The major blocker I see for the move is figuring out how we want to
coordinate versions between the related LLVM projects. I hear *terrible*
things about submodules, so I'd prefer a different sync mechanism, even if
it is a bad reimplementation of repo, gclient, submodules, and all the
other multi-repo sync tools.

On Tue, May 31, 2016 at 12:31 PM, Renato Golin via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> Folks,
>
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solution would have some disvantages, but
> many advantages. Furthermore, not hosting our own repos would save us
> a lot of headaches, admin costs and timed out connections.
>
> TL;DR: GitHub + git submodules [1] could replace all the functionality
> we have currently with SVN.
>
> (also GitLab, BitBucketc, etc).
>
> Here are some of the arguments made on IRC...
>
> 1. Due to SVN, we can't re-write history. If we use some GitHub
> properties [2], we could have the same effect.
>
> 2. Due to SVN, we have a mandatory time sequence, so commits go first
> in LLVM, then Clang (for example), and buildbots don't get lost. If we
> use submodules [1], we can have a similar relationship, but in a more
> explicit way, and the problem could be solved elegantly.
>
> 3. Some people still can only use SVN. For that, GitHub has an SVN
> interface [3] to the repositories.
>
> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
> etc. Not only this incurs in additional admin cost, but it also gets
> outdated, locally modified, and it needs to be backed up, etc. GitHub
> gives all that for us for free.
>
> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
> we can also use GitHub's system to manage releases (it's actually
> quite good for that).
>
> 6. GitHub has automated testing of merge requests, meaning we can have
> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
> own validation hooks. Even though that wouldn't cover everything,
> having a few pre-commit bots would considerably reduce the need to
> revert patches [citation needed].
>
> 7. With git submodules, we'd probably want to follow the same style we
> have today (llvm-projects/) instead of modelling how they look in
> tree (llvm/tools/clang still as a symlink).
>
> 8. Once we're solo Git, we can shop around *much* more easily. By
> using SVN, we're basically forced to host, or choose Source Forge.
> Using just Git, we can choose GitLab, BitBucket and many others, if
> GitHub is not appealing enough. Essentially, it doesn't matter where
> you are, the tools are good, there and largely replaceable [citation
> needed].
>
> What do people think? Any issue not covered that we should? How would
> that disrupt downstream users? Would it be a temporary disruption, but
> with long lasting benefits? Or will it just break everything for you?
>
> cheers,
> --renato
>
>
> [1] https://git-scm.com/book/en/v2/Git-Tools-Submodules
> [2]
> https://help.github.com/articles/defining-the-mergeability-of-pull-requests/
> [3] https://help.github.com/articles/support-for-subversion-clients/
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Chris Lattner via lldb-dev]

> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev 
>  wrote:
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solution would have some disvantages, but
> many advantages. Furthermore, not hosting our own repos would save us
> a lot of headaches, admin costs and timed out connections.

Personally, I’m hugely in favor of moving llvm’s source hosting to github at 
some point, despite the fact that I continue to dislike git as a tool and 
consider monotonicly increasing version numbers to be hugely beneficial.

The killer feature to me is the community aspects of github, allowing people to 
get involved in the project more easily and make “drive by” contributions 
through the pull request model.  Github also has a very scriptable interface, 
allowing integration of external bug trackers etc into the workflow (which is 
good, because its bugtracker is anemic).

> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
> etc. Not only this incurs in additional admin cost, but it also gets
> outdated, locally modified, and it needs to be backed up, etc. GitHub
> gives all that for us for free.

Yes, it would be great to get out of this business.

> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
> we can also use GitHub's system to manage releases (it's actually
> quite good for that).

If we made this change, I think we should only change one thing at a time: 
change source hosting, but not phabricator or the bug tracker.  We could then 
discuss moving off phabricator to the github PR model, etc.

> 6. GitHub has automated testing of merge requests, meaning we can have
> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
> own validation hooks.

This works pretty well.  The major problem is with tests that are flakey.

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[David Majnemer via lldb-dev]

On Tue, May 31, 2016 at 12:51 PM, Tim Northover via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 31 May 2016 at 12:31, Renato Golin via cfe-dev
>  wrote:
> > What do people think? Any issue not covered that we should?
>
> I'm in favour of the move. Git-svn just about works most of the time,
> but I find it makes committing to release branches particularly
> painful. It also randomly corrupts its database occasionally, just for
> the giggles I assume.
>

This hit me over the weekend, it was quite annoying. +1 from me.


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

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[Tim Northover via lldb-dev]

On 31 May 2016 at 12:31, Renato Golin via cfe-dev
 wrote:
> What do people think? Any issue not covered that we should?

I'm in favour of the move. Git-svn just about works most of the time,
but I find it makes committing to release branches particularly
painful. It also randomly corrupts its database occasionally, just for
the giggles I assume.

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

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[C Bergström via lldb-dev]

peanut gallery comments from a git hater (We use git for all source
revision control)

On Wed, Jun 1, 2016 at 3:31 AM, Renato Golin via cfe-dev
 wrote:
> Folks,
>
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solution would have some disvantages, but
> many advantages. Furthermore, not hosting our own repos would save us
> a lot of headaches, admin costs and timed out connections.
>
> TL;DR: GitHub + git submodules [1] could replace all the functionality

> we have currently with SVN.
>
> (also GitLab, BitBucketc, etc).
>
> Here are some of the arguments made on IRC...
>
> 1. Due to SVN, we can't re-write history. If we use some GitHub
> properties [2], we could have the same effect.

Are you referring to linear commit history being maintained going
forward or what specifically?

>
> 2. Due to SVN, we have a mandatory time sequence, so commits go first
> in LLVM, then Clang (for example), and buildbots don't get lost. If we
> use submodules [1], we can have a similar relationship, but in a more
> explicit way, and the problem could be solved elegantly.

Sub modules don't work exactly like svn. afaik they are glued to a
specific commit?
So you get questions like this
http://stackoverflow.com/questions/1030169/easy-way-pull-latest-of-all-submodules

So if this path is chosen, please make sure the minimum git version
supported is clarified.

>
> 3. Some people still can only use SVN. For that, GitHub has an SVN
> interface [3] to the repositories.
>
> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
> etc. Not only this incurs in additional admin cost, but it also gets
> outdated, locally modified, and it needs to be backed up, etc. GitHub
> gives all that for us for free.
>
> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
> we can also use GitHub's system to manage releases (it's actually
> quite good for that).

Bugzilla sucks, but github's issue tracker sucks worse (imnsho). I'm
not a stakeholder and have no vote, but if it ain't broke don't fix
it.. or try jira.. (they give free licenses to open source and it
rocks)

>
> 6. GitHub has automated testing of merge requests, meaning we can have
> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
> own validation hooks. Even though that wouldn't cover everything,
> having a few pre-commit bots would considerably reduce the need to
> revert patches [citation needed].
>
> 7. With git submodules, we'd probably want to follow the same style we
> have today (llvm-projects/) instead of modelling how they look in
> tree (llvm/tools/clang still as a symlink).
>
> 8. Once we're solo Git, we can shop around *much* more easily. By
> using SVN, we're basically forced to host, or choose Source Forge.
> Using just Git, we can choose GitLab, BitBucket and many others, if
> GitHub is not appealing enough. Essentially, it doesn't matter where
> you are, the tools are good, there and largely replaceable [citation
> needed].
>
> What do people think? Any issue not covered that we should? How would
> that disrupt downstream users? Would it be a temporary disruption, but
> with long lasting benefits? Or will it just break everything for you?

There's already git mirrors of all this stuff on github - *if* you're
going to go down this path, I think the 1st step is updating docs to
ask people to use those as a preferred solution. Based on that
feedback you can wean people off svn instead of hard cut.

This really falls into 2 categories - read-only and write..

For read-only the migration should be straight forward, but write gets
a bit more tricky as you'd need to likely rely on git-svn (which I
suspect some people are already using)

Even though git 1.7 or something deals with submodules better - I
don't personally like them at all. I'd rather have a convenience
script or something which pulls and clones the sources. Not everyone
needs all the sources and then there's the question of all the
subprojects and build.. etc Not changing the workflow here would be
most sane..

So clone llvm ; cd tools / ; clone ...
--
good luck with this.. I foresee near religious opinions on the horizon..
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] GitHub anyone?

[Renato Golin via lldb-dev]

Folks,

There has been some discussion on IRC about SVN hosting and the perils
of doing it ourselves. The consensus on the current discussion was
that moving to a Git-only solution would have some disvantages, but
many advantages. Furthermore, not hosting our own repos would save us
a lot of headaches, admin costs and timed out connections.

TL;DR: GitHub + git submodules [1] could replace all the functionality
we have currently with SVN.

(also GitLab, BitBucketc, etc).

Here are some of the arguments made on IRC...

1. Due to SVN, we can't re-write history. If we use some GitHub
properties [2], we could have the same effect.

2. Due to SVN, we have a mandatory time sequence, so commits go first
in LLVM, then Clang (for example), and buildbots don't get lost. If we
use submodules [1], we can have a similar relationship, but in a more
explicit way, and the problem could be solved elegantly.

3. Some people still can only use SVN. For that, GitHub has an SVN
interface [3] to the repositories.

4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
etc. Not only this incurs in additional admin cost, but it also gets
outdated, locally modified, and it needs to be backed up, etc. GitHub
gives all that for us for free.

5. We can still use Bugzilla (and lock GitHub's own bug system), but
we can also use GitHub's system to manage releases (it's actually
quite good for that).

6. GitHub has automated testing of merge requests, meaning we can have
pre-commit tests enabled on a set of fast bots, triggered by GitHub's
own validation hooks. Even though that wouldn't cover everything,
having a few pre-commit bots would considerably reduce the need to
revert patches [citation needed].

7. With git submodules, we'd probably want to follow the same style we
have today (llvm-projects/) instead of modelling how they look in
tree (llvm/tools/clang still as a symlink).

8. Once we're solo Git, we can shop around *much* more easily. By
using SVN, we're basically forced to host, or choose Source Forge.
Using just Git, we can choose GitLab, BitBucket and many others, if
GitHub is not appealing enough. Essentially, it doesn't matter where
you are, the tools are good, there and largely replaceable [citation
needed].

What do people think? Any issue not covered that we should? How would
that disrupt downstream users? Would it be a temporary disruption, but
with long lasting benefits? Or will it just break everything for you?

cheers,
--renato


[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules
[2] https://help.github.com/articles/defining-the-mergeability-of-pull-requests/
[3] https://help.github.com/articles/support-for-subversion-clients/
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] TODAY! Updating to CMake 3.4.3

[Chris Bieneman via lldb-dev]

One more thing I want to note on this thread.

For anyone looking at the patches. I’ve intentionally tried to make them 
minimal. After the patches have landed and stayed on trunk without issue for a 
while I’ll start doing cleanup around all the CMake version checks.

I’d like to not open the flood gates on those kinds of cascading changes in 
case these patches need to be reverted for some reason.

Thanks,
-Chris

> On May 31, 2016, at 11:22 AM, Chris Bieneman via lldb-dev 
>  wrote:
> 
> Just an FYI. Later today I’ll be updating the CMake minimum version to 3.4.3. 
> In advance of the transition I’ve posted a bunch of patches:
> 
> LLVM: http://reviews.llvm.org/D20822
> Clang: http://reviews.llvm.org/D20823
> Compiler-RT: http://reviews.llvm.org/D20824
> LLDB: http://reviews.llvm.org/D20826
> libcxx: http://reviews.llvm.org/D20828
> libcxxabi: http://reviews.llvm.org/D20829
> 
> I will commit the patches early this afternoon. 
> 
> I received a lot of responses from bot owners on my last thread 
> (http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html), so I think 
> we’ll be in good shape, but I will be watching closely.
> 
> If you maintain a bot that *hasn’t* yet been updated please contact me right 
> away so that we can coordinate.
> 
> Thanks,
> -Chris
> ___
> 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] Inquiry regarding AddOneMoreFrame function in UnWindLLDB

[via lldb-dev]

> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev 
>  wrote:
> 
> Hello,
>   I posted this query a while ago, i still have no answers, I am 
> currently working on Bug 27687 (PrintStackTraces), so the reason for the 
> failure is the erroneous unwinding of the frames from the zeroth frame. The 
> error is not detected in AddOneMoreFrame, since it only checks for 2 more 
> frames, if it was checking more frames in AddOneMoreFrame, it would have 
> detected the error. Now my questions are ->
> 
> ->  is that is there any specific reason for only checking 2 frames instead 
> of more ?

The stepping machinery uses the unwinder on each stop to figure out whether it 
has stepped in or out, which is fairly performance sensitive, so we don't want 
AddOneMoreFrame to do more work than it has to.  

Jim

> ->  Why no make the EH CFI based unwinder the default one and make the 
> assembly the fallback ?
> 
> Best Regards,
> A Ravi Theja
> 
> ___
> 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] TODAY! Updating to CMake 3.4.3

[Chris Bieneman via lldb-dev]

Just an FYI. Later today I’ll be updating the CMake minimum version to 3.4.3. 
In advance of the transition I’ve posted a bunch of patches:

LLVM: http://reviews.llvm.org/D20822
Clang: http://reviews.llvm.org/D20823
Compiler-RT: http://reviews.llvm.org/D20824
LLDB: http://reviews.llvm.org/D20826
libcxx: http://reviews.llvm.org/D20828
libcxxabi: http://reviews.llvm.org/D20829

I will commit the patches early this afternoon. 

I received a lot of responses from bot owners on my last thread 
(http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html), so I think 
we’ll be in good shape, but I will be watching closely.

If you maintain a bot that *hasn’t* yet been updated please contact me right 
away so that we can coordinate.

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

[lldb-dev] crashlog.py bug fixes and enhancements

[Alastair Houghton via lldb-dev]

(I’ve already filed a couple of Radars about this; rdar://24025436 and 
rdar://26090553, for those with Radar access.)

The crashlog.py script that ships with LLDB/Xcode is broken.  It has a few 
outright bugs, for which I have fixes, and it also relies on an external script 
that has undocumented behaviour and that the script looks for in the home 
directory of the user “rc” (not a safe thing to do on e.g. university networks, 
as it would allow that user to hijack the shell of any user trying to 
symbolicate using crashlog.py).

It’s also useful for it to be able to cope with the output from the Mac OS X 
“sample” tool, so I’ve added support for that too.

You can find the updated version here:

  https://bitbucket.org/al45tair/crashlog

It would be nice if, at some point, this got merged back into the official 
release...

Kind regards,

Alastair.

--
http://alastairs-place.net

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

[lldb-dev] Fwd: Inquiry regarding AddOneMoreFrame function in UnWindLLDB

[Ravitheja Addepally via lldb-dev]

Hello,
  I posted this query a while ago, i still have no answers, I am
currently working on Bug 27687 (PrintStackTraces), so the reason for the
failure is the erroneous unwinding of the frames from the zeroth frame. The
error is not detected in AddOneMoreFrame, since it only checks for 2 more
frames, if it was checking more frames in AddOneMoreFrame, it would have
detected the error. Now my questions are ->

->  is that is there any specific reason for only checking 2 frames instead
of more ?
->  Why no make the EH CFI based unwinder the default one and make the
assembly the fallback ?

Best Regards,
A Ravi Theja
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev