similar to: [LLVMdev] Missing #includes

I constructed an LLVM 2.7 VS solution with cmake, but it has 66 projects: ALL_BUILD, ".\ALL_BUILD.vcproj" BrainF, "examples\BrainF\BrainF.vcproj" Fibonacci, "examples\Fibonacci\Fibonacci.vcproj" FileCheck, "utils\FileCheck\FileCheck.vcproj" HowToUseJIT,

One thing that helps me understand complex software is a dependency graph. I found an LLVM dependency graph at https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_16/docs/UsingLibraries.html#dependencies but it's really messy and hard to follow. From that graph I made a cleaner graph by hand (attached)... sorry about the fax-quality scan. But I have some questions about it... -

Chris Lattner wrote: >>>Can you explain what goes wrong without the stub? It's the only part that >>>I didn't apply. >> >>The X86 backend doesn't get registered since there are no references to >>symbols in X86TargetMachine the object file is never pulled in from the >>library I create, and thus the static intializer for the RegisterTarget

Morten, I've applied these patches. Thanks for the updates! Reid. On Mon, 2004-11-15 at 01:26, Morten Ofstad wrote: > Hi, > > when I updated the sources today there were several small problems that > stopped the windows version from compiling, here are the patches > > m. > > > ______________________________________________________________________ > Index:

Vikram S. Adve wrote: > Another alternative may be to unify the LLVM-side information > (opt/debug options, tool names, directories, test scripts, etc.) so > that most tasks only require you to make changes in one place, and then > let the rest of the build system be separate for the two platforms. I think it's OK to have a seperate limited (only the core libraries) native

I moved my own llvm tree out of the way and tried to get a fresh copy from cvs and build everything from scratch... and it worked! apart from one little problem, a file was moved and should be removed from the project files -- here is a patch. There is a small problem with submitting patches for the .vcproj files - VS saves them with CRLF line endings but the CVS versions appear to have only

On Nov 2, 2004, at 2:40 AM, Morten Ofstad wrote: > Vikram S. Adve wrote: >> Another alternative may be to unify the LLVM-side information >> (opt/debug options, tool names, directories, test scripts, etc.) so >> that most tasks only require you to make changes in one place, and >> then let the rest of the build system be separate for the two >> platforms.

Like I said, it is in my path. That's not enough. I'd be happy if Morten chimed in with any suggestions as to how he got it to work. On Thu, 04 Nov 2004 18:45:18 -0800 Reid Spencer <reid at x10sys.com> wrote: > Two suggestions: > > 1. m4 might be located by your PATH variable. > 2. Talk to Morten Ofstad about how he got it to work. > > Reid. > > On

These are the updated .sln and .vcproj files for building llvm with MSVC 2008. It turned out that the compiling errors were because these projects wasn't updated to reflect the actual status of the llvm files. I checked all the files (removed, moved or added) and now they are ok. It compiles all targets from the first "Build Solution", both for Debug and for Release mode. You need

Are you sure your CVS is configured correctly? On Windows, CVS automatically converts between LF and CR/LF line endings. I sent a patch to remove all CRs from the repository because when I checked out the files on Windows, every line had two CRs and a single LF. When VS saved a modified project file, the extra CR went away, causing every line to diff. On Mon, 08 Nov 2004 12:10:21 +0100 Morten

On Tue, 13 May 2008, Razvan Aciu wrote: > These are the updated .sln and .vcproj files for building llvm with MSVC > 2008. > It turned out that the compiling errors were because these projects wasn't > updated to reflect the actual status of the llvm files. > I checked all the files (removed, moved or added) and now they are ok. > It compiles all targets from the first

On Thu, 4 Nov 2004, Jeff Cohen wrote: > path as it uses execvp. At least on Unix. I have no idea what it does > on Windows as I could not get the source used to build the Windows > version (the installer claimed it installed the source, but it didn't). Wierd. > The link of tablegen fails still fails, though, complaining of a missing > support.lib. This is due to a bug in

I verified the patch and it compiles all the targets, both in Debug and Release modes. If there is no someone else to keep the MSVC projects files updated, I will try from time to time to update them and to add the new targets. Maybe a note must be put in "docs/GettingStartedVS.html" at the Requirements section that llvm needs now MSVC (Express) 2008 to compile. Razvan -----

These calls are in ExternalCalls.cpp, they are platform dependent calls, so maybe llvm should consider including it's own implementation of a random number generator? For the time being I just replaced with calls to srand and rand like Paolo also did, but it needs to be fixed... m.

I have some patches of my own: * An improvement on Morten's fix to Signals.cpp. * Undo the breakage to system.vcproj (Signals.cpp was being built twice as a result). * Fix a class/struct inconsistency. * Remove unneeded #includes from win32 fSystem files. I've also determined why VC++ complains about deprecated destructors when using hash_map. Because it's not ANSI (yet),

I have problems getting the GNU tools to execute properly. I installed bison, sed, and flex from gnuwin32.sourceforge.net as suggested in the README. The installers for these packages did not want to put them in the llvm/win32/{tools,share} directory, which is unfortunately where the project files expect them to be. I copied the files manually to these directories, but bison still refuses to

Morten, have a look at the http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-September/002235.html thread... On Oct 19, 2004, at 2:40 PM, Morten Ofstad wrote: > These calls are in ExternalCalls.cpp, they are platform dependent > calls, so maybe llvm should consider including it's own implementation > of a random number generator? For the time being I just replaced with > calls

Two suggestions: 1. m4 might be located by your PATH variable. 2. Talk to Morten Ofstad about how he got it to work. Reid. On Wed, 2004-11-03 at 19:34, Jeff Cohen wrote: > I have problems getting the GNU tools to execute properly. I installed > bison, sed, and flex from gnuwin32.sourceforge.net as suggested in the > README. The installers for these packages did not want to put them

In lib/CodeGen/LiveVariables.cpp a variable length array is created. Since this is not standard C++, it won't compile with Visual Studio (for interested readers, there is a discussion of why the C99 style variable length array is a bad idea in C++ here: http://www.cuj.com/documents/s=8191/cuj0209stroustr/) I have made a patch that uses 'new' and 'delete' instead - if this

Hello, I've been away working on other things so I have not been able to respond to mails on this mailing list for a while. But today I got back and I got the latest version of LLVM from CVS and built it successfully (after I deleted my old config.h which was included instead of the one in the new location)... Jeff Cohen wrote: > OK, there may be some light at the end of the tunnel.