similar to: [LLVMdev] Official git mirroring of llvm, clang, lldb, test-suite, etc.?

Le 29 janv. 2011 à 09:33, Mark Lacey a écrit : > I know this comes up periodically, but it looks like it has been a few months since there was any posting indicating that having an official git mirror for LLVM, et al. was still in the works. > > I am wondering if there is a timeline or resources lined up to do this mirroring. > > The distributed nature of git fits very well with

Jean-Daniel Dupas <devlists at shadowlab.org> writes: > Le 29 janv. 2011 à 09:33, Mark Lacey a écrit : > >> I know this comes up periodically, but it looks like it has been a few months since there was any posting indicating that having an official git mirror for LLVM, et al. was still in the works. >> >> I am wondering if there is a timeline or resources lined up

greened at obbligato.org (David A. Greene) writes: > Jean-Daniel Dupas <devlists at shadowlab.org> writes: > >> Le 29 janv. 2011 à 09:33, Mark Lacey a écrit : >> >>> I know this comes up periodically, but it looks like it has been a >>> few months since there was any posting indicating that having an >>> official git mirror for LLVM, et al. was

greened at obbligato.org (David A. Greene) writes: >>> git-svn often doesn't work, especially if the other side also needs >>> git-svn. >> >> The git mirror would be read-only, so if you want to contribute changes >> to LLVM using git you need git-svn anyways. > > I pull down changes from upstream much more frequently than I send > changes up. To

lol On Feb 1, 2011, at 0:00, Chris Lattner wrote: > > On Jan 31, 2011, at 7:27 PM, Óscar Fuentes wrote: > >>> >>> If one is not supposed to use svn (the official blessed >>> LLVM SCM) on "our side," pray tell, what _are_ we supposed to use? >> >> Because LLVM chose to use svn at some point on the past (when >> distributed tools

On 2011-02-01 19:40, David A. Greene wrote: > Again, the problem is that there is no convenient solution. Everything > involves manual diff+patch at some point. This is entirely because svn > is not a distributed SCM. FWIW I used "svk" for a little while, to be able to make local commits on a SVN repository. It was certainly better than manually patching stuff. I think I used

Óscar Fuentes <ofv at wanadoo.es> writes: >> git-svn often doesn't work, especially if the other side also needs >> git-svn. > > The git mirror would be read-only, so if you want to contribute changes > to LLVM using git you need git-svn anyways. I pull down changes from upstream much more frequently than I send changes up. To send changes up, diff+patch+svn,

On Jan 31, 2011, at 7:27 PM, Óscar Fuentes wrote: >> >> If one is not supposed to use svn (the official blessed >> LLVM SCM) on "our side," pray tell, what _are_ we supposed to use? > > Because LLVM chose to use svn at some point on the past (when > distributed tools were not so mature and undestood as they are now) and > because there is no enough

greened at obbligato.org (David A. Greene) writes: > I can't use git-svn to pull because we use svn on our end. One can't do > this: > > (Upstream) svn <--> git-svn <--> git <--> git-svn <--> svn (Downstream) > > because the revisions in the two svn repositories don't have anything to > do with each other. That's what you deserve, for

Óscar Fuentes <ofv at wanadoo.es> writes: >> I asked about both to the git guys. They said it isn't supported. >> Double-ended git-svn just won't work, period. You can't do it because a >> git branch is still tied to the revision numbering of the first git-svn >> gateway created. Git branches still must relate to each other, they >> can't run

Óscar Fuentes <ofv at wanadoo.es> writes: > Are you saying that git-svn is slow at pulling changes? It is quite okay > in my experience, unless you pull once every other month. But I can't > relate that to your original assertion quoted above. I can't use git-svn to pull because we use svn on our end. One can't do this: (Upstream) svn <--> git-svn <-->

greened at obbligato.org (David A. Greene) writes: >> (Upstream) svn <--> git-svn <--> git-svn <--> svn (Downstream) > > I asked about both to the git guys. They said it isn't supported. > Double-ended git-svn just won't work, period. You can't do it because a > git branch is still tied to the revision numbering of the first git-svn > gateway

Óscar Fuentes <ofv at wanadoo.es> writes: > greened at obbligato.org (David A. Greene) writes: > >> I can't use git-svn to pull because we use svn on our end. One can't do >> this: >> >> (Upstream) svn <--> git-svn <--> git <--> git-svn <--> svn (Downstream) >> >> because the revisions in the two svn repositories

Hi, Lately, I have been wondering how a compiler like GCC or Clang implements builtin functions like sqrt, sin, and also more bit-specific things like bcmp and ffs. Originially, these were all deferred to the C library where they might still have a "backup implementation", but I don't understand why a compiler would choose the non-builtin version, as it should know its version is

Le 20 janv. 2012 à 14:38, Ruben Van Boxem a écrit : > Hi, > > Lately, I have been wondering how a compiler like GCC or Clang implements builtin functions like sqrt, sin, and also more bit-specific things like bcmp and ffs. Originially, these were all deferred to the C library where they might still have a "backup implementation", but I don't understand why a compiler would

> > > Besides, the git-svn readonly bridge is a great solution for those who want > to use git > It seems to be a reasonable solution for those individuals who want to use git, but in my experience not for organizations that want to use git, e.g. have a local server with local branches, with many people banging on that while at the same time continuously merging the LLVM mainline

On 22 Jan 2013, at 12:04, Duncan Sands wrote: > for an out-of-tree build you can use llvm-config to get include paths and so on. > I don't think there is any point bothering with llvm-build for this case. CMake works nicely for out-of-tree projects. I have an optimiser plugin that builds this way. I'm not sure if it's fixed now, but the autoconf builds used to not install the

On Wed, Jul 27, 2011 at 8:59 PM, Mark Lacey <641 at rudkx.com> wrote: > >> Besides, the git-svn readonly bridge is a great solution for those who >> want to use git >> > > It seems to be a reasonable solution for those individuals who want to use > git, but in my experience not for organizations that want to use git, e.g. > have a local server with local

I also encounter this issue and solved it locally by implementing this 2 functions. - The linux version of StartSymbolizerSubprocess uses only POSIX function and can be reused as is on OS X (maybe we should move it in a new sanitizer_symbolizer_posix.cc file) - I have a simple implementation of GetListOfModules (see the attached file) but it required 10.6 at least. That said, implementing this

On Mon, Aug 16, 2010 at 7:42 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Aug 16, 2010, at 7:24 PM, Mark Lacey wrote: > > > I have read through the TableGen Fundamentals documentation and been > browsing various .td files. One thing that is not clear to me is where > things like $src1 (as in GR32:$src1) are defined, and what they mean. The > TableGen