similar to: [LLVMdev] RE: LLVM + automake?

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

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)

Tanya Lattner wrote: > I've finished adding the -rundejagnu option to the nightly tester script, > which was the last step to fully support Dejagnu. I think now is the > appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot > of work went into using QMTest, so I think we should make this decision > carefully and before the 1.4 release. > > Here are the

On Wed, 20 Oct 2004 at 12:29:38 -0500, Misha Brukman wrote: > On Wed, Oct 20, 2004 at 01:01:33AM -0700, Reid Spencer wrote: > > Instead of spending a bunch more time on trying to get automake to work, > > I suggest we just fix the current makefile system to do what automake > > can do. Specifically we need to: > [snip] > > I am, of course, soliciting feedback

On Sunday 28 November 2004 00:24, Tanya Lattner wrote: Just some comments from a QMTest user... Note however, that even with them, dejagnu looks better. > Cons of QMTest: > 1) You have to use the gui to add directories. I think you're wrong. Manually creating a directory would work, as QMTest does not place anything special in directories. > 2) You have to use the gui to XFAIL

> > Cons of QMTest: > > 1) You have to use the gui to add directories. > > I think you're wrong. Manually creating a directory would work, as QMTest does > not place anything special in directories. I may have worded this poorly, but I think you have to use the gui to add new directories or tests, or specific tests. Otherwise, it does not know what to do with those

In an effort to simplify how tests are added to the LLVM testsuite, I've added support for Dejagnu. This only applies to the Feature and Regression tests. If this experiment goes well, we may switch from using QMTest to Dejagnu. I'm asking for people (especially those running nightly testers) to give Dejagnu a try. You will need to install Dejagnu (http://www.gnu.org/software/dejagnu/)

I've finished adding the -rundejagnu option to the nightly tester script, which was the last step to fully support Dejagnu. I think now is the appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot of work went into using QMTest, so I think we should make this decision carefully and before the 1.4 release. Here are the pros and cons in my eyes, please feel free to add your

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

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 application that automake might not be the best choice. I might just here to

Folks, I have completed the addition of automake makefiles to LLVM. All libraries, tools, and runtime libs build now with automake. Note that there are still many missing things in the automake support. Right now it just builds the basic software. However, before I invest more time in it, I thought some comparison would help us make some decisions about whether or not to proceed with automake

Talin wrote: > I've been using gtest (http://code.google.com/p/googletest/) for all of > my frontend unit tests and I'm very happy with it. It does all of that > automatic test discovery stuff pretty well. I haven't tried the XML test > report generation stuff, but it does have that capability. > Ok. > I don't know much about DejaGNU, and from what little I

Does anyone have any objections to removing support for QMtest from the LLVM regression testing framework? The LLVM Dejagnu framework has all of the functionality provided by QMtest and more. -Chris -- http://nondot.org/sabre/ http://llvm.org/

OvermindDL1 wrote: > On Fri, Oct 10, 2008 at 10:27 PM, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > >> /* snip */ >> > > I think a pure C++ llvm test platform would work quite well > personally. Not only could you test little parts of the API, but you > can also create IR in memory (or load the occasional file, but then > that would not test more

On Sun, Oct 12, 2008 at 12:58 AM, Talin <viridia at gmail.com> wrote: > I've been using gtest (http://code.google.com/p/googletest/) for all of > my frontend unit tests and I'm very happy with it. It does all of that > automatic test discovery stuff pretty well. I haven't tried the XML test > report generation stuff, but it does have that capability. > > I

Since we also ``sometimes'' have problems with incorrect configurations... ;-) Read this on the octave mailing list : (I'm not using octave; I'm trying to hear what they are talking about) ------- Start of forwarded message ------- Date: Mon, 17 May 1999 10:30:51 +0200 From: Thomas Walter <walter@pctc.chemie.uni-erlangen.de> To: jwe@bevo.che.wisc.edu CC:

If you rebuild the Makefiles using automake >= 1.13 then you'll likely hit this error: Makefile:1904: *** unterminated variable reference. Stop. This is caused by automake miscompiling GNU make macros that appear in the 'TESTS' variable decl in 'ocaml/Makefile.am'. I posted a bug about this upstream. It hasn't appeared yet, but it should turn up here in the near

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

Josh, Macports on OSX ships with automake-1.10 and the current autogen.sh detects 1.10 as an invalid version of automake. The following patch (snarfed from autogen.sh from libvorbis) fixes that. Once that is fixed there are still some other issues that need fixing for automake-1.10. Cheers, Erik diff -u -r1.16 autogen.sh --- autogen.sh 21 Nov 2006 01:40:57 -0000 1.16 +++ autogen.sh 10