similar to: [LLVMdev] LLVM Makefile Guide

The llvm.cs.uiuc.edu site does not seem to be updating at the moment so it contains the old instructions. If you're looking for the new instructions on the Projects.html page, you can view them here: http://illuvium.net/docs/Projects.html Reid. On Sat, 2005-01-15 at 18:30, Reid Spencer wrote: > The proposed makefile changes have been committed. If you are working > from CVS head and

The proposed makefile changes have been committed. If you are working from CVS head and you use the LLVM Makefile System in your own project, please make a note of the following: 1. If your makefiles use any BUILD_* variables, they now need to be prefixed with PROJ_ instead of BUILD_. For example, BUILD_SRC_ROOT is now PROJ_SRC_ROOT. 2. There are additional requirements

The proposed makefile changes have been committed. If you are working from CVS head and you use the LLVM Makefile System in your own project, please make a note of the following: 1. If your makefiles use any BUILD_* variables, they now need to be prefixed with PROJ_ instead of BUILD_. For example, BUILD_SRC_ROOT is now PROJ_SRC_ROOT. 2. There are additional requirements for projects.

On Fri, 14 Jan 2005, Reid Spencer wrote: > In buildling XPS using LLVM's makefile system, I'm finding that there's > a few things lacking in our support for LLVM-based projects. The items > below should help but may require changes to project makefiles. I > thought I'd check before just going and doing it. ok. > 1. Various autoconf generated variables (e.g.

If you're on the new Makefile system, you will want to update your Makefile.rules. The patch below provides some important fixes for parallel builds and dependencies. It also adds some new features like the -local targets. For example, you can now build "all-local" to build the local directory without recursing into subdirectories. See the comments below for details of the change.

On Mon, 11 Oct 2004 08:08:56 -0700 Reid Spencer <reid at x10sys.com> wrote: > FWIW, I agree that the current situation with llvm-gcc is not ideal, but > most of us just build llvm-gcc once and forget about it. The real > solution here is to endow LLVM with its own C/C++ compiler and bootstap, > but that's a longer strategy. > > Reid. While I agree this would be the

Hi, In buildling XPS using LLVM's makefile system, I'm finding that there's a few things lacking in our support for LLVM-based projects. The items below should help but may require changes to project makefiles. I thought I'd check before just going and doing it. 1. Various autoconf generated variables (e.g. abs_top_srcdir) are set in the makefiles but not used. They

Hi Mike, Sounds like an interesting project. Here's some ideas for you on the LLVM Makefile System. If you haven't, I *strongly* suggest you read the makefile and project documentation (docs/MakefileGuide.html and docs/Projects.html). There is much information there that you need to understand. LLVM is set up so that a single directory builds a single result. Since your source code

On Tue, 12 Oct 2004, Jeff Cohen wrote: > On Mon, 11 Oct 2004 08:08:56 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > FWIW, I agree that the current situation with llvm-gcc is not ideal, but > > most of us just build llvm-gcc once and forget about it. The real > > solution here is to endow LLVM with its own C/C++ compiler and bootstap, > > but

John, The point I was trying to make (and obviously didn't) was that because automake can make the mechanics of building/testing/packaging a release so much easier (one command), it is possible for this to be automated regularly (e.g. nightly test). Consequently, the problems only seen when building a distribution would be available much sooner than the week before the release. Distribution

On Thu, 2005-05-19 at 22:34 +0100, Aaron Gray wrote: > I do not really feel upto looking into makefiles yet as I don't really know > automake, configure scripts, etc, etc > Aaron, its trivial. Open up tools/llvm-ar/Makefile in an editor. Go to the TOOLNAME line, delete the space at the end of the line, save the file, rebuild. > >I'll patch the makefiles when UIUC's

Hi Reid, just a quick note while you're doing this, a while ago I ran into a problem that the standard makefiles weren't building libraries (like, say, a new pass) correctly on OS X - they were being built as shared libraries and not bundles, so they couldn't be loaded with dlopen. The discussion is in the archives if you want more details... I fixed it locally by doing the following

This kind of thing is one of the many reasons we broke llvm-test out to a separate project. It has multiple purposes. Its a correctness test on LLVM, its what we base our compiler benchmarks on, and its also where a lot of the research gets done. You've been bitten by the latt(n)er. :) At some point I'd like to see us make some distinctions so that there is a correctness test suite whose

Wow... it is nearly twice as fast. But it tried to install stuff in /usr/local (and as I wasn't root...) and it didn't do that before. As I don't care about profiling or tracing, I didn't bother to su and do it again. On Wed, 10 Nov 2004 23:45:35 -0800 Reid Spencer <reid at x10sys.com> wrote: > The entire makefile system was rewritten a couple of weeks ago. This is

No, I don't feel strongly about it... it's just annoying to have things change on me that break habits :) On the other hand, I do feel strongly about the tests in llvm-test that are now failing on me because they explicitly include alloca.h, a file that does not exist on FreeBSD. I can supply a patch to take out the include, of course, but the problem then becomes that the tests will

The default prefix is /usr/local but I would recommend that when you configure LLVm you do so with: configure --prefix=/me/llvm/install/dir ... so that installation occurs in a place you have write access. If you feel strongly about restoring the install-bytecode target, feel free to file a bug. Reid. On Thu, 2004-11-11 at 09:12, Jeff Cohen wrote: > Wow... it is nearly twice as fast. But

And, one more weird thing in this function. The FILESize static variable is never initialized so its likely initial value is 0 due to zero fill on many MMUs. The value is never written and used as a divisor. Why hasn't this function caused an arithmetic violation? Because the IOBBase point, also a static variable is initialized to zero and never modified and used in a conditional that thwarts

The LLVM 1.4 Release is now out! Get it here: http://llvm.cs.uiuc.edu/releases/ or read about it here: http://llvm.cs.uiuc.edu/releases/1.4/docs/ReleaseNotes.html#whatsnew This release features a huge assortment of improvements in functionality, generated code quality, and compile times. Thanks to everyone who has helped make this release the best one yet. In addition to the changes

I'll wait for the research. We should try, as much as possible, to make it work with just what the compiler provides and without third party packages. Thanks, reid. On Fri, 2004-09-24 at 07:46, Jeff Cohen wrote: > I added the include of cstudio and it fails with plain VC7.1; the file > does not exist. > > Add it for now. If it is impossible to build with VC7.1 and without

OK. I strongly support that sentiment. Paolo, could you send me your procedure for building under Windows? I haven't tried to build anything but System/Win32 so far. On Fri, 24 Sep 2004 07:52:23 -0700 Reid Spencer <reid at x10sys.com> wrote: > I'll wait for the research. We should try, as much as possible, to make > it work with just what the compiler provides and without