developing against privately patched libraries, and cabal
If you're making local changes against a library you don't own (with the ultimate intention of sending those changes back upstream to the library maintainer) it makes sense change the version number to avoid clashes with the canonical version of the library. Of course, it's easy to lose track and end up publishing your own program against a non-existent (outside your hard disk) version of the library. I'd like to make it very obvious, both in mypogram.cabal and library.cabal that one is a patched copy and the other has to be compiled against a patched copy. Does cabal provide any way of marking a version private? I thought initially to just mark the version field in the patched library as X.y-dougal and enforce my program to compile against that, but it doesn't seem to recognise the -dougal suffix there. Thoughts? D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net
Hi Dougal Could you prefix or suffix the forked package name in the cabal file instead, then choose the appropriate one when you use GHC with the -package-name flag? Best wishes Stephen
As somebody who's hacked on cabal-install a bit (but don't have a
worthwhile patch to contribute (yet?)), I can tell you that versions
support a "tag" structure, at least internally, but I haven't seen a
non-empty tags field and don't know how to make the tags field
non-empty. For that I'd have to go source-code diving again.
http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal-1.8.0.2/Distribu...
Best,
Leon
On Sun, Mar 21, 2010 at 10:58 AM, Dougal Stanton
If you're making local changes against a library you don't own (with the ultimate intention of sending those changes back upstream to the library maintainer) it makes sense change the version number to avoid clashes with the canonical version of the library.
Of course, it's easy to lose track and end up publishing your own program against a non-existent (outside your hard disk) version of the library. I'd like to make it very obvious, both in mypogram.cabal and library.cabal that one is a patched copy and the other has to be compiled against a patched copy.
Does cabal provide any way of marking a version private? I thought initially to just mark the version field in the patched library as X.y-dougal and enforce my program to compile against that, but it doesn't seem to recognise the -dougal suffix there.
Thoughts?
D
-- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Sun, Mar 21, 2010 at 5:15 PM, Leon Smith
As somebody who's hacked on cabal-install a bit (but don't have a worthwhile patch to contribute (yet?)), I can tell you that versions support a "tag" structure, at least internally, but I haven't seen a non-empty tags field and don't know how to make the tags field non-empty. For that I'd have to go source-code diving again.
http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal-1.8.0.2/Distribu...
That seems just the kind of thing that could be co-opted to my purposes, but as you say the cabal file format doesn't seem to mention how I'd go about setting my tag field. Trying "Tag: dougal1" didn't work, as I suspected ;-) In the mean time I will try Stephen Tetley's approach of renaming the package instead of the version. Cheers, D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net
The documentation for Data.Version might be insightful: http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Data-Version.... If Cabal uses the parseVersion function to parse versions then the following version is valid: "1.2.3-a-b-c". If should result in this value: Version {versionBranch = [1,2,3], versionTags = ["a", "b", "c"]} But I don't know if Cabal allows you to depend on such a version.
On Tue, Mar 23, 2010 at 10:00 AM, Roel van Dijk
The documentation for Data.Version might be insightful:
http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Data-Version....
If Cabal uses the parseVersion function to parse versions then the following version is valid: "1.2.3-a-b-c". If should result in this value:
Version {versionBranch = [1,2,3], versionTags = ["a", "b", "c"]}
But I don't know if Cabal allows you to depend on such a version.
This post has an answer, but not one that makes me very happy ;-) http://www.mail-archive.com/cabal-devel@haskell.org/msg05955.html "We've not yet removed tag from the parser for backwards compatibility. Clearly what we should do is add a big warning (or simply error) that such tags are no longer supported. I hope in time to get Data.Version changed to eliminate the tags entirely." (Duncan Coutts) I guess it's too easy to abuse (says he who was planning to abuse it) but it's sad that there isn't something I can easily use in its place. At the moment renaming the package is serving my purpose. Cheers, D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net
On Sun, 2010-03-21 at 13:15 -0400, Leon Smith wrote:
As somebody who's hacked on cabal-install a bit (but don't have a worthwhile patch to contribute (yet?)), I can tell you that versions support a "tag" structure, at least internally, but I haven't seen a non-empty tags field and don't know how to make the tags field non-empty. For that I'd have to go source-code diving again.
We no longer use tags because they have no sane semantics. Yes, the tag is still present internally in the Version type, however I hope to eventually eliminate it entirely. Duncan
participants (5)
-
Dougal Stanton -
Duncan Coutts -
Leon Smith -
Roel van Dijk -
Stephen Tetley