i'm not a fan of cpp, but two things it was good for in other
projects was
..
I'm immediately suspicious of any plan involving more CPP use - the
existing CPP we have (for platform-specific code, mostly) is one of the
causes of build problems, as the compiler can't spot that modifying
import lists, refactoring code, giving a function an extra argument,
etc, hasn't broken the build for another platform.
yes, as i said, i'm not a cpp fan either. just a few quick points:
- this particular use is intended to be temporary. the only purpose is
to isolate ghc hacker X from patches committed by ghc hacker Y
for just as long as it takes for hacker Y to fix his patches so that
they successfully pass all buildbots (assuming there's a buildbot
for every ghc variant/platform someone cares about). once that
is achieved, all the TEST_BUILD cpp stuff should be removed
from hacker Y's patches.
- this use is entirely schematic. once the ghc team has prescribed
an agreeable definition and use pattern of the TEST_BUILD
macro, using that pattern should add not extra breakage (note
that any platform-specific code would have its own cpp use
inside the TEST_BUILD then-branch). the only issue i can
think of here would be haskell-code that isn't cpp-friendly.
- noone would be forced to use the TEST_BUILD scheme to
ease their patches into the main repo. but anyone not using
the scheme would better be very sure of their work. while
anyone using the scheme (provided they do a successful
build on at least one platform) would have some additional
insurance - they are less likely to break other people's builds,
because all of their additions will be invisible to anyone but
the buildbots until the TEST_BUILD protection is explicitly
removed for a platform - *after* the buildbot for that
platform reports a successful build *with* the new code.
i'd be happier if the same advantages could be achieved
without cpp, but the issues that the TEST_BUILD scheme
is intended to isolate us from are likely to be platform-specific,
or else they wouldn't break some builds while working on at
least one build.
the idea is that i develop my presumably standard code,
build on a standard platform, and send a patch, protected
by TEST_BUILD. then Manuel checks out the latest ghc,
with my patch in the source but still disabled, and with the
SPJ patch he needs, already tested and enabled. he builds
ghc successfully and goes on with his work, while the
buildbot for his platform tries to build the same source,
but with my patch enabled.
so i get back error reports that tell me that mingw doesn't
support that "standard" header i used, or that Manuel's
platform has changed what used to be a "standard" function
into a non-standard macro. then i disable my patch for
those two platforms, and ask on this list whether there's
a way to make my patch work on those two platforms
as well. all the while, noone but two buildbots has been
inconvenienced. unlike now, when Manuel's build would
have failed, with my incomplete patch preventing him
from getting easy access to the SPJ patch he needs.
so much for a usage scenario. does this explain what
i'm after? in a sense, the idea is to integrate the
last-known-good versions into the main repo: only
buildbots and adventurous souls see the bleeding
edge of untested patches. everyone else is protected
by the TEST_BUILD scheme.. i hope;-)
this is just one proposal. but we do seem to agree
that we need something, and this sounds workable
at least in theory. perhaps, like the buildbot-specific
last-known-good repos, it will have problems in
practice. i don't know!-)
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
