[dmd-internals] dmd commit, revision 657

[Walter Bright]

Brad Roberts wrote:
> On 9/2/2010 3:00 PM, Walter Bright wrote:
>   
>> Brad Roberts wrote:
>>     
>>> The major wish I have is that walter would start using the public test suite
>>> rather than the private one.  I'm working on getting the public one to work on
>>> windows -- making good progress, it runs most of the tests now.
>>>
>>>   
>>>       
>> It already works fine on Windows, and I disagree that it needed reengineering so
>> that it wouldn't.
>>     
>
> If you honestly think what I did was engineer it so that it wouldn't work on
> windows, we need to talk.

No, I don't mean that at all, and apologize for implying that. I meant 
the current setup is simple and effective and works on all the supported 
platforms.

I should add that Andrei agrees with you about this and disagrees with 
me strongly. So keep that in mind when you read the following.

>   It needed reenginering for other reasons (probably
> incomplete, but this is off the top of my head and quickly written):
>
> 1) to use a single driver for all platforms rather than one for each that were
> never kept in sync -- an old argument you keep loosing
>   

Except that there is much customization from one platform to the next. 
Switches are different, commands are different, paths are different, 
extensions are different, generated files are different, etc.

Not sure I keep losing the argument. For example, Phobos1 used to have 
std.c.stdio loaded with version declarations for the different _iobuf's 
for each platform. The trouble was, when one updated one platform one 
tended to break the others. Even worse, adding a new platform meant 
someone would just cut & paste the info from some other platform, and 
assume it worked. This added a bunch of work for me as I had to go 
through and vet every declaration. Things got better when I separated 
out each platform into its own import. These problems resurfaced with 
druntime, which tries to do a lot using version declarations instead of 
separate platform files.

So yes, on the one hand you can add files to all platforms 
simultaneously. On the other, there's constant breakage of the platforms 
the updater didn't test on.

> 2) to run tests in parallel -- your attempts at doing that in your custom shell
> engine didn't work out terribly well
>   

I didn't spend that much time on the multithreading, either <g>. One 
problem was that the text output of the different threads got 
interleaved, a problem that multithreaded make also has. The other 
problem is that optlink must always run on core 0, meaning that 
multithreading the test suite on Windows does not actually speed it up. 
Until I can fix that problem with optlink, it wasn't worth the effort to 
continue working on parallelizing the tests.

I've also got things set up now so that with one command I can fire off 
4 windows, and have each window ssh'ing into a different machine and 
running the build & test suite (Windows, Linux, OSX and FreeBSD). Those 
obviously all run in parallel (!). I can watch them all run on one screen.

> 3) to separate test driver output from test output -- spewing all that output to
> the screen is a mess.  Tests should have a single line of output: name of test
> and pass or fail
>   

I guess I never had any trouble noticing when one failed and which one 
it was.

> 4) to make it easy to run subsets of the test suite, specifically easy to run
> the one that's failing.
>   

I'm not sure what the problem is with typing:

   dmc test23


> 5) to run _all_ of the test suite -- note the 4 bugs I filed based on the
> failure tests that hadn't been run or would have caught a couple regressions.
>   

That failing was mine in not keeping the suite updated, not a fault in 
the methodology.

> Also of potential interest.. the biggest problem I've had with the windows
> support is switching from / to \ based on os since optlink can't handle it.  It
> looked like everything else was happy -- though dmd might have had some issues,
> I didn't try to isolate the issue between the two.  The o vs obj and nothing vs
> .exe were trivial.  Support for \ is a pain in the ass.. having to \\ in places
> -- right now something somewhere is retaining both \\'s rather than treating it
> as one escaped.  I got frustrated with that and your post so I set aside the
> project for the evening.
>   

The \ issue is always a problem. I'm always running into windows 
software, including Microsoft software, that doesn't recognize /.

> I'll finish it tomorrow or this weekend, maybe.
>
>
>