- cabal-devel - Haskell.org

Release planning?
by Bardur Arantsson 17 Dec '15

17 Dec '15

Hi all, Where does release planning happen? I'd like to start on merging some solver-related PRs, but if there's an imminent release, that might not be such a good idea... Regards,

4 7

Cabal/cabal-install 1.24 release status
by Mikhail Glushenkov 16 Dec '15

16 Dec '15

Hi *, As some of you know, I've recently been elected as Cabal "chair"/release coordinator. GHC 8/Cabal 1.24 release date is fast approaching, so I'll try to summarise my current plans regarding the next release. Release schedule: * I'll create the 1.24 branch in about two weeks' time (Dec. 30 let's say). * GHC 8 RC1 will be using Cabal HEAD/1.23. * If there will be a GHC 8 RC2 (Herbert tells me it's very likely), it'll use the Cabal 1.24 pre-release (1.24 branch). * Cabal 1.24 final will be released simultaneously with GHC 8 (maybe a bit earlier). * cabal-install 1.24 will be released either simultaneously with Cabal 1.24, or soon after. I don't want to delay it by much. Cabal patches I'd like to see in 1.24: * Library support for Duncan's nix-local-build branch. This has just went in (#2948). * Kristen's improved 'Setup configure' (#2925). Needs a review. * Edsko's foreign library patches (#2540). Mostly ready to go in, but needs rebasing and some additional review. * **/* globbing (#2522). I want to rework it a bit. * (Possibly) #2829 - Thomas's reconfigure work, though he seems to have abandoned it. cabal-install patches I'd like to see in 1.24: * hackage-security. Duncan tells me that Edsko is working on it right at the moment, and some preliminary patches have already been merged. We may delay cabal-install's release a bit to get this in. * Duncan's nix-local-build work in some form. This release will probably be a "technical preview". * Andres's solver patches (#2731). Needs tests. * Kristen's solver improvements (#2917, #2916, #2914). Would be nice if Andres could do a review. * 'gen-bounds' (#2774). * 'user-config init' (either #2640 or #2604). Comments welcome! Some other TODO items on my list: * Gershom/Haskell.org are willing to allocate some build bot time to us for producing cabal-install binaries (Windows/OS X/Linux) and possibly nightlies. This will need a patch to ghc-builder [2], but should in principle be not that hard to set up. GitHub Releases can be used for hosting downloads. * Revamp the web site [3]. I'd like to set up a news feed/blog and start posting monthly news updates akin to what haskell-mode devs have been doing [4]. * Reorganise the user guide. We need to put more focus on the 'cabal' tool and less on the 'Setup.hs' interface. If someone is willing to help me with these three last ones, it'd be appreciated! [1] http://article.gmane.org/gmane.comp.lang.haskell.cabal.devel/10408 [2] https://github.com/haskell/ghc-builder [3] https://www.haskell.org/cabal/ [4] https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-July-2015

1 0

ANN: Cabal-1.22.5.0 has been released
by Ryan Thomas 30 Nov '15

30 Nov '15

Cabal 1.22.5.0 has been released and pushed to hackage with the following changes: - Don't recompile C sources unless needed (#2601). (Luke Iannini) - Support Haddock response files. - Add frameworks when linking a dynamic library. As well as to facilitate the GHC 7.10.3 release. Cheers, ryan

1 0

issue with cabal behavior with a custom Setup.hs
by Thomas Lippincott 29 Nov '15

29 Nov '15

Hello, I'm seeing what I think is some strange (or at least, non-intuitive) behavior in a custom package, and was wondering if someone could point me in the right direction. Basically, I need the build process to generate some additional exposed modules, i.e. add them to the "exposed-modules" variable, and create the corresponding source files. It's easy to get the list of modules and produce the source files at any point in the build process (I know this is a questionable design, trying to do this as part of Cabal, but suffice it to say there are good arguments on both sides for our particular situation). I'm *so* close to having it working perfectly: in fact, if I run "cabal repl", I get a shell with all the right modules compiled and exposed, so, it should work the same way if it's installed and imported in ghci, right? Well, when I do that, the auto-generated modules are *not* exposed. It's clearly generating the source files and compiling them, maybe "cabal install" isn't getting the updated module list or something? Here's what I'm doing: I override "confHook" to call the original configure function, but then get the list of auto-generated modules and add them to the exposedModules field in the Library structure nested in the LocalBuildInfo structure before returning it. The idea is that I've intercepted the list of exposed modules as early as possible, and so it's as though the Cabal file had the auto-generated modules listed from the start. I generate the actual source files by overriding "preBuild". Nothing else is modified from the default simpleUserHooks. This probably isn't the place for "how do I..." questions, so I'll frame it as: why would "cabal repl" work, and "cabal install" and ghci+import not work? I apologize if this is an inappropriate place to ask, but there aren't exactly a ton of Cabal experts floating around! Thanks for any help, -Tom

2 2

Hints on fixing #2645: Properly merge preferences (dependency resolution)
by Martin Vlk 28 Nov '15

28 Nov '15

Hi folks, I am a beginner cabal hacker and I have been picking issues to fix, labeled with "easy". My next one is https://github.com/haskell/cabal/issues/2645. I've been trying to read and feel my way through the code and find where this issue is rooted, but so far I haven't succeeded. To save me unnecessary effort, could somebody point me at the right modules/functions where soft constraints/preferences are handled and also where the corresponding merging functionality is implemented for hard constraints. I'll then take it from there, read the code and fix the issue, potentially asking more questions here. Many Thanks Martin

2 2

Contributing to Cabal (fix to #2155)
by Martin Vlk 17 Nov '15

17 Nov '15

Hi, I have a fix to https://github.com/haskell/cabal/issues/2155 including tests almost ready locally and I would like to look at how to propose a pull request on GitHub. Do I fork the cabal repo or do I have to get commit rights for the main repo? How does a review process work? Mind you I am a Haskell beginner and likewise this is my first time contributing to some other repo on GitHub so I ask for patience. :-) Martin Vlk

3 2

Fwd: Haskell Platform Plans
by Gershom B 13 Nov '15

13 Nov '15

Dear all, As you know, Mark has passed on the Haskell Platform maintainer hat to me. I wanted to give a heads-up on current plans to keep folks in the loop. This message has three sections, first the 7.10.3 release, next the 8.0 release, and finally some general musings on fiddly details and future plans. 1) 7.10.3 The 7.10.3 release candidates have been out for windows and unix for a bit. As I understand it there is still work underway on the mac build, but that will hopefully be coming shortly. The plan is to release a new platform roughly simultaneously. This platform will work essentially as in the past, for two reasons. First, because it is the last release in the 7.10 series and should be seen like the 7.10.3 compiler as just incorporating some necessary patches rather than any serious changes. Furthermore, the future plans underway rely on a few patches to cabal which have been merged, but are not yet in any existing cabal-install release. A few packages have received minor version bumps, as follows: PACKAGE 7.10.2-a latest ------------------------------------------- case-insensitive 1.2.0.4 1.2.0.5 fgl 5.5.2.0 5.5.2.3 GLUT 2.7.0.1 2.7.0.3 GLURaw 1.5.0.1 1.5.0.2 HUnit 1.2.5.2 1.3.0.0 OpenGL 2.12.0.1 2.13.1.0 OpenGLRaw 2.5.1.0 2.6.0.0 primitive 0.6 0.6.1.0 syb 0.5.1 0.6 scientific 0.3.3.8 0.3.4.2 StateVar 1.1.0.0 1.1.0.1 A few packages were held back due to dependency issues (notably zlib) and additionally, packages shipped with ghc were held back to the versions that will be shipped with 7.10.3. 2) 8.0 We also plan to ship a new platform concurrently with the ghc 8.0 that should be released early next year. That platform will implement some long-discussed and requested changes. First, the platform already ships with msys on windows. However, it does not do so in a way that lets you, as with minGHC, install the network library directly, or for that matter install directly other libraries that use build-type configure. This is because the msys binaries don't get placed into the path, by design. The new platform will ship with a newer cabal, incorporating a patch (pull request #2480) that uses the extra-prog-path setting for build-type: configure. This should allow network and other things reliant on build-type: configure to directly cabal install. The goal for the platform on windows will be that any packages binding to msys libraries _should_ be cabal installable without hassle. If you maintain a library that you think would be a good test-case for this, please drop a line so we can work together towards this goal. Second, the default platform will be _minimal_. That is to say that it will _only_ install into the global package database those packages that are directly shipped with ghc, and not any additional platform packages. "Blessed" platform packages will however still be shipped as a "default user cabal.config" file, so in a setting where users want to work unsandboxed, their versions of platform libs will remain pegged to those chosen by the platform, should they not choose to alter their settings. In a sandboxed setting, or in the presence of a local cabal.config generated by a freeze, those constraints will be disregarded. Furthermore, it is likely but not certain that the "nix-like cabal" or "no-reinstall cabal" will be available for the 8.0 release. If this is the case, users will be able to operate in an unsandboxed environment without conflicts, as multiple instances of the same version of a package, with different dependency choices, will be able to live side-by-side. Third, the platform will ship not only with cabal-install, but also with the stack tool, so that users can choose either workflow, depending on their project or preferences. A number of people have adopted the stack tool, and many beginners have reported success with it as well, so it will be good to provide that functionality out of the box with every platform install. Time and resources permitting we would also like to ship a platform version _with_ the platform libraries prebuilt and included, as that is also a use case that some people continue to like. However, this is a secondary priority, and contingent on us getting our build infrastructure into a good enough shape to make this not too much extra hassle. I'm excited about these changes, and confident we can get their in a timespan that matches the 8.0 release of ghc. 3) Generalities As I mentioned, it would be good to have a more uniform build infrastructure. Generally, I have put out some feelers and am working towards extending the ghc nightly buildbot infrastructure to both cover more platforms and also cover more tools -- not only ghc, but cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get an economy of scale and many of our core tools will be able to all share regular automated builds across many platforms. If you like CI/buildbot systems and would like to help out with this project, please reach out. Also, once we've modernized and fixed up the core platform installer tech, it would be nice to move back to the process of making the platform a good set of blessed libraries -- taking more proposals for additions to it, looking to cull libraries that are no longer widely used, etc. As part of this I intend to move the haskell-platform list off our deprecated community.haskell.org infrastructure and onto mail.haskell.org with our other active lists. Finally, I'm happy to be maintainer of the platform through this period of change and transition, but at some future point, as things get sorted out and the release process becomes more standard and mechanical, I would very much like to pass this responsibility on. I have had some nibbles of offers, but if other people want to begin to get involved, please let me know and we can start to get small contributions from you so that you can become familiar with the various tech and systems involved. The Haskell ecosystem is a team effort, a collective project, and volunteer driven. In my modest experience hacking on the various systems involved (cabal, cabal-install, hackage, the platform build, etc.) some are a bit confusing, but I have always found helpful contributors willing to explain things and review patches, and to help think about and diagnose problems. And none of the code has been as confusing as things I've had to wade through for employment-related purposes :-). So when this stuff doesn't work as well as we'd like, we can investigate together, and then put our heads together and figure out how to improve it together. Furthermore, it can be very satisfying to do so, because the impact of those improvements makes itself widely felt. I look forward to more people joining in! Best, Gershom

