similar to: [LLVMdev] Is there room for another build system?

Jonathan Brumley wrote: > > 2 more roadblocks for Visual Studio users are the inability to compile > gcc and the inability to compile and run the test suite. I would not > want to submit a change unless I could still compile/run gcc and pass > the test suite. (Testing before submission is the way we do it where > I come from - I am assuming it's the same here). >

Hi Kenneth, If the LLVM project is switching to CMake, then CTest might be the framework of choice to use rather than scripting up something in Bash. --Sam --- On Wed, 7/30/08, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > From: Kenneth Boyd <zaimoni at zaimoni.com> > Subject: Re: [LLVMdev] Is there room for another build system? > To: "LLVM Developers Mailing

Kenneth Boyd <zaimoni at zaimoni.com> writes: > I'm indulging in this exercise to enable testing a native MingW32 build > of LLVM in Windows. If LLVM's DejaGNU usage is the same as GCC's, I'll google or ask on the MinGW mailing list how MinGW testers run the GCC testsuite, before trying to fix something that maybe is not broken. > There are more portability

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > > >> I'm indulging in this exercise to enable testing a native MingW32 build >> of LLVM in Windows. >> > > If LLVM's DejaGNU usage is the same as GCC's, I'll google or ask on the > MinGW mailing list how MinGW testers run the GCC testsuite, before > trying to

On Jul 30, 2008, at 1:15 PM, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > I've been thinking of constructing a mirror test suite coordinated > using > shell scripts (bash) Please no, pick a real language. I love bash and it is fine for any 200 line or less program, but for much beyond that, something else. Python?c? C++?

On Sat, Oct 11, 2008 at 7:30 AM, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > At the absolute minimum, simple counting of the success/failure/internal > error results requires three different exit codes, and a test driver > capable of tallying them up and reporting all failures (unexpected > success, unexpected failure, and internal errors with a designated > distinct exit

[As this is turning off-topic, feel free to switch to private email] Kenneth Boyd <zaimoni at zaimoni.com> writes: > Note that the official MinGW GCC binaries generally are not > bootstrapped; they're cross-compiled (presumably from CygWin). [In > particular, both the 3.4.5 and 4.2.1 MinGW binaries of gcc are not > bootstrapped.] I use MinGW rather than CygWin for

Kenneth Boyd <zaimoni at zaimoni.com> writes: >>> I've been thinking of constructing a mirror test suite coordinated >>> using shell scripts (bash) >> >> Please no, pick a real language. I love bash and it is fine for any >> 200 line or less program, but for much beyond that, something else. >> Python?c? C++? >> > If I thought

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 of the things, which is kind of the purpose) and either JIT it to test

Stuart Hastings wrote: >> David Greene <dag at cray.com> writes: >> >> >>>> For my test suite I use Tcl (with TclX, no Expect). It watches >>>> stdout >>>> and stderr, gets exit codes and has a timer for killing hanged >>>> processes. Process control works the same on Windows and Unix and >>>> takes

Mike Stump wrote: > On Jul 30, 2008, at 1:15 PM, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > >> I've been thinking of constructing a mirror test suite coordinated >> using >> shell scripts (bash) >> > > Please no, pick a real language. I love bash and it is fine for any > 200 line or less program, but for much beyond that, something

On Friday 01 August 2008 00:22, Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > >>> I've been thinking of constructing a mirror test suite coordinated > >>> using shell scripts (bash) > >> > >> Please no, pick a real language. I love bash and it is fine for any > >> 200 line or less program, but for much beyond

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 don't know much about DejaGNU, and from what little I know about it, I'm not sure its worth my

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

Kenneth Boyd <zaimoni at zaimoni.com> writes: >> I'm seeing a failure related to circular library references while >> building LLVM with CMake and MSYS. This didn't happen on the >> past. Building with the configure script works, so it seems something >> related to CMake. Do you have any insight on this? >> > I'll get back on this tonight or

Kenneth Boyd <zaimoni at zaimoni.com> writes: [snip] >> That does not really surprise me about CMake, but then mingw is not a >> primary compiler on Windows, more so is VC++ or Intel, either way a >> bug should be submitted to the CMake devs. > I do not want to troll the CMake devteam, so I will not submit the bug > report without a full-blown patch. The CMake

Kenneth Boyd <zaimoni at zaimoni.com> writes: >>> * I am seeing desynchronization between the configure-generated >>> Makefiles and the CMakeFile.txt files. [e.g., llc; makefile doesn't >>> have asmprinter, CMakeFile.txt does]. That much I should be able to >>> construct a patch for "blind", if no-one gets to it first. >>>

> > David Greene <dag at cray.com> writes: > >>> For my test suite I use Tcl (with TclX, no Expect). It watches >>> stdout >>> and stderr, gets exit codes and has a timer for killing hanged >>> processes. Process control works the same on Windows and Unix and >>> takes >>> a less than 30 lines of code. >>>

OvermindDL1 wrote: > On Sat, Oct 11, 2008 at 7:30 AM, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > >> At the absolute minimum, simple counting of the success/failure/internal >> error results requires three different exit codes, and a test driver >> capable of tallying them up and reporting all failures (unexpected >> success, unexpected failure, and

On Fri, Oct 10, 2008 at 2:44 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > That is because the lib/CodeGen project file is missing PBQP.cpp. That did not help, that cpp and its header do not contain createPBQPRegisterAllocator anywhere in them. it was still missing those files in the project though. What did fix it was adding in RegAllocPBQP.cpp, so that file, and the PBQP.cpp/.h need