It has also submodules.
https://github.com/llvm-project/llvm-project-submodule
Both llvm-project(-tree) and (-submodule) have refs/notes/commits.
On Tue, Jun 28, 2016 at 1:13 AM Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On 27 June 2016 at 17:03, Rafael Espíndola
> wrote:
> >
Hi,
I followed instructions in http://lldb.llvm.org/build.html to build lldb on
Mac.
I opened "*lldb/lldb.xcworkspace*" in Xcode7.3.1, select lldb-tools scheme
and build, I always got build error below. I have tried "brew install
cmake" but the installed cmake version does not match what build sc
On Jun 27, 2016, at 9:57 PM, Chris Lattner via llvm-dev
wrote:
>
> I continue to think that 3.10 is the least defensible option out there.
I agree, given that there isn’t a concurrent agreement that we want to define
and conform to a semantic versioning scheme — and that agreement not only
On Jun 27, 2016, at 4:57 PM, Hans Wennborg wrote:
>> Eh, if we're switching to a completely unrelated versioning scheme, it
>> doesn't seem completely unreasonable.
>>
>> We could also count how many time-based releases we have had and use that...
>>
>> :: shrug ::
>>
>> I think counting from 4
On Mon, Jun 27, 2016 at 3:40 PM, Chandler Carruth wrote:
> On Mon, Jun 27, 2016 at 3:38 PM Hans Wennborg via lldb-dev
> wrote:
>>
>> On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner wrote:
>> > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev
>> > wrote:
>> >> That's what concerns me about
On Mon, Jun 27, 2016 at 3:38 PM Hans Wennborg via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner wrote:
> > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
> >> That's what concerns me about going to the sche
On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner wrote:
> On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev
> wrote:
>> That's what concerns me about going to the scheme Richard and Rafael
>> suggested, of bumping the major version each time: we'd release 4.0,
>> and would Tom's dot-release
On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev
wrote:
> That's what concerns me about going to the scheme Richard and Rafael
> suggested, of bumping the major version each time: we'd release 4.0,
> and would Tom's dot-release then be 4.1? That would be confusing to
> those who are used t
Stable release can use a different numbering space -- a,b,c,d. 4.1a
means the first patch release of 4.1 release, etc.
David
On Mon, Jun 27, 2016 at 8:26 AM, Hans Wennborg wrote:
> On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth via cfe-dev
> wrote:
> > On Sun, Jun 26, 2016 at 10:01 AM X
On 27 June 2016 at 17:03, Rafael Espíndola wrote:
> I think that trying to create a ordering/rev number between independent git
> repositories is fundamentally unreliable.
>
> If we want to keep llvm and clang in lock step we should probably probably
> just have them in the same repository like
>
Hello there,
Renato, thank you for putting everything together.
Talking about second question (commits mailing list): github provides set
of various web hooks. I think here we are interested
In 'push'es particularly.
Besides that it has some CI related integrations: buildbots can update pull
req
I think that trying to create a ordering/rev number between independent git
repositories is fundamentally unreliable.
If we want to keep llvm and clang in lock step we should probably probably
just have them in the same repository like
https://github.com/llvm-project/llvm-project.
Cheers,
Rafael
On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth via cfe-dev
wrote:
> On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev
> wrote:
>>
>> I also believe this is the simplest versioning scheme*. It eliminates all
>> future debates on this topic (e.g, when to bump major version etc) and
On Fri, Jun 24, 2016 at 5:55 PM, Saleem Abdulrasool
wrote:
> On Fri, Jun 24, 2016 at 5:43 PM, Dmitri Gribenko via cfe-dev
> wrote:
>>
>> On Fri, Jun 24, 2016 at 4:41 PM, Hans Wennborg via llvm-dev
>> wrote:
>> > Richard suggested that since we do time-based rather than
>> > feature-based release
On 27 June 2016 at 15:39, Rafael Espíndola wrote:
> So, I probably missed something, but what was the main objection to
> just using submodules? This would put llvm inside clang instead of the
> other way around. When changing an API one currently has to
I don't think the consensus was to change
Two problems:
1) Submodules have some UX problems for developers around updating the
parent project and its effects on the submodule which make them annoying to
use.
2) I find the advantage you claim especially scary and bad. Put another
way: if a developer *doesn't* make a commit to clang with the
>> As for updating the meta repository: We could disable write access for the
>> normal llvm developer and delegate the submodule bumping to an external
>> server. I believe this would be an easy enough job for buildbot or jenkins.
>
> The plan is to disable all write access to this repository (ot
On 27 June 2016 at 01:20, Matthias Braun wrote:
> I really liked the the solution proposed earlier in this thread: Do nothing
> server side, but instead use
> `git rev-list --count master` on the client side (which takes 0.9s on my
> machine) to get the number of the commit. So nothing to do on
18 matches
Mail list logo
