date:20140720

Re: Planning a Haskell Platfrom Release Candidate this weekend

2014-07-20 Thread Mark Lentczner

Where I'm at:

*-- General --*
[x] haddock linkage from HP packages to GHC core packages is broken

*-- think I have this fixed checking in all contexts*

[x] decision on QuickCheck?

*-- staying with 2.6, because 2.7 added a dep on a package not in the
platform*



*-- Source Tarball --*
[x] missing platform.sh scripts
[x] missing os-extras in hptool/src

*-- both done*


*-- Mac --*
[x] start.html needs a once over updating

*-- done*

[-] uninstall-hs should clean out /usr/local/bin symlinks (as it does with
/usr/bin)

*   -- turns out it already was... long post on why it is hard to clean out
installations that are configured to install directly into common shared
directories (like /usr/local/bin and /usr/local/share/man)*

[?] activate-hs should add -P for clang pre-processing
*- bug found in Cabal*
*- adding -P for all preprocessing will suck*
*- no other good fix*
[-] ensuring that the MACOSX_DEPLOYMENT_TARGET=10.6 is set

*-- decided to defer this to later - just need to remember to do this
by hand before starting the build*


*-- Windows --*
[ ] GLUT issue in ghci

*-- no updates*


*-- Website --*
[ ] templatize info on pages
[ ] add build mode to bptool Main
- needs to take file of downloads & hashes

*-- this can all wait until after the RC*

The issue with pre-processing is a big one - and one not easily solvable.
It has already bit developers (bos posted about it recently), and it will
bite again.

I'm also feeling at a loss to actually test the Platform. Normally I do a
big system build, like Pandoc, or my own Plush to prove that a wider
variety of developer packages will compile with the platform. Alas, none of
those will compile with 7.8.3 and this platform. [for the curious: texmath
ends up in a compilation that never ends during the profiling lib build,
and Plush relies on warp, which puts it into it's own cabal hell...)

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

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

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

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


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

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

Re: Update Cabal submodule to HEAD (1.21)

2014-07-20 Thread 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.

Edward

Excerpts from Joachim Breitner's message of 2014-07-20 16:55:20 +0100:
> Hi,
> 
> Am Sonntag, den 20.07.2014, 16:58 +0200 schrieb Joachim Breitner:
> > > > 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?
> 
> So I got a working configuration. The following patch needs to be
> applied to Cabal:
> 
> diff --git a/Cabal/Distribution/Simple/Utils.hs 
> b/Cabal/Distribution/Simple/Utils.hs
> index 9096186..54df19d 100644
> --- a/Cabal/Distribution/Simple/Utils.hs
> +++ b/Cabal/Distribution/Simple/Utils.hs
> @@ -379,7 +379,12 @@ rawSystemExitWithEnv verbosity path args env = do
>  hFlush stdout
>  (_,_,_,ph) <- createProcess $
>(Process.proc path args) { Process.env = (Just env)
> -   , Process.delegate_ctlc = True }
> +#ifndef BOOTSTRAPPING
> +-- delegate_ctlc has been added in process 1.2, and we still want to be able 
> to build
> +-- bootstrap GHC on systems not having that version
> +   , Process.delegate_ctlc = True
> +#endif
> +   }
>  exitcode <- waitForProcess ph
>  unless (exitcode == ExitSuccess) $ do
>  debug verbosity $ path ++ " returned " ++ show exitcode
> @@ -405,7 +410,12 @@ rawSystemIOWithEnv verbosity path args mcwd menv inp out 
> err = do
> , Process.std_in= mbToStd 
> inp
> , Process.std_out   = mbToStd 
> out
> , Process.std_err   = mbToStd 
> err
> -   , Process.delegate_ctlc = True }
> +#ifndef BOOTSTRAPPING
> +-- delegate_ctlc has been added in process 1.2, and we still want to be able 
> to build
> +-- bootstrap GHC on systems not having that version
> +   , Process.delegate_ctlc = True
> +#endif
> +   }
>  exitcode <- waitForProcess ph
>  unless (exitcode == ExitSuccess) $ do
>debug verbosity $ path ++ " returned " ++ show exitcode
> 
> and this adjustment made to GHCs build system:
> 
> diff --git a/ghc.mk b/ghc.mk
> index e9d7e83..cfe46ec 100644
> --- a/ghc.mk
> +++ b/ghc.mk
> @@ -382,8 +382,10 @@ else
>  # Packages that are built by stage0. These packages are dependencies of
>  # programs such as GHC and ghc-pkg, that we do not assume the stage0
>  # compiler already has installed (or up-to-date enough).
> +# "process" can be removed once the version required by Cabal is not
> +# particularly new any more.
>  
> -PACKAGES_STAGE0 = Cabal/Cabal hpc bin-package-db hoopl transformers
> +PACKAGES_STAGE0 = process Cabal/Cabal hpc bin-package-db hoopl transformers
>  ifeq "$(Windows_Host)" "NO"
>  ifneq "$(HostOS_CPP)" "ios"
>  PACKAGES_STAGE0 += terminfo
> @@ -732,6 +734,11 @@ fixed_pkg_prev=
>  $(foreach pkg,$(PACKAGES_STAGE0),$(eval $(call 
> fixed_pkg_dep,$(pkg),dist-boot)))
>  utils/ghc-pkg/dist/package-data.mk: $(fixed_pkg_prev)
>  compiler/stage1/package-data.mk:$(fixed_pkg_prev)
> +
> +# we also need to configure hsc2hs after process has been configured, as
> +# BOOT_PKG_CONSTRAINTS will make hsc2hs want to use the in-tree process 
> library.
> +utils/hsc2hs/dist/package-data.mk : 
> libraries/process/dist-boot/package-data.mk
> +
>  endif
>  
>  ifneq "$(BINDIST)" "YES"
> 
> 
> 
> Now I’d like to apply this change, but I’m not sure how to proceed with
> such GHC-specific fixes to Cabal. I guess I could create a pull request,
> wait for the Cabal devs to apply it, wait for the next Cabal release,
> and then update the submodule. Is there anything quicker that gets the
> fix in until that has happened?
> 
> Greetings,
> Joachim
> 
___
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, 16:58 +0200 schrieb Joachim Breitner:
> > > 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?

