search for: pr21562

Displaying 14 results from an estimated 14 matches for "pr21562".

2015 Jul 29
7
[LLVMdev] [RFC] Road map for CMake
Hi LLVMDev, I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months. Apologies in advance for the substantial 0/7 Wall of Text I've summoned here (it only cost me 3 swamp mana). The main thing I want to talk about is PR21562. For Apple PR21562 is the biggest reason we can't fully abandon autoconf. I've spent some time over the last month hacking on compiler-rt's build system and I've come up with a basic outline of the approach I'd like to take. (1) Reconcile out-of-tree functionality Apple has a...
2015 Jul 30
0
[LLVMdev] [RFC] Road map for CMake
...> Hi LLVMDev, > > I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months. Apologies in advance for the substantial 0/7 Wall of Text I've summoned here (it only cost me 3 swamp mana). > > The main thing I want to talk about is PR21562. For Apple PR21562 is the biggest reason we can't fully abandon autoconf. I've spent some time over the last month hacking on compiler-rt's build system and I've come up with a basic outline of the approach I'd like to take. > > (1) Reconcile out-of-tree functionality &gt...
2015 Jul 30
2
[LLVMdev] [RFC] Road map for CMake
..., >> >> I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months. Apologies in advance for the substantial 0/7 Wall of Text I've summoned here (it only cost me 3 swamp mana). >> >> The main thing I want to talk about is PR21562. For Apple PR21562 is the biggest reason we can't fully abandon autoconf. I've spent some time over the last month hacking on compiler-rt's build system and I've come up with a basic outline of the approach I'd like to take. >> >> (1) Reconcile out-of-tree functiona...
2015 Jul 30
0
[LLVMdev] [RFC] Road map for CMake
...Dev, > > I wanted to take some time to write up and roll out a proposed road map > for CMake over the next few months. Apologies in advance for the > substantial 0/7 Wall of Text I've summoned here (it only cost me 3 swamp > mana). > > The main thing I want to talk about is PR21562. For Apple PR21562 is the > biggest reason we can't fully abandon autoconf. I've spent some time over > the last month hacking on compiler-rt's build system and I've come up with > a basic outline of the approach I'd like to take. > > (1) Reconcile out-of-tree fun...
2015 Jul 30
0
[LLVMdev] [RFC] Road map for CMake
...ninja for all compilation jobs? You're doing the work, so it's fine if that's a nongoal. However, I'd like it if the simple case where compiler-rt is being compiled for the host, the generated build files don't shell out to another build. The main thing I want to talk about is PR21562. For Apple PR21562 is the > biggest reason we can't fully abandon autoconf. I've spent some time over > the last month hacking on compiler-rt's build system and I've come up with > a basic outline of the approach I'd like to take. > > (1) Reconcile out-of-tree fun...
2015 Jul 30
2
[LLVMdev] [RFC] Road map for CMake
...each other or the master project’s rules (2) Importing the sub-projects into the parent ninja (3) Mark the CMake invocations for the external projects as “generator” rules so that Ninja would re-exec itself if CMake changed the build files -Chris > > The main thing I want to talk about is PR21562. For Apple PR21562 is the biggest reason we can't fully abandon autoconf. I've spent some time over the last month hacking on compiler-rt's build system and I've come up with a basic outline of the approach I'd like to take. > > (1) Reconcile out-of-tree functionality &gt...
2015 Jul 30
0
[LLVMdev] [RFC] Road map for CMake
...; >> I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months. Apologies in advance for the substantial 0/7 Wall of Text I've summoned here (it only cost me 3 swamp mana). > >> > >> The main thing I want to talk about is PR21562. For Apple PR21562 is the biggest reason we can't fully abandon autoconf. I've spent some time over the last month hacking on compiler-rt's build system and I've come up with a basic outline of the approach I'd like to take. > >> > >> (1) Reconcile out-of-tree...
2015 Jul 30
0
[LLVMdev] [RFC] Road map for CMake
...roject’s rules > (2) Importing the sub-projects into the parent ninja > (3) Mark the CMake invocations for the external projects as “generator” > rules so that Ninja would re-exec itself if CMake changed the build files > > -Chris > > > The main thing I want to talk about is PR21562. For Apple PR21562 is the >> biggest reason we can't fully abandon autoconf. I've spent some time over >> the last month hacking on compiler-rt's build system and I've come up with >> a basic outline of the approach I'd like to take. >> >> (1) Recon...
2015 Jul 30
4
[LLVMdev] [RFC] Road map for CMake
...> I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months. Apologies in advance for the substantial 0/7 Wall of Text I've summoned here (it only cost me 3 swamp mana). >>>> >>>> The main thing I want to talk about is PR21562. For Apple PR21562 is the biggest reason we can't fully abandon autoconf. I've spent some time over the last month hacking on compiler-rt's build system and I've come up with a basic outline of the approach I'd like to take. >>>> >>>> (1) Reconcile out-o...
2015 Jul 31
0
[LLVMdev] [RFC] Road map for CMake
...0, Chris Bieneman wrote: Hi LLVMDev, I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months. Apologies in advance for the substantial 0/7 Wall of Text I've summoned here (it only cost me 3 swamp mana). The main thing I want to talk about is PR21562. For Apple PR21562 is the biggest reason we can't fully abandon autoconf. I've spent some time over the last month hacking on compiler-rt's build system and I've come up with a basic outline of the approach I'd like to take. (1) Reconcile out-of-tree functionality Apple has a...
2015 Jul 29
2
[LLVMdev] [RFC] July Update: Progress report on CMake build system's ability to replace autoconf
...tifying itself as amd64 causing x86_64 tests to fail * Migrating buildbots * We need to make sure libc++ works properly on Darwin * Put together a “cheat sheet” document for transitioning I have another RFC titled "[RFC] Road map for CMake” which I’ll be sending shorty to discuss PR 14109 and PR21562 in more detail. Thanks, -Chris
2015 Jul 29
0
[LLVMdev] [RFC] July Update: Progress report on CMake build system's ability to replace autoconf
...ng x86_64 tests to fail > * Migrating buildbots > * We need to make sure libc++ works properly on Darwin > * Put together a “cheat sheet” document for transitioning > > I have another RFC titled "[RFC] Road map for CMake” which I’ll be sending > shorty to discuss PR 14109 and PR21562 in more detail. > > Thanks, > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTM...
2015 Jul 30
1
[LLVMdev] [RFC] July Update: Progress report on CMake build system's ability to replace autoconf
...ausing x86_64 tests to fail > * Migrating buildbots > * We need to make sure libc++ works properly on Darwin > * Put together a “cheat sheet” document for transitioning > > I have another RFC titled "[RFC] Road map for CMake” which I’ll be sending shorty to discuss PR 14109 and PR21562 in more detail. > > Thanks, > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mail...
2015 Mar 11
7
[LLVMdev] [RFC] Raise minimum required CMake version to 3.0
On 11 March 2015 at 04:14, Chandler Carruth <chandlerc at google.com> wrote: > Just to rebase things a bit, here is some context. > > - This is a 60+ email thread spreading across a month of time. > - I've not read every single email and I don't think it makes sense to > assume the context of the first email applies to the most recent. I think we all agree that