[LLVMdev] Is there room for another build system?

[Kenneth Boyd]

Ó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.