search for: revlocked

.../libLTO on the system, clang generates bitcode, and libLTO handles it. > >>> > >>> If ld64 was statically linked against LLVM, it couldn’t read the new bitcode right? > >>> > >>> > >>> Well sure, that's what Peter meant when he said revlocked. :) > >> > >> I’m not sure we’re talking about the same thing, I may have misunderstood his point (“In theory the same does not apply to libLTO, but we do end up changing it > >> occasionally to add new APIs which ld64 promptly starts using, so it isn’t clear how much ld...

...not sure how is that supposed to work? > I drop a new clang/libLTO on the system, clang generates bitcode, and > libLTO handles it. > > If ld64 was statically linked against LLVM, it couldn’t read the new > bitcode right? > > Well sure, that's what Peter meant when he said revlocked. :) -eric > — > Mehdi > > > > > And you already don't have forward compatibility because of what Peter > said in the first place. :) > > > Anyhow, I don't actually expect this to change. Also the C API has to > change, but yes that's a different th...

...ed to work? > > I drop a new clang/libLTO on the system, clang generates bitcode, and libLTO handles it. > > > > If ld64 was statically linked against LLVM, it couldn’t read the new bitcode right? > > > > > > Well sure, that's what Peter meant when he said revlocked. :) > > I’m not sure we’re talking about the same thing, I may have misunderstood his point (“In theory the same does not apply to libLTO, but we do end up changing it > occasionally to add new APIs which ld64 promptly starts using, so it isn’t clear how much ld64 gains by relying on libL...

This patch eases building clang when present in the source tree. Since clang is revlocked to llvm, one usually updates them together, and builds them together. Ok? -------------- next part -------------- A non-text attachment was scrubbed... Name: clang-3.patch Type: application/octet-stream Size: 794 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attach...

On Thu, Sep 3, 2015 at 11:45 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi, > > > On Sep 2, 2015, at 7:31 PM, Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote: > >> On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith < > >>

On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote: > On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith < > dexonsmith at apple.com> wrote: > > > > > > On 2015-Aug-31, at 18:09, Eric Christopher <echristo at gmail.com> wrote: > > > > > > > > > > > > On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith

On 19 Jan 2009, at 19:08, Mike Stump wrote: > This patch eases building clang when present in the source tree. > Since clang is revlocked to llvm, one usually updates them together, > and builds them together. > > Ok? In my humble opinion, using OPTIONAL_DIRS would be better and cleaner. It may require some changes to ‘Makefile.rules’ to work as intended, though. If there's interest in such a change, I can prepare...

> On Aug 9, 2016, at 1:38 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Aug 9, 2016, at 11:27 AM, Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >>> (2) If I’m stuck using git-svn I kinda feel like there is no real point in changing anything. >> >>

> (2) If I’m stuck using git-svn I kinda feel like there is no real point in changing anything. No real point *for you specifically*. But the vast majority of people would not be stuck using git-svn. And in addition the LLVM project would not be stuck using svn, with all the baggage, hosting issues, workflow issues (for people other than you), etc. The bar by which this proposal should be

> On 2015-Aug-31, at 18:09, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > > On 2015-Aug-31, at 12:21, Eric Christopher <echristo at gmail.com> wrote: > > Yep. This is where I was going :) > > Glad I found consensus, but I want to

Hi Duncan, > […] > 2. Those working on projects *outside* the monolithic repo will get the downsides of both: a monolithic repo that they are only using parts of, and multiple repos that are somehow version-locked. > > 3. For many (most?) developers, changing to a monolithic git repo is a *bigger* workflow change than switching to separate git repos. Many people (and at least some