So I got a working configuration. The following patch needs to be
applied to Cabal:

diff --git a/Cabal/Distribution/Simple/Utils.hs 
b/Cabal/Distribution/Simple/Utils.hs
index 9096186..54df19d 100644
--- a/Cabal/Distribution/Simple/Utils.hs
+++ b/Cabal/Distribution/Simple/Utils.hs
@@ -379,7 +379,12 @@ rawSystemExitWithEnv verbosity path args env = do
 hFlush stdout
 (_,_,_,ph) <- createProcess $
   (Process.proc path args) { Process.env = (Just env)
-   , Process.delegate_ctlc = True }
+#ifndef BOOTSTRAPPING
+-- delegate_ctlc has been added in process 1.2, and we still want to be able 
to build
+-- bootstrap GHC on systems not having that version
+   , Process.delegate_ctlc = True
+#endif
+   }
 exitcode <- waitForProcess ph
 unless (exitcode == ExitSuccess) $ do
 debug verbosity $ path ++ " returned " ++ show exitcode
@@ -405,7 +410,12 @@ rawSystemIOWithEnv verbosity path args mcwd menv inp out 
err = do
, Process.std_in= mbToStd 
inp
, Process.std_out   = mbToStd 
out
, Process.std_err   = mbToStd 
err
-   , Process.delegate_ctlc = True }
+#ifndef BOOTSTRAPPING
+-- delegate_ctlc has been added in process 1.2, and we still want to be able 
to build
+-- bootstrap GHC on systems not having that version
+   , Process.delegate_ctlc = True
+#endif
+   }
 exitcode <- waitForProcess ph
 unless (exitcode == ExitSuccess) $ do
   debug verbosity $ path ++ " returned " ++ show exitcode

and this adjustment made to GHCs build system:

diff --git a/ghc.mk b/ghc.mk
index e9d7e83..cfe46ec 100644
--- a/ghc.mk
+++ b/ghc.mk
@@ -382,8 +382,10 @@ else
 # Packages that are built by stage0. These packages are dependencies of
 # programs such as GHC and ghc-pkg, that we do not assume the stage0
 # compiler already has installed (or up-to-date enough).
+# "process" can be removed once the version required by Cabal is not
+# particularly new any more.
 
-PACKAGES_STAGE0 = Cabal/Cabal hpc bin-package-db hoopl transformers
+PACKAGES_STAGE0 = process Cabal/Cabal hpc bin-package-db hoopl transformers
 ifeq "$(Windows_Host)" "NO"
 ifneq "$(HostOS_CPP)" "ios"
 PACKAGES_STAGE0 += terminfo
@@ -732,6 +734,11 @@ fixed_pkg_prev=
 $(foreach pkg,$(PACKAGES_STAGE0),$(eval $(call 
fixed_pkg_dep,$(pkg),dist-boot)))
 utils/ghc-pkg/dist/package-data.mk: $(fixed_pkg_prev)
 compiler/stage1/package-data.mk:$(fixed_pkg_prev)
+
+# we also need to configure hsc2hs after process has been configured, as
+# BOOT_PKG_CONSTRAINTS will make hsc2hs want to use the in-tree process 
library.
+utils/hsc2hs/dist/package-data.mk : libraries/process/dist-boot/package-data.mk
+
 endif
 
 ifneq "$(BINDIST)" "YES"



Now I’d like to apply this change, but I’m not sure how to proceed with
such GHC-specific fixes to Cabal. I guess I could create a pull request,
wait for the Cabal devs to apply it, wait for the next Cabal release,
and then update the submodule. Is there anything quicker that gets the
fix in until that has happened?

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 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: Planning a Haskell Platfrom Release Candidate this weekend

Re: Update Cabal submodule to HEAD (1.21)

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

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

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

Re: Update Cabal submodule to HEAD (1.21)

Re: Update Cabal submodule to HEAD (1.21)

Re: Update Cabal submodule to HEAD (1.21)

Re: Update Cabal submodule to HEAD (1.21)

9 matches

Site Navigation

Mail list logo

Footer information