[LLVMdev] Is there room for another build system?

[Kenneth Boyd]

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
>>>> a less than 30 lines of code.
>>>>
>>>> What else do you need?
>>>>         
>>> A way to examine asm output and compate to expected patterns.
>>>       
>> This is a text manipulation task, isn't it? No problem.
>>
>>     
>>> A way to run performance regression tests (i.e. looking at CPU time
>>> and allowing for fuzz between test runs).
>>>       
>> Do you mean that you want a language with that feature built-in?
>>
>>     
>>> In my experience Tcl is very hard to work with due to the
>>> non-existence of any reasonable debugging tools on all platforms.
>>>       
>> For one reason or another, my Tcl code never grows so large that I  
>> miss
>> a debugger. A `puts' here and there plus the repl is enough :-)
>> Message: 6
>> Date: Mon, 4 Aug 2008 17:48:47 -0500
>> From: David Greene <dag at cray.com>
>> Subject: Re: [LLVMdev] Is there room for another build system?
>> To: llvmdev at cs.uiuc.edu
>> Message-ID: <200808041748.48057.dag at cray.com>
>> Content-Type: text/plain;  charset="iso-8859-1"
>>
>> On Monday 04 August 2008 16:59, ?scar Fuentes 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
>>>>> a less than 30 lines of code.
>>>>>
>>>>> What else do you need?
>>>>>           
>>>> A way to examine asm output and compate to expected patterns.
>>>>         
>>> This is a text manipulation task, isn't it? No problem.
>>>       
>> No problem with Perl either, or Python.  Tcl is much less well-known.
>>
>> Note that I don't particularly like any of these languages but I'm  
>> trying
>> not to let personal preference get in the way.  :)
>>     
>
> (Is there a scripting language that you like?)
>
>   
>>>> A way to run performance regression tests (i.e. looking at CPU time
>>>> and allowing for fuzz between test runs).
>>>>         
>>> Do you mean that you want a language with that feature built-in?
>>>       
>> No, I mean in the future we should have tests that actually pass/ 
>> fail based
>> on their runtime performance.  To do that you need a way to time the  
>> test
>> and a way to account for normal system variations (the fuzz bit).
>>
>> We don't have any of these kinds of tests yet.  But I hope we do in  
>> the
>> future.
>>
>>     
>>>> In my experience Tcl is very hard to work with due to the
>>>> non-existence of any reasonable debugging tools on all platforms.
>>>>         
>>> For one reason or another, my Tcl code never grows so large that I  
>>> miss
>>> a debugger. A `puts' here and there plus the repl is enough :-)
>>>       
>> How many people know Tcl?  That has a direct impact on maintanability.
>>     
>
> IMHO, anyone that is discussing LLVM internals will have no trouble  
> with any popular scripting language, including Tcl.
>   
Other than learning curve, yes.
> I'm not expert in any of these languages, nor do I have a strong  
> preference.  But I have some impressions:
>
> ...
>
> sh/csh/bash/zsh: Widely understood and used, but wordy and there are  
> portability issues.  (Perhaps someone with Ming and Cygwin experience  
> can speak to shell portability?)
I'm indulging in this exercise to enable testing a native MingW32 build 
of LLVM in Windows.

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.

With best regards,
Kenneth