this would work better for new features than for modifications.
developers on OSX would -after testing- check in something like:
#if (OSX || TEST(WIN) || TEST(LINUX) ..)
.. new feature ..
#endif
..
depending on build/test outcome. TEST(X) would be false for
any non-X variant, true for the X-buildbot. FAILED_TEST(X)
would be false everywhere.
actually, TEST(X) should be true only for the buildbot responsible
for X, so that anyone else checking out from the main repo won't
be affected by changes yet to be tested.
all the buildbots would need to push would be changes to the
cpp-directives. do you think that could work?
the buildbots wouldn't even need to push themselves, just generate
a report including all TESTs specific to their build. something like
find . -name <whatever> | xargs grep 'TEST(mybuild)'
if those reports were mailed to cvs-ghc, the developers could be
responsible for modifying the cpp-directives as soon as successful
buildbot reports for all/some variants come in.
similarly, if any failed buildbot report included TESTs, their
developers would be responsible for either fixing or disabling
the code (other developers wouldn't be affected directly, but
buildbots hampered by known-to-fail TESTs would be of no
use to them).
obvious issues:
- cpp or similar is needed everywhere :-(
- should the TEST macro include a test identifier?
- how to generate the list of TEST(X)s? can this be automated?
what do you think?
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
