Broken head

[Manuel M T Chakravarty]

Duncan,

BTW why do you think the System.Info.os problem is MacOS specific? 
The buildbot seems to think otherwise:

   http://www.haskell.org/pipermail/cvs-ghc/2007-August/037167.html

So, no validate after all?

Manuel

Manuel M T Chakravarty wrote,
> Duncan,
> 
>> On Mon, 2007-08-06 at 12:44 +1000, Manuel M T Chakravarty wrote:
>>> Running validate on the current (Mon Aug  6 12:42:45 EST 2007) head, 
>>> gives me
>>>
>>> /opt/local/bin/ghc -H64m -Onot -fasm -I. -Iinclude -Rghc-timing -O 
>>> -fasm  -ignore-package Cabal -ignore-package filepath -I../libraries 
>>> -fglasgow-exts -no-recomp    -c Distribution/System.hs -o 
>>> Distribution/System.o  -ohi Distribution/System.hi
>>>
>>> ../libraries/Cabal/Distribution/System.hs:14:10:
>>>      Not in scope: `System.Info.os'
>>>
>>> This is on MacOS compiling with GHC 6.6.1.
>>>
>>> Duncan, did you run validate before pushing all these recent cabal 
>>> patches?
>>
>> Not that I am blaming people for breaking ghc head (since I did it too
>> recently with other Cabal patches) but I note that this particular bug
>> was committed by someone who does use validate on a regular basis. :-)
>> In this case, running validate would not have helped since the compile
>> error was conditional on #ifdef stuff that triggers on OSX (which I'm
>> fixing now...).
>>
>> I'm not sure what this teaches us.
> 
> We talked about that when initially discussing validate.  It would be 
> too cumbersome to absolutely require testing on multiple platforms 
> before a patch can be pushed.  However, the rule, as explained at
> 
>   http://hackage.haskell.org/trac/ghc/wiki/TestingPatches
> 
> "Depending on the nature of the changes, more testing might be sensible. 
> e.g. if possible, build system changes should be tested on Linux, Mac OS 
> X and Windows machines."
> 
> So, it is up to the developer to apply some common sense in judging 
> whether a patch my lead to issues on other platforms.  I guess the 
> message printed by a successful validate run could be a bit more precise 
> in that respect.
> 
> And thanks for fixing this!
> Manuel
>