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). On a related note, has anyone gotten the LLVM test suite working on MinGW? I am in the process of trying to get LLVM working on my Windows box. I expect I can get the test suite working on Cygwin - but I'm not sure about MinGW. Message: 6 Date: Wed, 30 Jul 2008 10:43:14 -0700 From: Chris Lattner <clattner at apple.com> Subject: Re: [LLVMdev] Is there room for another build system? To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Message-ID: <1AFD3D24-C017-4B2A-9725-51B6A6568E36 at apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes On Jul 30, 2008, at 9:41 AM, ?scar Fuentes wrote:> I'm evaluating CMake (1) primarily as an alternative build system for > Visual Studio users, although it can easily be a replacement for > `configure' and hand-made makefiles too, providing a single build > system > for all platforms. CMake is a tool that takes a project description > and > configures, generates makefiles, project files for IDEs, etc as > requested.Ok. Killing off autoconf would be a huge bonus, but should probably be done as a second step.> There are three MS C++ compilers capable of compiling LLVM: Visual > Studio 2003, 2005, 2008 and their respective "free tools" > edition. However, the project files distributed with LLVM are for > 2005. This means that people using 2003 is left in the cold and people > who only have 2008 must convert the project files and, most important, > can't contribute to the maintenance of the VC++ build.Yes, this is a problem. We also support Xcode to various degrees on the mac, and keeping all these project files in sync with the makefiles is a pain.> Furthermore, CMake can replace `configure' and generate gmake > makefiles, > project files for XCode, etc.Having one point of truth would be great.> Now, my questions: > > 1. General LLVM users: Are you so happy with `configure' and hand-made > makefiles that you wont consider an alternative? If you are > interested, > I can steer my work to cover all platforms.I would prefer to kill off makefiles if we have something better. We really only want to support one build system.> 3. LLVM administrators: Do you object to having a CMakeLists.txt file > on every source directory?No, particularly if it means we eventually lose the Makefile :). One trick is that we want to keep llvm-config and the 'LINK_COMPONENTS' system used when building tools. I am sure cmake can handle this, but I just wanted to mention that it is important. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20080730/7c742163/attachment.html>
"Jonathan Brumley" <jbrumley at gmail.com> writes:> 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).Completely agreed. However, for VC++, I'm not thinking on LLVM contributors, but on LLVM users.> On a related note, has anyone gotten the LLVM test suite working on > MinGW? I am in the process of trying to get LLVM working on my > Windows box. I expect I can get the test suite working on Cygwin - > but I'm not sure about MinGW.People run the GCC test suite on MinGW and, IIRC, LLVM uses the same framework, so it should be doable. -- Oscar
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). > > On a related note, has anyone gotten the LLVM test suite working on > MinGW? I am in the process of trying to get LLVM working on my > Windows box. I expect I can get the test suite working on Cygwin - > but I'm not sure about MinGW.The LLVM test suite requires expect as a dependency of DejaGNU. The stock source of expect requires a *NIX fork, so it's relatively difficult to build under MinGW even though Tk/Tcl is easy to build under MinGW. (I'm not aware of a precompiled MinGW binary for expect, although it might be in one of the more obscure packages). I'd be interested in a successful build (with patches) for expect myself. I've been thinking of constructing a mirror test suite coordinated using shell scripts (bash) to replace DejaGNU. (This is for maximal portability. For Windows, batch files are another option; however, they have some limitations relative to shell scripts.) This is rather solidly in the "feasibility study/vaporware" stage for LLVM, although I've had moderate success testing the ideas with batch files on an internal project. Kenneth
Kenneth Boyd <zaimoni at zaimoni.com> writes:> The LLVM test suite requires expect as a dependency of DejaGNU. The > stock source of expect requires a *NIX fork, so it's relatively > difficult to build under MinGW even though Tk/Tcl is easy to build > under MinGW. (I'm not aware of a precompiled MinGW binary for expect, > although it might be in one of the more obscure packages). I'd be > interested in a successful build (with patches) for expect myselfAbout two years ago, ActiveState added the Windows port of Expect to its Tcl distribution, which is the de-facto canonical source of Tcl/Tk for Windows users. Check activestate.com [snip] -- Oscar
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 List" <llvmdev at cs.uiuc.edu> > Date: Wednesday, July 30, 2008, 3:15 PM > 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). > > > > On a related note, has anyone gotten the LLVM test > suite working on > > MinGW? I am in the process of trying to get LLVM > working on my > > Windows box. I expect I can get the test suite > working on Cygwin - > > but I'm not sure about MinGW. > The LLVM test suite requires expect as a dependency of > DejaGNU. The > stock source of expect requires a *NIX fork, so it's > relatively > difficult to build under MinGW even though Tk/Tcl is easy > to build under > MinGW. (I'm not aware of a precompiled MinGW binary > for expect, > although it might be in one of the more obscure packages). > I'd be > interested in a successful build (with patches) for expect > myself. > > I've been thinking of constructing a mirror test suite > coordinated using > shell scripts (bash) to replace DejaGNU. (This is for > maximal > portability. For Windows, batch files are another option; > however, they > have some limitations relative to shell scripts.) > > This is rather solidly in the "feasibility > study/vaporware" stage for > LLVM, although I've had moderate success testing the > ideas with batch > files on an internal project. > > Kenneth > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu llvm.cs.uiuc.edu > lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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++?