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 issues *between* shells, than across OS's. > If I go ahead with targeting bash, I suspect (by avoiding bash > extensions and otherwise being careful) that the resulting script should > work on any recent Bourne compatible shell. csh will not be supported > at all (incompatible test operator syntax). > > Note that shell scripts can coordinate invoking other languages/tools; > targeting bash doesn't rule out using Tcl/Perl/Python/etc. where convenient.AFAIK, there is no "native" port of `bash' on Windows. If you plan to use Cygwin's (or MSYS', which is a fork of Cygwin) you will discover that it is quite tricky to work with non-Cygwin processes (including MinGW's gcc) due to differences on directory structures, I/O, process control, etc. -- Oscar
Ó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 fix something that maybe is not broken. >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 political reasons, so running DejaGNU under CygWin isn't a real option for me.>> There are more portability issues *between* shells, than across OS's. >> If I go ahead with targeting bash, I suspect (by avoiding bash >> extensions and otherwise being careful) that the resulting script should >> work on any recent Bourne compatible shell. csh will not be supported >> at all (incompatible test operator syntax). >> >> Note that shell scripts can coordinate invoking other languages/tools; >> targeting bash doesn't rule out using Tcl/Perl/Python/etc. where convenient. >> > > AFAIK, there is no "native" port of `bash' on Windows. If you plan to > use Cygwin's (or MSYS', which is a fork of Cygwin) you will discover > that it is quite tricky to work with non-Cygwin processes (including > MinGW's gcc) due to differences on directory structures, I/O, process > control, etc. >I've been using MSYS' for slightly over a decade now. It's not nearly as tricky as you imagine, aside from not having *NIX fork() and the occasional adjustments needed to deal with confused configure scripts. Just remember to run configure and make from *within* bash (MSYS-3.1); things are much worse with sh ./configure from the Windows command shell, than ./configure within bash. Best regards, Kenneth The reason CMake won't build "out of the box" for me, is that it's *misapplying* the CygWin workarounds to MinGW -- and then refusing to write out something for me to fix up.
So just to add to this conversation, I *too* was thinking about rewriting the build system :) I've been writing a new build system from the ground up, and I was hoping to see how my system would work against llvm. I wanted to make sure that I understand the licensing issues. I'm releasing my build system using just a standard BSD license, which is compatible with llvm's license, right? I just have to make sure any code I use from llvm's autoconf directory is properly attributed? Anyway, if anyone is interested in yet-another-buildsystem, I've got the (pre-alpha) code up here: http://git.felix-lang.org/?p=fbuild.git;a=summary It's designed to be used for cross compiling, configuration, and being really simple to extend, since it's written in python (3.0b2). It's also only ~3500 lines, which is way smaller than any other build system I've seen for what it supports. I'll be on #llvm and #felix on freenode (as erickt) if anyone actually wants to talk about it.
On Aug 5, 2008, at 9:12 PM, Erick Tryzelaar wrote:> I'm releasing my build system using just a standard BSD > license, which is compatible with llvm's license, right?Yes. -Chris
[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 political reasons, so > running DejaGNU under CygWin isn't a real option for me.If politics enter the game, this becomes too much complex for me, sorry.> I've been using MSYS' for slightly over a decade now.Is MSYS so old? IIRC its existence was first made public on 2001. At the time I was an active MinGW-ist. (I'm getting old... :-)> It's not nearly as tricky as you imagine, aside from not having *NIX > fork() and the occasional adjustments needed to deal with confused > configure scripts.As mentioned above, MSYS is a Cygwin fork, tweaked for MinGW friendliness. However, as you point out, MinGW developers prefer to build from Cygwin. Maybe this comes from the previous MinGW developers (pre-MSYS) who used Cygwin extensively, maybe there are technical reasons for doing so. [snip]> The reason CMake won't build "out of the box" for me, is that it's > *misapplying* the CygWin workarounds to MinGW -- and then refusing to > write out something for me to fix up.I'm having success building the LLVM libraries with CMake 2.6.1 on MSYS, where 2.6 failed, IIRC. Maybe this was fixed. -- Oscar