DPH-setting in mk/build.mk (was: HEADS-UP: Git submodule conversion imminent)

On 2014-06-30 at 08:45:57 +0200, Jan Stolarek wrote: Herbert, all, I just pulled the new HEAD and have a question which I believe was not addressed so far. In my work on the GHC tree I never pulled the dph subrepo because the only thing it adds for me is extra build time (of course I

Re: DPH-setting in mk/build.mk (was: HEADS-UP: Git submodule conversion imminent)

It may be worth considering setting BUILD_DPH=NO in some of the quick-build templates in mk/build.mk, but I didn't want to change anything w/o discussion here first. +1 from me. I see this change as being beginner-friendly - most newcomers probably don't need DPH. Janek

RE: DPH-setting in mk/build.mk (was: HEADS-UP: Git submodule conversion imminent)

: ghc-devs@haskell.org | Subject: DPH-setting in mk/build.mk (was: HEADS-UP: Git submodule | conversion imminent) | | On 2014-06-30 at 08:45:57 +0200, Jan Stolarek wrote: | Herbert, all, | | I just pulled the new HEAD and have a question which I believe was not | addressed so far. In my work

Re: HEADS-UP: Git submodule conversion imminent

Herbert, all, I just pulled the new HEAD and have a question which I believe was not addressed so far. In my work on the GHC tree I never pulled the dph subrepo because the only thing it adds for me is extra build time (of course I pull it for my validation tree because I have no choice).

Re: HEADS-UP: Git submodule conversion imminent

Hi herbert, I followed your instructions, and one of my repos converted well: e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm (stm-2.4.3-release-3-ge8a901f) the other gave: -e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm How can I salvage the situation? Thanks, Gabor On

Re: HEADS-UP: Git submodule conversion imminent

On 2014-06-28 at 13:49:15 +0200, Gabor Greif wrote: Hi herbert, I followed your instructions, and one of my repos converted well: e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm (stm-2.4.3-release-3-ge8a901f) the other gave: -e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm

Re: HEADS-UP: Git submodule conversion imminent

Hmm, I guess this was the reason, when I did that, I got fatal: Needed a single revision Unable to find current revision in submodule path 'libraries/parallel' so the other submodules were not initialized. What might be wrong with 'libraries/parallel' ? Thanks, Gabor On 6/28/14,

Re: HEADS-UP: Git submodule conversion imminent

On 2014-06-28 at 14:19:15 +0200, Gabor Greif wrote: Hmm, I guess this was the reason, when I did that, I got fatal: Needed a single revision Unable to find current revision in submodule path 'libraries/parallel' so the other submodules were not initialized. What might be wrong with

Re: HEADS-UP: Git submodule conversion imminent

Should be fixed in 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177. On Thu, Jun 26, 2014 at 8:07 AM, Johan Tibell johan.tib...@gmail.com wrote: As a very temporary (and wrong) workaround you can edit libraries/ghc-prim/cbits/atomic.c to have the functions involving nand all return 0. I should have

Re: HEADS-UP: Git submodule conversion imminent

Johan, Should be fixed in 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177. Thanks. validate is finished with new settings on Mac. :-) --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

RE: HEADS-UP: Git submodule conversion imminent

...@haskell.org] On Behalf Of Herbert | Valerio Riedel | Sent: 25 June 2014 08:47 | To: ghc-devs | Subject: HEADS-UP: Git submodule conversion imminent | | Hello GHC Devs! | | In order to not drag this out any longer, I'll completing the submodule | conversion in the next few hours by converting

RE: HEADS-UP: Git submodule conversion imminent

| - if I have a tree with a bunch of as-yet-unpushed commits, what do I | do? | | If you have as-yet-unpushed commits in ghc.git, there shouldn't be | anything special to handle. Or were you referring to the case of having | unpushed commits in the converted sub-repos? I meant mainly in

HEADS-UP: Git submodule conversion imminent

Hello GHC Devs! In order to not drag this out any longer, I'll completing the submodule conversion in the next few hours by converting the remaining sub-repo packages into proper submodules. This is represents phase 1 of the reorganization (phase 2 comprises officially transitioning the

Re: HEADS-UP: Git submodule conversion imminent

It's done! After pulling the latest ghc.git commit (and assuming you have made sure you have no unpushed data laying around in the repos listed below) you'll have to either run - git submodule update --init *or* - ./sync-all get (a mere ./sync-all pull will just call git submodule

Re: HEADS-UP: Git submodule conversion imminent

Thank you Geoff On 6/25/14, 4:46 AM, Herbert Valerio Riedel wrote: It's done! After pulling the latest ghc.git commit (and assuming you have made sure you have no unpushed data laying around in the repos listed below) you'll have to either run - git submodule update --init *or*

Re: HEADS-UP: Git submodule conversion imminent

Herbert, It's done! Thanks. I tried to build GHC HEAD on Mac. I did: % git clone git://git.haskell.org/ghc.git % cd ghc % ./sync-all get % CPUS=10 sh validate Unfortunately, I got the following errors: inplace/bin/ghc-stage1 -optc-m64