Re: Update Cabal submodule to HEAD (1.21)

2014-07-20 Thread Joachim Breitner
Hi,


Am Samstag, den 19.07.2014, 16:48 +0200 schrieb Joachim Breitner:
 Am Samstag, den 19.07.2014, 01:14 +0100 schrieb Edward Z.Yang:
  The reason for this is that the builders do not have a sufficiently
  recent version of process, which Cabal has upgraded to depend on.
  Probably 'cabal update  cabal install process' should bring it up to
  date and make it working.  Unfortunately, the build system bypasses
  Cabal for the bootstrap build of Cabal, so the version dependency range
  is not checked. 
 
 didn’t seem to help just like that.
 https://api.travis-ci.org/jobs/30346178/log.txt?deansi=true
 
 Probably because of -no-user-package-db. Trying with cabal install
 --global now.

I did this on the builder machines, but now I noticed that I’d also like
to build this on my own machine, and using cabal to do system wide
installations is not really the recomended way. And people wanting to
hack on GHC that do not have root access have to jump through even more
hoops (such as making a user installation of GHC).

It would also break building Distribution packages (and already does so
on) http://deb.haskell.org/dailies/

Is there an easy way out here? 

  I suppose if you /really/ wanted to we could add a
  macro to disable ctl-c support and pass it on the zeroboot.
 
I tried that (there is already a macro BOOTSTRAPPING), and then it does
build inplace/bin/ghc-cabal.

But the next thing it tries to do is to build Cabal, which then fails,
expecting the newer process.

So process needs to be added to PACKAGES_STAGE0. But this adds
--constriant process == 1.2.0.0 to the options when building hsc2hs,
which then fails – but only with make -j2. In a sequential build,
process happens to be built before hsc2hs

So I guess I need to tell make somehow to first configure and register
process and then configure and register hsc2hs. But I’m lost in GHC’s
makefiles... Can anyone point me into the right direction?

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Update Cabal submodule to HEAD (1.21)

2014-07-20 Thread Joachim Breitner
Hi,


Am Sonntag, den 20.07.2014, 17:08 +0100 schrieb Edward Z.Yang:
 As long as we get Cabal to do a release before we cut a release,
 it should be fine, so all we need is for Cabal to take the patch.

Nevermind, I noticed you updated the submodule to Cabal HEAD, not Cabal
some-release.


But anyways...

 Excerpts from Joachim Breitner's message of 2014-07-20 16:55:20 +0100:
  Am Sonntag, den 20.07.2014, 16:58 +0200 schrieb Joachim Breitner:
  So I got a working configuration. The following patch needs to be
  applied to Cabal:
  
  [..]
  
  and this adjustment made to GHCs build system:
  
  [..]

doesn’t quite work. It finishes phase 0, but phase 1 says
make[1]: *** No rule to make target 
'libraries/process/dist-boot/build/System/Process.hi', needed by 
'utils/hsc2hs/dist/build/Common.o'.  Schluss.
and I’m stuck. Can someone help me here?

Thanks,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


The haddock / clang problem revisited ... root cause found...

2014-07-20 Thread Mark Lentczner
tl;dr:

   - cabal is the culprit
   - If you have the `Extensions: CPP` directive in your .cabal file, then
   when invoking haddock, cabal causes every file to be pre-processed twice in
   sequence.
   - pre-processing isn't idempotent
   - when done under clang, it outputs things that ghc.


longer:

Regarding the ellusive problem whereby haddock for some packages fails on
ghc-7.8.3 / haddock-2.14.2 systems with clang (as in OS X 10.9):

Bugs were filed for both haddock and cabal:

https://github.com/haskell/haddock/issues/284
https://github.com/haskell/cabal/issues/1740

I've been trying to find a work-around before releasing the platform for OS
X. In sleuthing this I found the root cause: cabal.

Full details here: Root cause of haddock / clang failure
https://gist.github.com/mzero/d4ba11c567977111749a

The correct fix is to change cabal's behavior: Either don't pre-process the
fils for Haddock, or don't pass --optghc=-XCPP

There is no good work around: We could add -optP-P to all compilations, but
that breaks line numbers for everything. We could wrap haddock to remove
the --optghc=-XCPP, but that will break hand invocations of haddock.

- Mark
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Fatal git error on .git/modules/libffi-tarballs

2014-07-20 Thread Karel Gardas


Hello,

while working on HEAD and after a few iteraction of ./validate my git 
complains with:


$ git status
fatal: Not a git repository: 
/export/home/karel/vcs/ghc-src/ghc-git-test-2/.git/modules/libffi-tarballs

karel@silence:~/vcs/ghc-src/ghc-solaris-validate-fix$

Is this a known error or is there any known workaround for this issue?

Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Fatal git error on .git/modules/libffi-tarballs

2014-07-20 Thread Edward Z . Yang
Hello Karel,

You should blow away your copy (well, preserve the patches), upgrade
your version of Git and then check out again.  You've run into
this bug:

http://comments.gmane.org/gmane.comp.version-control.git/193492

Cheers,
Edward

Excerpts from Karel Gardas's message of 2014-07-20 18:55:08 +0100:
 
 Hello,
 
 while working on HEAD and after a few iteraction of ./validate my git 
 complains with:
 
 $ git status
 fatal: Not a git repository: 
 /export/home/karel/vcs/ghc-src/ghc-git-test-2/.git/modules/libffi-tarballs
 karel@silence:~/vcs/ghc-src/ghc-solaris-validate-fix$
 
 Is this a known error or is there any known workaround for this issue?
 
 Thanks!
 Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Update Cabal submodule to HEAD (1.21)

2014-07-20 Thread Edward Z . Yang
Since this patch causes GHC HEAD to not bootstrap out of the box
from GHC 7.6, I've reverted it for now.  We'll have to cross
this bridge sometime though.

Edward

Excerpts from Joachim Breitner's message of 2014-07-20 17:18:56 +0100:
 Hi,
 
 Am Sonntag, den 20.07.2014, 17:08 +0100 schrieb Edward Z.Yang:
  As long as we get Cabal to do a release before we cut a release,
  it should be fine, so all we need is for Cabal to take the patch.
 
 Nevermind, I noticed you updated the submodule to Cabal HEAD, not Cabal
 some-release.
 
 
 But anyways...
 
  Excerpts from Joachim Breitner's message of 2014-07-20 16:55:20 +0100:
   Am Sonntag, den 20.07.2014, 16:58 +0200 schrieb Joachim Breitner:
   So I got a working configuration. The following patch needs to be
   applied to Cabal:
   
   [..]
   
   and this adjustment made to GHCs build system:
   
   [..]
 
 doesn’t quite work. It finishes phase 0, but phase 1 says
 make[1]: *** No rule to make target 
 'libraries/process/dist-boot/build/System/Process.hi', needed by 
 'utils/hsc2hs/dist/build/Common.o'.  Schluss.
 and I’m stuck. Can someone help me here?
 
 Thanks,
 Joachim
 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs