Head broken again

[Claus Reinke]

>> 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