[LLVMdev] Is there room for another build system?

[Kenneth Boyd]

David Greene wrote:
> 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.  :)
>   
I already use both Python and Perl.  I ruled out Python, even though it 
is a very good match feature-wise (subprocess module For The Win), 
because my in-house applications (about 600 lines of code, maybe 800 
lines of code and comments) are not nearly as forward-compatible when 
avoiding deprecated constructions as the public relations statements 
imply; something has broken on *every* major release since I started 
using it (2.2 |-> 2.3. |-> 2.4 |-> 2.5).

My coding style just finds those breakages that aren't caught in 
Python's regression testing :)  I'm fine with this for small 
applications, but reimplementing the testcase runner looks like it's 
going to be large enough to make the 2.5 |-> 2.6  change a large breakage.
>>> 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.
>   
Agreed.  This (and the lack of a reliable cross-platform way to grab 
both stdout and stderr) is what has me nervous about using Perl.

Kenneth