search for: revlock

...at > >>>>>> all. > >>>>>> > >>>>>> He can speak more to this though. > >>>>> > >>>>> The C++ interface is much more convenient for a C++ program to use, but > >>>>> clients need to revlock themselves to LLVM in order to use it. > >>>>> > >>>>> 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 > >>>>> cl...

...sing the C++ interface to handle everything and not using libLTO >> at >> >> all. >> >> >> >> He can speak more to this though. >> > >> > The C++ interface is much more convenient for a C++ program to use, but >> > clients need to revlock themselves to LLVM in order to use it. >> > >> > 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 rely...

...e to handle everything and not using libLTO at > >> >> all. > >> >> > >> >> He can speak more to this though. > >> > > >> > The C++ interface is much more convenient for a C++ program to use, but > >> > clients need to revlock themselves to LLVM in order to use it. > >> > > >> > 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 re...

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/atta...

...> >> > >> Ah, using the C++ interface to handle everything and not using libLTO at > >> all. > >> > >> He can speak more to this though. > > > > The C++ interface is much more convenient for a C++ program to use, but > > clients need to revlock themselves to LLVM in order to use it. > > > > 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 libLTO, > > Back...

...ld that pcc is working on? > > > > What specifically? > > > Ah, using the C++ interface to handle everything and not using libLTO at > all. > > He can speak more to this though. The C++ interface is much more convenient for a C++ program to use, but clients need to revlock themselves to LLVM in order to use it. 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 libLTO, or whether the burden on in-tree clients is worth it (ther...

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 prepa...

...checkout monorepo, GitHub monorepo with svn, and submodules cases. The submodules case will likely show that bisecting is more complex than on the monorepo, while pushing is simpler. > > Similarly, the submodules workflow probably isn’t capable of a single commit to llvm and clang in the revlock case while the monorepo is, but we as a community need to decide whether we want to optimize for that or not. I don’t have any data to suggest that revlock commits are frequent/infrequent or even a problem in general, and I don’t think we should optimize for that case unless its worth doing so. &g...

> (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