similar to: [LLVMdev] Howdy + GIT

> On Jan 16, 2015, at 3:26 AM, Erik de Castro Lopo <mle+cl at mega-nerd.com> wrote: > > As for all the reason why the LLVM project does not use Git, I wonder > why large complex projects like the Linux kernel, Wine, MinGW-w64, > GHC and many many others don't seem to have any major problems using > Git. Lots of projects are also happy with Mercurial, or BZR, or even

Dear LLVMers, If you live on the bleeding edge (i.e. CVS version), please read! On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Do you really want external patches for this ? A simple Perl script > that runs on all *.h and *.cpp files, and a local commit from your > side would be much simpler. I'm in the process of doing just this as we speak. What this

LLVMers, The LLVM Oversight group is trying to assess whether there is sufficient interest in the LLVM development community for holding an LLVM Conference next summer. If getting together with your fellow LLVM Developers sounds interesting to you, please respond to me (off list) and I'll summarize the results. Here's our current thinking: * Venue: West Coast, USA. Probably either San

Why not put all this into a pre-commit filter in CVS and be done with it? We'd never be bothered with it again as it would never be committed again. Reid. On Thu, 2005-04-21 at 15:11 -0500, Misha Brukman wrote: > Dear LLVMers, > > If you live on the bleeding edge (i.e. CVS version), please read! > > On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote:

Hello LLVMers, For the windows side of my team's product, I use the VStudio project files included in the LLVM tree (which are VStudio 2k3 files). I just switched over to the SVN sources yesterday and spent some time working with those project files to get things to build cleanly on my system. We use VStudio 2k5, so I have to go through a conversion process which may be the cause of some

John, Here's my list: 1. CVS is slow. Many of the other tools do bi-directional binary deltas on file changes they are transmitting. This is basically the technology that makes rsync so fast. CVS doesn't do this. Probably not a big deal when you're working at UIUC but its CRUCIAL when I'm on the road working from a hotel or airport wi-fi connection. 2. Related to 1 is diff

LLVMers, The oversight group has been kicking around the idea of getting a better version control system than CVS. The problem is, we're not quite sure what "better" means. So, we thought we'd ask your opinions. If you're interested in this topic (and you should be if you're actively developing), please have a look at this site:

Hola Reid, Cool deal. I think I have all the bugs worked out as I'm building cleanly now in one "build all" pass as opposed to two. I'm going to integrate and test the results with our system. Will the patch process be sufficient for this kind of change (~350K of VStudio XML goo)? Should I request commit access, if at least for the vstudio stuff? Thanks, Chuck.

Hi Chuck, On Wed, 2007-07-25 at 11:16 -0700, Chuck Rose III wrote: > Hello LLVMers, > > > > For the windows side of my team’s product, I use the VStudio project > files included in the LLVM tree (which are VStudio 2k3 files). I just > switched over to the SVN sources yesterday and spent some time working > with those project files to get things to build cleanly on my

On Tue, 17 Aug 2004, Reid Spencer wrote: > That's pretty cute actually. Do you want this "brilliant" :) example in the cvs > repository? I'd be happy to put it in. Here's an idea: how about we take the ModuleMaker, Valery's previous example, and this one and put them all in one "small examples" project? -Chris > Valery A.Khamenya wrote: > >

Hi LLVMers, The root of my SRC_DIR is: /home/hb/projects/src/llvm-1/llvm/ and the root of my OBJ_DIR is: /home/hb/projects/build/FC1/llvm-1-1. However, the configure script seems to have stripped some of the / from the paths: Makefile.common:63: /home/hb/projects/buildFC1llvm-1-1/Makefile.config: No such file or directory Makefile.common:69: /home/hb/projects/srcllvm-1/Makefile.rules: No such

LLVMers, The oversight group has been kicking around the idea of getting a better version control system than CVS. The problem is, we're not quite sure what "better" means. So, we thought we'd ask your opinions. There are three options, unless someone strongly advocates another solution: 1. Stay with CVS 2. Use Subversion 3. Use arch Some of the things we're trying to

On Sat, 2005-06-18 at 10:32 +0200, Henrik Bach wrote: > Hi LLVMers, > > The root of my SRC_DIR is: /home/hb/projects/src/llvm-1/llvm/ > and the root of my OBJ_DIR is: /home/hb/projects/build/FC1/llvm-1-1. > > However, the configure script seems to have stripped some of the / from the > paths: > Makefile.common:63: /home/hb/projects/buildFC1llvm-1-1/Makefile.config: No

I've gone about as far as I can in building executables with VC++. The problem with the remaining ones is that they rely on the static constructor trick to register various modules. This doesn't work with VC++ because without an explicit external reference to these modules they simply can't be linked in to an executable. This isn't a new problem, of course. Morten

Misha Brukman wrote: > On Tue, Jun 21, 2005 at 02:11:22PM -0400, Ed Cogburn wrote: >> Reid Spencer wrote: >> > Its certainly possible to generate .ll files but its probably about >> > the same amount of work to use the LLVM API and there are >> > significant speed and validity benefits to doing so. >> >> Does this mean that LLVM is moving away from

Hi all, My 2 cents as well: Here where I work (The MathWorks), we have hundreds of developers. We use CVS but we've had to write several thousand lines of Perl to make it useful to us (through revisions, branching, testing, and integration). Mercifully, we're planning on going to another system. In short, CVS doesn't scale well. It also doesn't having good branching capabilities

On Thu, 21 Apr 2005, Reid Spencer wrote: > Why not put all this into a pre-commit filter in CVS and be done with > it? We'd never be bothered with it again as it would never be committed > again. I'd rather not have CVS commit scripts mucking with the code. If you want to have the nightly tester whine about source code with spaces at the end of lines (like it whines about

Jeff, There should be a way to do what we do with the Unix Makefiles and build re-linked object modules. That is, when we build an analysis or transform pass, we create two things: a .o file and a .a file. They contain the same code but the latter is searchable while the former is not. Can you not "pre-link" a bunch of .obj files together with VC++ to produce a new .obj file? And, when

LLVMers, I'm running into a fair bit of confusion as I start to *use* LLVM to build my own compiler. The issues relate to what is in a given .a or .o file, why linking takes so long, and getting LLVM header files to include correctly, and the lack of viable "install" target. I'll deal with each of these in turn: For my own project, I've added an AC_CHECK_LIB line to check

No, VC++ has no way to combine multiple .obj files into one. Nor is there any way to force the entire contents of a .lib file into an executable. Believe me, I looked for a way. Morten couldn't find one either. Even Microsoft's command line tools can't do it. Advantage: GNU. DLLs aren't that slow any more. Windows is so dependent on DLLs (the Win32 API itself is