Gearing up for a 1.18 release

older
Cabal Hacking at ZuriHac 2013

Johan Tibell

6 Aug 2013 6 Aug '13

2:37 a.m.

Hi all, The sandbox functionality now works well enough that I think we should let it out in the wild. I've created a 1.18 release branch at https://github.com/haskell/cabal/tree/cabal-install-1.18 My intention is to make any necessary bug fixes on that branch before the release and then merge those fixes into master once the release is done (i.e. using a work flow similar to http://nvie.com/posts/a-successful-git-branching-model/ but without the develop branch). Are there any fixes that absolutely must make it in before a 1.18 release? Remember, this release is already long overdue and there will be more frequent releases in the future so lets not try to cram in some extra functionality and delay this release further. P.S. In the future I hope we can make a release every 3-6 months instead of the current almost yearly release cycle. Cheers, Johan

Show replies by date

Roman Cheplyaka

6 Aug 6 Aug

4:42 a.m.

Hi, May I ask you to include haskell suite support in this release? Haskell suite adds a new compiler flavor to Cabal, except it is not tied to any particular compiler. Hopefully, this may be the last compiler flavor added to Cabal. (related: https://github.com/haskell/cabal/issues/57) It is already used by the haskell suite interface generator. (See http://documentup.com/haskell-suite/haskell-names#module-interfaces/generati...) Here's the patch (on top of the cabal-install-1.18 branch): https://github.com/feuerbach/cabal/commit/ae2070b1fcb7b59998cbc251f5f1bf4519... I can also create a pull request if needed. I realize that including new code just before the release is usually not a good idea, but in this case it's very low-risk. It doesn't change the public Cabal API. All it does from the user's perspective is introducing a new switch (--haskell-suite), which shouldn't impact in any way users who don't use it. The only possible issue is during compilation. Speaking of which, I've verified that Cabal and cabal-install build with this patch using GHC 7.6.3 and 7.0.4. Cabal's policy is to support being built by versions of GHC that are up to 3 years old. That would be 6.12.3, released 12 June 2010. Cabal with the patch indeed builds on 6.12.3; however, cabal-install fails to configure: Warning: Falling back to topdown solver for GHC < 7. Resolving dependencies... cabal: cannot configure process-1.0.1.3. It requires directory ==1.0.* For the dependency on directory ==1.0.* there are these packages: directory-1.0.0.0, directory-1.0.0.3, directory-1.0.1.0, directory-1.0.1.1 and directory-1.0.1.2. However none of them are available. directory-1.0.0.0 was excluded because directory-1.2.0.1 was selected instead directory-1.0.0.0 was excluded because cabal-install-1.18.0 requires directory ==1.2.* directory-1.0.0.3 was excluded because directory-1.2.0.1 was selected instead directory-1.0.0.3 was excluded because cabal-install-1.18.0 requires directory ==1.2.* directory-1.0.1.0 was excluded because directory-1.2.0.1 was selected instead directory-1.0.1.0 was excluded because cabal-install-1.18.0 requires directory ==1.2.* directory-1.0.1.1 was excluded because directory-1.2.0.1 was selected instead directory-1.0.1.1 was excluded because cabal-install-1.18.0 requires directory ==1.2.* directory-1.0.1.2 was excluded because directory-1.2.0.1 was selected instead directory-1.0.1.2 was excluded because cabal-install-1.18.0 requires directory ==1.2.* Roman * Johan Tibell [2013-08-06 08:37:57+0200]

...

Hi all,

The sandbox functionality now works well enough that I think we should let it out in the wild. I've created a 1.18 release branch at

https://github.com/haskell/cabal/tree/cabal-install-1.18

My intention is to make any necessary bug fixes on that branch before the release and then merge those fixes into master once the release is done (i.e. using a work flow similar to http://nvie.com/posts/a-successful-git-branching-model/ but without the develop branch).

Are there any fixes that absolutely must make it in before a 1.18 release? Remember, this release is already long overdue and there will be more frequent releases in the future so lets not try to cram in some extra functionality and delay this release further.

P.S. In the future I hope we can make a release every 3-6 months instead of the current almost yearly release cycle.

Cheers, Johan

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Johan Tibell

7:46 a.m.

This is quite a big patch and the functionality isn't critical for most users. However, if someone feels strongly enough about having it in for 1.18 to review it and merge it within the next few days we could have it in. On Tue, Aug 6, 2013 at 10:42 AM, Roman Cheplyaka wrote:

...

Hi,

May I ask you to include haskell suite support in this release?

Haskell suite adds a new compiler flavor to Cabal, except it is not tied to any particular compiler. Hopefully, this may be the last compiler flavor added to Cabal. (related: https://github.com/haskell/cabal/issues/57)

It is already used by the haskell suite interface generator. (See http://documentup.com/haskell-suite/haskell-names#module-interfaces/generati...)

Here's the patch (on top of the cabal-install-1.18 branch): https://github.com/feuerbach/cabal/commit/ae2070b1fcb7b59998cbc251f5f1bf4519... I can also create a pull request if needed.

I realize that including new code just before the release is usually not a good idea, but in this case it's very low-risk. It doesn't change the public Cabal API. All it does from the user's perspective is introducing a new switch (--haskell-suite), which shouldn't impact in any way users who don't use it.

The only possible issue is during compilation. Speaking of which, I've verified that Cabal and cabal-install build with this patch using GHC 7.6.3 and 7.0.4.

Cabal's policy is to support being built by versions of GHC that are up to 3 years old. That would be 6.12.3, released 12 June 2010. Cabal with the patch indeed builds on 6.12.3; however, cabal-install fails to configure:

Warning: Falling back to topdown solver for GHC < 7. Resolving dependencies... cabal: cannot configure process-1.0.1.3. It requires directory ==1.0.* For the dependency on directory ==1.0.* there are these packages: directory-1.0.0.0, directory-1.0.0.3, directory-1.0.1.0, directory-1.0.1.1 and directory-1.0.1.2. However none of them are available. directory-1.0.0.0 was excluded because directory-1.2.0.1 was selected instead directory-1.0.0.0 was excluded because cabal-install-1.18.0 requires directory ==1.2.* directory-1.0.0.3 was excluded because directory-1.2.0.1 was selected instead directory-1.0.0.3 was excluded because cabal-install-1.18.0 requires directory ==1.2.* directory-1.0.1.0 was excluded because directory-1.2.0.1 was selected instead directory-1.0.1.0 was excluded because cabal-install-1.18.0 requires directory ==1.2.* directory-1.0.1.1 was excluded because directory-1.2.0.1 was selected instead directory-1.0.1.1 was excluded because cabal-install-1.18.0 requires directory ==1.2.* directory-1.0.1.2 was excluded because directory-1.2.0.1 was selected instead directory-1.0.1.2 was excluded because cabal-install-1.18.0 requires directory ==1.2.*

Roman

* Johan Tibell [2013-08-06 08:37:57+0200]

...
Hi all,

The sandbox functionality now works well enough that I think we should let it out in the wild. I've created a 1.18 release branch at

https://github.com/haskell/cabal/tree/cabal-install-1.18

My intention is to make any necessary bug fixes on that branch before the release and then merge those fixes into master once the release is done (i.e. using a work flow similar to http://nvie.com/posts/a-successful-git-branching-model/ but without the develop branch).

Are there any fixes that absolutely must make it in before a 1.18 release? Remember, this release is already long overdue and there will be more frequent releases in the future so lets not try to cram in some extra functionality and delay this release further.

P.S. In the future I hope we can make a release every 3-6 months instead of the current almost yearly release cycle.

Cheers, Johan

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Mikhail Glushenkov

8:52 a.m.

Hi Roman, On Tue, Aug 6, 2013 at 10:42 AM, Roman Cheplyaka wrote:

...

Cabal's policy is to support being built by versions of GHC that are up to 3 years old. That would be 6.12.3, released 12 June 2010. Cabal with the patch indeed builds on 6.12.3; however, cabal-install fails to configure:

Try building with -fold-directory. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Roman Cheplyaka

9:28 a.m.

* Mikhail Glushenkov [2013-08-06 14:52:52+0200]

...

Hi Roman,

On Tue, Aug 6, 2013 at 10:42 AM, Roman Cheplyaka wrote:

...
Cabal's policy is to support being built by versions of GHC that are up to 3 years old. That would be 6.12.3, released 12 June 2010. Cabal with the patch indeed builds on 6.12.3; however, cabal-install fails to configure:

Try building with -fold-directory.

Thanks, that did the trick. So the patch builds with 6.12.3, too. Roman

Johan Tibell

8 Aug 8 Aug

3:39 p.m.

I'd like to get this out before the end of my vacation, so in the next two weeks. Any objections to go with the current content of the master branch? On Tue, Aug 6, 2013 at 3:28 PM, Roman Cheplyaka wrote:

...

* Mikhail Glushenkov [2013-08-06 14:52:52+0200]

...
Hi Roman,

On Tue, Aug 6, 2013 at 10:42 AM, Roman Cheplyaka wrote:

...
Cabal's policy is to support being built by versions of GHC that are up to 3 years old. That would be 6.12.3, released 12 June 2010. Cabal with the patch indeed builds on 6.12.3; however, cabal-install fails to configure:

Try building with -fold-directory.

Thanks, that did the trick. So the patch builds with 6.12.3, too.

Roman

Mikhail Glushenkov

9 Aug 9 Aug

5:05 a.m.

Hi Johan, On Thu, Aug 8, 2013 at 9:39 PM, Johan Tibell wrote:

...

I'd like to get this out before the end of my vacation, so in the next two weeks. Any objections to go with the current content of the master branch?

I'd also like to see #1404 ("cabal repl") included in 1.18. It needs a bit more testing with sandboxes, which I'll do in the next few days. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Johan Tibell

3:50 p.m.

OK. Sounds good to me. On Fri, Aug 9, 2013 at 11:05 AM, Mikhail Glushenkov wrote:

...

Hi Johan,

On Thu, Aug 8, 2013 at 9:39 PM, Johan Tibell wrote:

...
I'd like to get this out before the end of my vacation, so in the next two weeks. Any objections to go with the current content of the master branch?

I'd also like to see #1404 ("cabal repl") included in 1.18. It needs a bit more testing with sandboxes, which I'll do in the next few days.

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Carter Schonwald

10 Aug 10 Aug

9:16 p.m.

this is great! Also: REALLY important, because 1.18/1.17 has the right hooks to make sure ghc 7.6 on macs works correctly with the xcode 5 CLI tools, and having 1.18 out will make it very very very easy to walk people through the fix needed to use ghc with clang correctly. On Fri, Aug 9, 2013 at 3:50 PM, Johan Tibell wrote:

...

OK. Sounds good to me.

On Fri, Aug 9, 2013 at 11:05 AM, Mikhail Glushenkov wrote:

...
Hi Johan,

On Thu, Aug 8, 2013 at 9:39 PM, Johan Tibell wrote:

...
I'd like to get this out before the end of my vacation, so in the next two weeks. Any objections to go with the current content of the master branch?

I'd also like to see #1404 ("cabal repl") included in 1.18. It needs a bit more testing with sandboxes, which I'll do in the next few days.

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Mikhail Glushenkov

14 Aug 14 Aug

7:31 p.m.

Hi Johan, On Tue, Aug 6, 2013 at 8:37 AM, Johan Tibell wrote:

...

Are there any fixes that absolutely must make it in before a 1.18 release? Remember, this release is already long overdue and there will be more frequent releases in the future so lets not try to cram in some extra functionality and delay this release further.

One other thing I just remembered: apparently the cross-compilation patches broke a lot of custom Setup.hs scripts (see https://github.com/haskell/cabal/pull/1214#issuecomment-21845325 ). I'll prepare a patch. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Johan Tibell

19 Aug 19 Aug

5:02 p.m.

What's the status of this? On Thu, Aug 15, 2013 at 12:31 AM, Mikhail Glushenkov wrote:

...

Hi Johan,

On Tue, Aug 6, 2013 at 8:37 AM, Johan Tibell wrote:

...
Are there any fixes that absolutely must make it in before a 1.18 release? Remember, this release is already long overdue and there will be more frequent releases in the future so lets not try to cram in some extra functionality and delay this release further.

One other thing I just remembered: apparently the cross-compilation patches broke a lot of custom Setup.hs scripts (see https://github.com/haskell/cabal/pull/1214#issuecomment-21845325 ). I'll prepare a patch.

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Mikhail Glushenkov

20 Aug 20 Aug

4:26 a.m.

Hi Johan, On Mon, Aug 19, 2013 at 11:02 PM, Johan Tibell wrote:

...

What's the status of this?

'cabal repl' seems to work fine with sandboxes. The backwards compat patch for #1214 is not yet done (I'm on it). Other than that, the documentation update is the only thing left to do. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Herbert Valerio Riedel

6:11 a.m.

On 2013-08-20 at 10:26:07 +0200, Mikhail Glushenkov wrote:

...

On Mon, Aug 19, 2013 at 11:02 PM, Johan Tibell wrote:

...
What's the status of this?

'cabal repl' seems to work fine with sandboxes. The backwards compat patch for #1214 is not yet done (I'm on it). Other than that, the documentation update is the only thing left to do.

Fwiw, I've been using haskell-mode with "cabal repl" successfully myself, and I've pushed preliminary "cabal repl" support to the public Github repo recently[1]; I've also added a workaround to be able to use ghci-ng w/ "cabal repl"[2]. So I really hope "cabal repl" gets released as part of 1.18.0, as it's already working quite nicely and IMHO represents a big improvement over cabal-dev in its current state. [1]: https://github.com/haskell/haskell-mode/issues/195 [2]: https://github.com/hvr/ghci-ng/commit/941fa170ba92c82b08d52672075cfa36184bc0... cheers, hvr

Carter Schonwald

4:37 p.m.

relatedly: has Luite's patches been added yet? (are those the cross compilation patches you're talking about?) On Tue, Aug 20, 2013 at 6:11 AM, Herbert Valerio Riedel wrote:

...

On 2013-08-20 at 10:26:07 +0200, Mikhail Glushenkov wrote:

...
On Mon, Aug 19, 2013 at 11:02 PM, Johan Tibell wrote:

...
What's the status of this?

'cabal repl' seems to work fine with sandboxes. The backwards compat patch for #1214 is not yet done (I'm on it). Other than that, the documentation update is the only thing left to do.

Fwiw, I've been using haskell-mode with "cabal repl" successfully myself, and I've pushed preliminary "cabal repl" support to the public Github repo recently[1]; I've also added a workaround to be able to use ghci-ng w/ "cabal repl"[2]. So I really hope "cabal repl" gets released as part of 1.18.0, as it's already working quite nicely and IMHO represents a big improvement over cabal-dev in its current state.

[1]: https://github.com/haskell/haskell-mode/issues/195 [2]: https://github.com/hvr/ghci-ng/commit/941fa170ba92c82b08d52672075cfa36184bc0...

cheers, hvr

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Johan Tibell

21 Aug 21 Aug

7 a.m.

Another reason we need this out soon is that we want Cabal 1.18 to ship with the next GHC, which I believe will be released after ICFP. On Tue, Aug 20, 2013 at 9:37 PM, Carter Schonwald wrote:

...

relatedly: has Luite's patches been added yet? (are those the cross compilation patches you're talking about?)

On Tue, Aug 20, 2013 at 6:11 AM, Herbert Valerio Riedel wrote:

...
On 2013-08-20 at 10:26:07 +0200, Mikhail Glushenkov wrote:

...
On Mon, Aug 19, 2013 at 11:02 PM, Johan Tibell wrote:

...
What's the status of this?

'cabal repl' seems to work fine with sandboxes. The backwards compat patch for #1214 is not yet done (I'm on it). Other than that, the documentation update is the only thing left to do.

Fwiw, I've been using haskell-mode with "cabal repl" successfully myself, and I've pushed preliminary "cabal repl" support to the public Github repo recently[1]; I've also added a workaround to be able to use ghci-ng w/ "cabal repl"[2]. So I really hope "cabal repl" gets released as part of 1.18.0, as it's already working quite nicely and IMHO represents a big improvement over cabal-dev in its current state.

[1]: https://github.com/haskell/haskell-mode/issues/195 [2]: https://github.com/hvr/ghci-ng/commit/941fa170ba92c82b08d52672075cfa36184bc0...

cheers, hvr

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Mikhail Glushenkov

23 Aug 23 Aug

6:04 a.m.

Hi Johan, On Tue, Aug 20, 2013 at 10:26 AM, Mikhail Glushenkov wrote:

...

Hi Johan,

On Mon, Aug 19, 2013 at 11:02 PM, Johan Tibell wrote:

...
What's the status of this?

Fixes for the two remaining release blockers: https://github.com/haskell/cabal/pull/1430 https://github.com/haskell/cabal/pull/1429 I also wrote a changelog: https://github.com/23Skidoo/homepage/blob/master/content/blog/2013-08-21-Cab... http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Johan Tibell

6:51 a.m.

Great, if no one protests, I'll try to get out an initial RC for people to test today or tomorrow. On Fri, Aug 23, 2013 at 7:34 AM, Mikhail Glushenkov wrote:

...

Hi Johan,

On Tue, Aug 20, 2013 at 10:26 AM, Mikhail Glushenkov wrote:

...
Hi Johan,

On Mon, Aug 19, 2013 at 11:02 PM, Johan Tibell wrote:

...
What's the status of this?

Fixes for the two remaining release blockers:

https://github.com/haskell/cabal/pull/1430 https://github.com/haskell/cabal/pull/1429

I also wrote a changelog:

https://github.com/23Skidoo/homepage/blob/master/content/blog/2013-08-21-Cab... http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Carter Schonwald

12:50 p.m.

Does this include the API changes luite needs? If not, could you give him a wee bit of time needed to get the patch your way? On Friday, August 23, 2013, Johan Tibell wrote:

...

Great, if no one protests, I'll try to get out an initial RC for people to test today or tomorrow.

On Fri, Aug 23, 2013 at 7:34 AM, Mikhail Glushenkov javascript:;> wrote:

...
Hi Johan,

On Tue, Aug 20, 2013 at 10:26 AM, Mikhail Glushenkov javascript:;> wrote:

...
Hi Johan,

On Mon, Aug 19, 2013 at 11:02 PM, Johan Tibell javascript:;> wrote:

...
What's the status of this?

Fixes for the two remaining release blockers:

https://github.com/haskell/cabal/pull/1430 https://github.com/haskell/cabal/pull/1429

I also wrote a changelog:

https://github.com/23Skidoo/homepage/blob/master/content/blog/2013-08-21-Cab...

...
http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/cabal-devel

Carter Schonwald

11:08 p.m.

Just so you guy's know, Luite should have a patch ready for consideration very soon. (just spoke with him) I hope you consider it for the 1.18 release! On Fri, Aug 23, 2013 at 12:50 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

Does this include the API changes luite needs?

If not, could you give him a wee bit of time needed to get the patch your way?

On Friday, August 23, 2013, Johan Tibell wrote:

...
Great, if no one protests, I'll try to get out an initial RC for people to test today or tomorrow.

On Fri, Aug 23, 2013 at 7:34 AM, Mikhail Glushenkov wrote:

...
Hi Johan,

On Tue, Aug 20, 2013 at 10:26 AM, Mikhail Glushenkov wrote:

...
Hi Johan,

On Mon, Aug 19, 2013 at 11:02 PM, Johan Tibell wrote:

...
What's the status of this?

Fixes for the two remaining release blockers:

https://github.com/haskell/cabal/pull/1430 https://github.com/haskell/cabal/pull/1429

I also wrote a changelog:

https://github.com/23Skidoo/homepage/blob/master/content/blog/2013-08-21-Cab...

...
http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Luite Stegeman

24 Aug 24 Aug

12:55 a.m.

On Sat, Aug 24, 2013 at 5:08 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

Just so you guy's know, Luite should have a patch ready for consideration very soon. (just spoke with him)

Yes, I've updated the patch [1], but I still have a problem loading dynlibs for TH in some cases. I don't think it's related to Cabal (which appears to be running all the right commands), but I can't completely rule it out either. luite [1] https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d...

Luite Stegeman

25 Aug 25 Aug

4:50 a.m.

...

Yes, I've updated the patch [1], but I still have a problem loading dynlibs for TH in some cases. I don't think it's related to Cabal (which appears to be running all the right commands), but I can't completely rule it out either.

The Cabal patch was fine indeed. It was a problem with the internal names of some GHCJS dynlibs, so the system linker did not always pick up dependencies correctly. luite

Johan Tibell

12:23 p.m.

I still think we shouldn't change the CompilerId type. You gave this motivation for changing it in another thread:

...

It's not so much an implementation detail of GHCJS itself, but more a side effect of many people using impl(ghc) flags in their packages to check whether the compiler supports some particular feature. We could leave it out, but then many packages would have to be updated to duplicate the impl check (or replace it)

I think we should definitely fix the packages, not put a hack in Cabal. On Sat, Aug 24, 2013 at 2:25 AM, Luite Stegeman wrote:

...

On Sat, Aug 24, 2013 at 5:08 AM, Carter Schonwald wrote:

...
Just so you guy's know, Luite should have a patch ready for consideration very soon. (just spoke with him)

Yes, I've updated the patch [1], but I still have a problem loading dynlibs for TH in some cases. I don't think it's related to Cabal (which appears to be running all the right commands), but I can't completely rule it out either.

luite

[1] https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d...

Luite Stegeman

12:53 p.m.

...

I think we should definitely fix the packages, not put a hack in Cabal.

In the latest hackage archive, there are 462 packages that use the impl(ghc) flag, including lots of very common packages. For example binary: if impl(ghc >= 7.2.1) cpp-options: -DGENERICS other-modules: Data.Binary.Generic if impl(ghc <= 7.6) -- prior to ghc-7.4 generics lived in ghc-prim build-depends: ghc-prim Is there a generic way to do this without impl ghc checks? Otherwise all these impl(ghc >= x) flag checks have to be changed to impl(ghc >= x) || impl(ghcjs >= y), not something I'd be looking forward to... Also I personally don't really see it as a hack (of course I'm biased since I've been using it for a while). It just allows you to specify that "compiler x is based on compiler y", so that unless explicitly queried otherwise you can assume that flags for 'y' hold for 'x'. luite

Dag Odenhall

26 Aug 26 Aug

6:09 a.m.

I definitely think impl(ghc) should cover GHCJS, as it effectively just is a GHC backend (even if not part of GHC). Doing otherwise would be a bit like having impl(ghc) be false when compiling with -fllvm IMHO. The value of GHCJS is that it's supposed to be able to compile most existing packages as-is. Just my two cents. :-) On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman wrote:

...

I think we should definitely fix the packages, not put a hack in Cabal.

In the latest hackage archive, there are 462 packages that use the impl(ghc) flag, including lots of very common packages. For example binary:

if impl(ghc >= 7.2.1) cpp-options: -DGENERICS other-modules: Data.Binary.Generic if impl(ghc <= 7.6) -- prior to ghc-7.4 generics lived in ghc-prim build-depends: ghc-prim

Is there a generic way to do this without impl ghc checks? Otherwise all these impl(ghc >= x) flag checks have to be changed to impl(ghc >= x) || impl(ghcjs >= y), not something I'd be looking forward to...

Also I personally don't really see it as a hack (of course I'm biased since I've been using it for a while). It just allows you to specify that "compiler x is based on compiler y", so that unless explicitly queried otherwise you can assume that flags for 'y' hold for 'x'.

luite

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Johan Tibell

9:39 a.m.

Lets change the implementation of `impl` itself then to have ghc == ghcjs = True. This way the special casing is at least localized and not all users of the CompilerId data type need to care. Are there any other such checks that need to be adjusted? On Mon, Aug 26, 2013 at 7:39 AM, Dag Odenhall wrote:

...

I definitely think impl(ghc) should cover GHCJS, as it effectively just is a GHC backend (even if not part of GHC). Doing otherwise would be a bit like having impl(ghc) be false when compiling with -fllvm IMHO. The value of GHCJS is that it's supposed to be able to compile most existing packages as-is.

Just my two cents. :-)

On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman wrote:

...
...
I think we should definitely fix the packages, not put a hack in Cabal.

In the latest hackage archive, there are 462 packages that use the impl(ghc) flag, including lots of very common packages. For example binary:

if impl(ghc >= 7.2.1) cpp-options: -DGENERICS other-modules: Data.Binary.Generic if impl(ghc <= 7.6) -- prior to ghc-7.4 generics lived in ghc-prim build-depends: ghc-prim

Is there a generic way to do this without impl ghc checks? Otherwise all these impl(ghc >= x) flag checks have to be changed to impl(ghc >= x) || impl(ghcjs >= y), not something I'd be looking forward to...

Also I personally don't really see it as a hack (of course I'm biased since I've been using it for a while). It just allows you to specify that "compiler x is based on compiler y", so that unless explicitly queried otherwise you can assume that flags for 'y' hold for 'x'.

luite

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Luite Stegeman

11:30 a.m.

To be honest I think that's a much bigger hack than what I originally proposed. The point of the sub/super compiler CompilerId change is that both parts can have their own version range. For example GHCJS is currently at version 0.1.0, GHC at 7.6. While currently GHCJS can only be built against HEAD, that could change in the future (we used to have a version compatible with both 7.4 and 7.6), and one could want checks like this: impl(ghcjs >= 0.1) && impl(ghc < 7.10) I think this could also come in handy with Roman's haskell-suite compiler flavour, which makes it easy to make customized compilers. If you make something based on GHC it would be useful to be able to specify that, so you can support packages that depend on impl(ghc) checks. With this CompilerId change, that can be implemented for the HaskellSuite flavour by just giving the user a way to specify the compiler name/version. If there's a way to achieve this without changing CompilerId, that would be great. As for the CompilerId change itself: There are 11 packages on hackage that appear to use the CompilerId constructor (archlinux, cab, cabal-debian, cabal-db, cabal2nix, cabal-ghci, cabal-install-bundle, cblrepo, ghc-mod, hackport, hoogle) I'd be happy to send all of them a pull req. For other projects (not on hackage), I think that with some comments/Haddock the CompilerId type they can be quickly guided towards the right change (usually ignoring the field or adding Nothing) luite On Mon, Aug 26, 2013 at 3:39 PM, Johan Tibell wrote:

...

Lets change the implementation of `impl` itself then to have ghc == ghcjs = True. This way the special casing is at least localized and not all users of the CompilerId data type need to care. Are there any other such checks that need to be adjusted?

...
I definitely think impl(ghc) should cover GHCJS, as it effectively just is a GHC backend (even if not part of GHC). Doing otherwise would be a bit

...
having impl(ghc) be false when compiling with -fllvm IMHO. The value of GHCJS is that it's supposed to be able to compile most existing packages as-is.

Just my two cents. :-)

On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman wrote:

...
...
I think we should definitely fix the packages, not put a hack in Cabal.

In the latest hackage archive, there are 462 packages that use the impl(ghc) flag, including lots of very common packages. For example

binary:

...
if impl(ghc >= 7.2.1) cpp-options: -DGENERICS other-modules: Data.Binary.Generic if impl(ghc <= 7.6) -- prior to ghc-7.4 generics lived in ghc-prim build-depends: ghc-prim

Is there a generic way to do this without impl ghc checks? Otherwise all these impl(ghc >= x) flag checks have to be changed to impl(ghc >= x) || impl(ghcjs >= y), not something I'd be looking forward to...

Also I personally don't really see it as a hack (of course I'm biased since I've been using it for a while). It just allows you to specify

On Mon, Aug 26, 2013 at 7:39 AM, Dag Odenhall wrote: like that

...
...
"compiler x is based on compiler y", so that unless explicitly queried otherwise you can assume that flags for 'y' hold for 'x'.

luite

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Johan Tibell

12:06 p.m.

I'd like for Duncan to comment on this.

...

If there's a way to achieve this without changing CompilerId, that would be great. As for the CompilerId change itself:

There are 11 packages on hackage that appear to use the CompilerId constructor (archlinux, cab, cabal-debian, cabal-db, cabal2nix, cabal-ghci, cabal-install-bundle, cblrepo, ghc-mod, hackport, hoogle)

I'm not worried about these packages, but about the Cabal code base itself. On Mon, Aug 26, 2013 at 1:00 PM, Luite Stegeman wrote:

...

To be honest I think that's a much bigger hack than what I originally proposed. The point of the sub/super compiler CompilerId change is that both parts can have their own version range. For example GHCJS is currently at version 0.1.0, GHC at 7.6. While currently GHCJS can only be built against HEAD, that could change in the future (we used to have a version compatible with both 7.4 and 7.6), and one could want checks like this:

impl(ghcjs >= 0.1) && impl(ghc < 7.10)

I think this could also come in handy with Roman's haskell-suite compiler flavour, which makes it easy to make customized compilers. If you make something based on GHC it would be useful to be able to specify that, so you can support packages that depend on impl(ghc) checks. With this CompilerId change, that can be implemented for the HaskellSuite flavour by just giving the user a way to specify the compiler name/version.

If there's a way to achieve this without changing CompilerId, that would be great. As for the CompilerId change itself:

There are 11 packages on hackage that appear to use the CompilerId constructor (archlinux, cab, cabal-debian, cabal-db, cabal2nix, cabal-ghci, cabal-install-bundle, cblrepo, ghc-mod, hackport, hoogle)

I'd be happy to send all of them a pull req. For other projects (not on hackage), I think that with some comments/Haddock the CompilerId type they can be quickly guided towards the right change (usually ignoring the field or adding Nothing)

luite

On Mon, Aug 26, 2013 at 3:39 PM, Johan Tibell wrote:

...
Lets change the implementation of `impl` itself then to have ghc == ghcjs = True. This way the special casing is at least localized and not all users of the CompilerId data type need to care. Are there any other such checks that need to be adjusted?

On Mon, Aug 26, 2013 at 7:39 AM, Dag Odenhall wrote:

...
I definitely think impl(ghc) should cover GHCJS, as it effectively just is a GHC backend (even if not part of GHC). Doing otherwise would be a bit like having impl(ghc) be false when compiling with -fllvm IMHO. The value of GHCJS is that it's supposed to be able to compile most existing packages as-is.

Just my two cents. :-)

On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman wrote:

...
...
I think we should definitely fix the packages, not put a hack in Cabal.

In the latest hackage archive, there are 462 packages that use the impl(ghc) flag, including lots of very common packages. For example binary:

if impl(ghc >= 7.2.1) cpp-options: -DGENERICS other-modules: Data.Binary.Generic if impl(ghc <= 7.6) -- prior to ghc-7.4 generics lived in ghc-prim build-depends: ghc-prim

Is there a generic way to do this without impl ghc checks? Otherwise all these impl(ghc >= x) flag checks have to be changed to impl(ghc >= x) || impl(ghcjs >= y), not something I'd be looking forward to...

Also I personally don't really see it as a hack (of course I'm biased since I've been using it for a while). It just allows you to specify that "compiler x is based on compiler y", so that unless explicitly queried otherwise you can assume that flags for 'y' hold for 'x'.

luite

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Luite Stegeman

12:57 p.m.

...

I'm not worried about these packages, but about the Cabal code base itself.

The Cabal code base hardly creates CompilerId directly, in almost all cases the change is ignoring the third field. This is where CompilerId is created: All existing flavours add Nothing, 6x one-line change: - https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d... Distribution.PackageDescription.Check uses it, but only for checking that the base range is bounded, not with a real compiler, but with buildCompiler with no version: - https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d... buildCompilerId uses it (buildCompilerId is never used in Cabal, cabal-install and hackage), a better change would be to find the subcompiler if buildCompilerFlavor is GHCJS, but just adding Nothing makes it do the right thing for all existing compilers: - https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d... The other changes are the direct intended changes: Updated flag resolution, parsing/printing CompilerId, and getting the shared library filename from a CompilerId

4289

Age (days ago)

4309

Last active (days ago)

List overview

Download

27 comments

7 participants

participants (7)

Carter Schonwald
Dag Odenhall
Herbert Valerio Riedel
Johan Tibell
Luite Stegeman
Mikhail Glushenkov
Roman Cheplyaka