similar to: [LLVMdev] Time For automake?

Folks, I have recently added support for building LLVM with automake. This shouldn't affect anyone, and is entirely optional at this point. Note that the automake support is currently in addition to the current makefile system, it doesn't replace it. This effort isn't complete (e.g. install doesn't work), but if you'd like to take a look at what's coming or even help, it

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

Hello, I've closed PR106 (use automake) as WONTFIX. I've already delineated the problems with automake in previous posts but as of now, all the automake related stuff has been removed from the repository. In an effort to start making our makefile system better, I've committed changes to Makefile.rules and a few library Makefiles that nearly double the speed of our compilations. I

On 2/23/07, Reid Spencer <rspencer at reidspencer.com> wrote: > > However, if I run the AutoRegen.sh script (after modifying it to > > accept autoconf 2.61, which I think is fine as gentoo slots it the > > same as the 2.5[0-9] versions), the configure no longer works: > > ~/programming/llvm-1.9/projects/zhe $ cd autoconf/ > >

I'm forwarding this bug resolution because it has a pretty wide impact on LLVM developers. This bug (451) has been resolved (well, works for me anyway). If you have reconfigured your build tree since October 4th, you need to reconfigure again. The bug produced shared objects that don't have a .so extension. Reconfiguring will fix this problem. The notes below show what was needed to

Hello Scott, On Wed, 2007-02-21 at 18:57 -0500, me22 wrote: > I'm trying to follow docs/Projects.html to use llvm in a project of my own. > > If I just copy the sample directory, running configure in the new one > works fine: > ~/programming/llvm-1.9/projects $ cp -a sample/ zhe > ~/programming/llvm-1.9/projects $ cd zhe/ > ~/programming/llvm-1.9/projects/zhe $

I'm trying to follow docs/Projects.html to use llvm in a project of my own. If I just copy the sample directory, running configure in the new one works fine: ~/programming/llvm-1.9/projects $ cp -a sample/ zhe ~/programming/llvm-1.9/projects $ cd zhe/ ~/programming/llvm-1.9/projects/zhe $ ./configure configure: creating ./config.status config.status: creating Makefile.common config.status:

Hi Ryan, The output from autoconf doesn't look familiar (but then, does it ever?). Note that it thinks that AC_CONFIG_MAKEFILE isn't defined which is likely if you didn't get the LLVM_SRC_ROOT correct. Here's the only things I can think of: 1. You also need to cvs update llvm/autoconf/m4 to get the new definition of LLVM_CONFIG_PROJECT. 2. You typed in the LLVM source root

Reid, Thanks for the help. I am trying out the fixes you checked into CVS. I seem to be getting some errors running AutoRegen.sh. I am a bit inexperienced with autoconf and m4. The errors I'm getting are below. Do you know what the problem is? I am using machines running FC3. The autoconf version is 2.59, the aclocal version is 1.9.2, and the m4 version is 1.4.1.

Reid, Thank you for all your help. I think that I have AutoRegen.sh working now. (I still get the warning about GOB2_HOOK, but I'm assuming that's not a problem.) I'll explain the scenario that led to the problem. I copied the sample project to ~/work/myproject/src/sample. Then I renamed it to ~/work/myproject/src/llvm, indicating that this was the llvm part of my project.

Hi, I'm trying to compile icecast-kh (last version) on a OpenBSD machine. While I execute ./autogen.sh an error occurs: autoheader libtoolize --automake automake --add-missing automake: #################### automake: ## Internal Error ## automake: #################### automake: unrequested trace `include' automake: Please contact <bug-automake@gnu.org>. at

Hello, I've tried NUT trunk SVN branch some time ago in order to use it with a Blazer USB UPS (megatec protocol driver supported by Carlos Rodriguez). This UPS wasn't yet supported by NUT but I was able to compile and test the software on my Debian. I download in order to try latest Rev: 805 today to see if USB support for my UPS where better but the 'autoreconf' command give me

Josh, Automake 1.10 on OSX is giving me warnings like the following: test/Makefile.am:50: wildcard *.raw: non-POSIX variable name test/Makefile.am:50: (probably a GNU make extension) test/Makefile.am:50: wildcard *.flac: non-POSIX variable name test/Makefile.am:50: (probably a GNU make extension) test/Makefile.am:50: wildcard *.oga: non-POSIX variable name

I have the latest updates to CentOS 5.6. However, I need different versions of autoconf and automake. How can this be handled? What will happen on later updates? Currently I have autoconf (GNU Autoconf) 2.59 automake (GNU automake) 1.9.6 I need autoconf 2.69-1 and automake 1.11.6. Thanks, John -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc.

I'm re-thinking my penchant for automake. automake is great for many standard applications that just need to get portable makefiles up and running quickly. However, it turns out that LLVM is "different enough" from a standard application that automake might not be the best choice. Here's some of the problems I've run into: 1. There's no way to tell automake to build

I've eagerly grabbed the current CVS as of a few minutes ago, and attempted to build and play with theora, but am running into a snag with the autogen.sh script: ------------------------------------------------------------------------ bash-2.05# ./autogen.sh I am going to run ./configure with no arguments - if you wish to pass any to it, please specify them on the ./autogen.sh command line.

RHEL 6 has automake 1.13.4. Since we have stopped supporting RHEL 5, there is no need for the complex macro to check for older versions of automake that didn't have 'serial_tests'. --- configure.ac | 17 +---------------- 1 file changed, 1 insertion(+), 16 deletions(-) diff --git a/configure.ac b/configure.ac index 88f5568..9fde5c5 100644 --- a/configure.ac +++ b/configure.ac @@

Ryan, Rather than fix the documentation to match reality, I decided to fix reality to match the documentation. I have just committed (CVS head) changes to the sample project's AutoRegen.sh script that will prompt the user for the path to the LLVM source root and the LLVM object root, if it can't automatically determine the location (because your project is not located in the llvm/projects

Compiling current git on MacOSX 10.5.8 Darwin mac.stare.cz 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 $ ./autogen.sh Updating build configuration files for FLAC, please wait.... configure.ac:26: require Automake 1.11, but have 1.10 autoreconf: automake failed with exit status: 1 Why

All, we recently had a user report an issue associated with utilizing LLVM-MC as the desired assembler in place of GNU’s GAS. They are utilizing a tangled mess of automake scripts to build this respective software package and have decided to manually override the “CCAS” macro to point directly to LLVM-MC (rather than using Clang). Apparently, automake assumes that whatever “compiler” (as it is