Fawzi Mohamed wrote:
that s good, but maybe for a release one should also try to compile some
of the largish projects that are done in D (even al older frozen
version) to see if in larger codebases something comes up...
At least for D 1.0 on a fixed system the idea "if id did compile it
should compile again" is something that could be considered.
You could ask people to make a script "setup my program" that does it
with the dmd in the path.
This could be done for some releases (stable ones), yes bugs found this
way are harder to isolate, but it could be worthwhile.
I generally don't do that because:
1. I didn't write the code, and when it fails to compile it can be
rather time consuming because I don't know what it is intended to be doing.
2. They often don't come with a test suite, and simply compiling it
doesn't really say if it works or not. If it does come with a test
suite, and the test suite fails, debugging someone else's code can be
very hard.
3. It makes running the test suite take considerably longer. I need it
to be fast, as I run it very often when developing things.
4. Nearly all problems boil down to less than 10 lines of code. This
makes for a very compact and fast running test suite. If the test suite
fails, the problem is usually already isolated down.
5. I've discovered over the years that programmers write in particular
"islands" of the language. No matter how large a code base they produce,
they never stray outside that island, so once the bugs they initially
encountered are fixed, they never run into compiler bugs anymore. The
coverage of a test suite is simply not a function of number of lines of
code thrown at it.
In other words, large applications tend to make lousy test suites. A
test suite needs to be written to be a test suite.
On the other hand, anyone can subscribe to the dmd-beta mailing list,
and have a chance to check for regressions on their own code before the
release. It's the point of the list.
