llvm dev - Aug 2008 - [LLVMdev] Is there room for another build system?

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