similar to: [LLVMdev] automake (PR106)

Hi, I'd like to convert LLVM to use automake. This, as you know, has been a hot-button for me over the last several months. See http://llvm.cs.uiuc.edu/PR106 for the details. Now that llvm/test/Programs is moved out of the main source repository, I think the time is right. However, I don't want to break everyone's build environment while I develop it. The plan is to have peaceful

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

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/ > >

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 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

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

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.

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 $

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

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

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:

Thank you for the response. I guess the only thing that is confusing is that the LLVM documentation, at http://llvm.org/docs/Projects.html under the "Create a Project from the Sample Project" heading, indicates that (1) you can place your project *anywhere* you want, and (2) that you are supposed to use the AutoRegen.sh script as is. However, that seems not to be the case. The

On Thursday 21 October 2004 01:54, Vladimir Prus wrote: > On Wednesday 20 October 2004 12:01, Reid Spencer wrote: > > 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

After puzzling about the size of the executables and the build times, I discovered (thanks Chris!) that I had compiled everything without debug symbols in the automake version. So, here's some revision from the first version of this email. The build times didn't change much (I guess I/O is cheap on my machine). The new "Build With Automake" times are 20m28.672s (elapsed),

One more update. The Makefile.am for analyze was wrong. It wasn't linking in the some of the passes. The new size is 56951088 which is in line with the other executables. Also, I have now completed a run of projects/llvm-test/MultiSource with the tools generated by automake. The only errors were for: TEST (llc) 'sgefa' FAILED! TEST (jit) 'sgefa' FAILED! TEST (jit)

FYI, The changes to make libtool appear as mklib have now also been committed. If you want to have support for mklib in your build tree, here's what you do: cd $objdir rm libtool $srcdir/configure --prefix=... --llvmgccdir=... After configure runs, you should have a "mklib" script in your $objdir and the Makefile.rules have been configured to use it. Reid. On Sun, 2004-09-19 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

For those of you that rebuild the configure script, please note that the required auto* tools have been updated. The AutoRegen.sh script now requires: autoconf 2.60 libtool 1.5.22 automake 1.9.6 The versions we were using were getting a little stale (several years out of date) and the change was made in an attempt to get better support from libtool for --whole-archive option (see PR780). Reid.

It's complaining about the LLVM autoconf/m4 directory which contains the m4 macros that are used in your project's configure.ac. By convention, your project should be in the llvm/projects directory so that you have: 1. llvm/autoconf 2. llvm/projects/yourProj/autoconf The AutoRegen.sh in #2 is looking for #1. By convention that should be located at ../../../autoconf/m4. AC_CONFIG_AUX_DIR

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.