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?
the third issue (not hardcoding all available or anticipated variants/
platforms/buildbots) and the second issue can be addressed easily,
to improve self-documentation:
#define TEST_BUILD(testID, tested, todo) ((defined(BUILDBOT) || tested) &&
!(todo) )
#if TEST_BUILD("my feature" , OSX || LINUX , IPHONE || PS4 || NO_TYPE_CLASSES )
.. new code ..
#else
.. old known-to-work code ..
#endif
where BUILDBOT is defined for BUILDBOTs and others who need to
live at the edge, 'tested' lists the variants for which the new feature is
already known to build, and 'todo' lists the variants for which the new
feature is known not to work yet, be it because previous test builds
have failed, or because the submitter doesn't know how to implement
the feature on those variants.
in this example, builds on OS, LINUX, or any BUILDBOT not
explicitly listed in IPHONE || PS4 || NO_TYPE_CLASSES, will
build with the new code. all other builds will use the old code.
in other words, user builds on most platforms will not be affected
by this kind of patch, while tested platforms can immediately take
advantage of it, and most buildbots will try to test-build with the
new code. only known-to-work and known-not-to-work variants
need to be listed explicitly (eg, the new buildbot for WIN128
would try to build with the new code, even though the code
doesn't mention this variant).
after a buildbot build, a simple find/grep will list all new TESTs:
find . -name <whatever> | xargs grep 'TEST_BUILD | grep -v <myvariant>'
(if the buildbot's variant V is not explicitly listed, the build used
the new code, and the patch submitter needs to add V either
to tested or to todo, or fix the code and try again)
similarly, a simple find/grep will list all ongoing TESTs, and the
missing/failed variants:
find . -name <whatever> | xargs grep 'TEST_BUILD
i may have forgotten my c/cpp, but this is starting to look like
a very cheap way of getting a significant reduction in broken
user builds while allowing use of the buildbots to test on all
variants/platforms, without slowing down patches.
too many concurrent TEST_BUILDS might still make the
buildbot reports useless for extended periods of time; but
the interim remedy for that would be to list the offending
TEST_BUILD variant in the 'todo' parameter, which anyone
could do, even if the patch submitter went on holiday..
btw, this topic usually attracts an intense discussion, so the
current silence makes me wonder whether i'm on the wrong
track somehow?
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