1 0

Baffled by Distribution.Simple.BuildTarget.checkTargetExistsAsFile
by Echo Nolan 11 Nov '15

11 Nov '15

I'm finding this function very confusing. I think it's supposed to determine if a user build target is a file, and whether that file exists, but it does some real weird stuff. I'm not sure if I've found a bug or I just don't understand what it's supposed to do. Here's the source: checkTargetExistsAsFile :: UserBuildTarget -> IO (UserBuildTarget, Bool) checkTargetExistsAsFile t = do fexists <- existsAsFile (fileComponentOfTarget t) return (t, fexists) where existsAsFile f = do exists <- doesFileExist f case splitPath f of (d:_) | hasTrailingPathSeparator d -> doesDirectoryExist d (d:_:_) | not exists -> doesDirectoryExist d _ -> return exists fileComponentOfTarget (UserBuildTargetSingle s1) = s1 fileComponentOfTarget (UserBuildTargetDouble _ s2) = s2 fileComponentOfTarget (UserBuildTargetTriple _ _ s3) = s3 So... UserBuildTargets can be components, modules or files and can be qualified at three levels of specificity. It takes the last part of the qualified build target - which is either a module (Main), a component (cabal), or a file (Main.hs), then runs the existsAsFile function on it. It returns a 2-tuple of its input and the result of existsAsFile. existsAsFile checks whether its parameter is an existing file, then splits its parameter on directory separators i.e. / or \. If the resulting list is nonempty and first element ends in a directory separator it returns whether that first element is an existing directory. This case is entered any time the parameter begins with a directory, e.g. "foo/bar.hs" but not "bar.hs". Shouldn't we just return exists here? existsAsFile's second case is where the split path has at least two elements and the parameter is not an existing file. It returns whether the first component of the split path is an existing directory. I have no idea. The last case is where splitPath f is []. This can only be true if f is []. In that case we return whether the file named "" exists. This is impossible, so it's always false. I can't imagine what happened to make this function this way. From my perspective, existsAsFile should equal doesFileExist. I must be missing something right? Best regards, Echo Nolan

1 0

Anybody using the "top-down" solver?
by Bardur Arantsson 10 Nov '15

10 Nov '15

Hi all, Just to get input from as many people as possible: I was pondering a plan for modularizing the solver[1] and wanted to reach as many people as possible with my question: Is anybody is still using the top-down solver? Please respond to this list if you are, especially if you're doing so because there's no other way to get the modular solver to do what you want. (Obviously, I'm not promising to fix any problems you may have with the modular solver, but it would be valuable information since it could affect the decision of whether we have to keep the top-down solver around.) Regards, -- [1] https://github.com/haskell/cabal/pull/2768#issuecomment-154917165

4 5

pre-710 compatibility stuff
by lennart spitzner 24 Oct '15

24 Oct '15

hi, should we use #if __GLASGOW_HASKELL__ < 710 or #if !MIN_VERSION_base(4,8,0) ? currently both are used in different places, and i have no idea if there is a difference/if it matters. if it does not, i suggest conventionizing one of the two. lennart

3 5