- cabal-devel - Haskell.org

Progress: GSoC - Improve the feedback of the cabal-install dependency solver
by Martin Ruderer 18 Jun '13

18 Jun '13

Hey all, we are nearing the end of the "Students get to know mentors, read documentation, get up to speed to begin working on their projects"-Phase and I would like to tell you what I have done so far and how you can follow my progress in the future, if you like. I have forked cabal at https://github.com/mr-/cabal and I have set up a little blog at http://cabal-summer.blogspot.de/ . So far, I have written an IDE to navigate the dependency tree interactively. However the output is not very user-friendly yet. This I will focus on in the immediate future. If you have any comments on what you would like to see done, or more concretely, have suggestions for useful commands to walk the tree, I would be very grateful. Ciao, Martin

2 2

Auto generating hoogle database from cabal
by Erik de Castro Lopo 10 Jun '13

10 Jun '13

Hi all, Anyone know the status of adding the ability to generate hoogle database from cabal? I've found these: http://hackage.haskell.org/trac/hackage/ticket/402 https://code.google.com/p/ndmitchell/issues/detail?id=80 but they seem un-finished or incomplete. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 0

Password recovery on trac
by David Fox 10 Jun '13

10 Jun '13

The page at http://hackage.haskell.org/trac/hackage/reset_password says Trac Error The password file could not be updated. Trac requires read and write access to both the password file and its parent directory. when I try to recover my password. Could someone take a look at this? Thanks. -david

1 0

Mac .app and .framework bundle building
by Irene Knapp 05 Jun '13

05 Jun '13

Hi, all! The other day, I created an issue over on GitHub with my thoughts on a family of related features that I have now begun implementing, to support the building of Mac bundles. As anyone who's used the platform probably knows, these are a way of distributing libraries and applications as specially-structured directory trees. They are particularly important because the Mac's GUI API, Cocoa, *requires* a .app wrapper around any executable which uses the display. Command-line programs which attempted to access the display used to behave strangely and never take focus, but since Mountain Lion introduced sandboxing, they no longer even run. This makes libraries such as SDL and its peer glow rather pointless for Haskell developers, unless we can build them into bundles. I have specific thoughts on implementation, which I wrote up on the ticket, but as I've begun work on this I've additionally noticed some related features which, since I'm now doing this "for real" and not "just for me" like my previous work in this area, really need discussion before being implemented. I've linked to the ticket below, but for those on their phones, :), I'm also summarizing and repeating most of what I said there, here. I'll put the most controversial part first: I'm doing this as two new top-level components, Framework and App respectively, as peers to Library, Executable, TestSuite, and all our other favorites. This allows a single .cabal file to contain instructions for both regular Unix-style and fancy Mac-style, and even to install both side-by-side if desired. This is particularly important in the case that one wants to build a .app bundle which contains some command-line support tools, which is not a hugely uncommon pattern in software designed for developers. It does create some duplication of information; for example, if one wants to build a Library on non-Mac platforms, but instead build a Framework on the Mac, then one must include all the options for both, keep ithem in synch, and conditionalize the buildable: option based on the platform. However, I don't see this duplication as being any worse than what most .cabal files in the wild already do for test suites. I will note that somebody else might wish to work on a feature to define variables in a .cabal file, with sets of option-value pairs as their values, with the goal of reducing duplication... but I don't have time myself. A subsidiary feature is the building of Apple's Interface Builder .xib documents into .nib documents (.xib is a source file and .nib is its compiled form), by shelling out to Apple's command-line tool. This is one of the things I've already gotten working and just need to forward-port from my two-year-old fork to my current fork, so it shouldn't be a big deal or raise major design questions. Another issue is Apple's Info.plist files, which are XML in a well-documented format, that goes inside the bundle. The last time I worked on this, Duncan expressed a strong desire for them to be generated; I believe his argument reduced to wanting Cabal, as a matter of pride, to be the authoritative owner of package metadata. They do overlap slightly with what we currently have, mostly in the authorship information. They also have version numbers, but I don't think offhand that they're in a compatible format with ours. Mostly, however, they contain Apple-specific information such as category in their store; bundle identifier in reverse-DNS style; document-type definitions which include identifiers, filename extension mappings, and the like; ... They are fairly complex in that way. It would be a pain to describe them in our .cabal file, and the information would be useless for other component-types. So, I'm not inclined to do this. I expect to have no difficulty with .app bundles, because those also I previously had working. However, .framework bundles present a different can of worms. It is certainly of some use to create a .framework which contains Haskell code intended to be used from a C application. But, it would be really nice if we could actually use our own .frameworks from Haskell. To do this, the .hi and installed-package-info files need to reside inside the .framework directory... and need to use relative paths, which I haven't looked into the feasibility of, since the point of a .framework is that it can be relocated in the filesystem. I think that if this can be done, that will be sufficient to make these beasts load properly, but does anybody see any other obstacles? My old patches for C-side main() and other supporting things I don't remember regarding hybrid C-Haskell programs will also be needed, but I'm fairly sure those got merged recently. (I wasn't involved, since I had long since given up getting them through review, so I'm not sure exactly which patches made it.) Another point - I've been operating under the assumption that Framework components will have names, unlike Library components. I can't easily use the package name for them, as is done for Library components, because the Unix convention is lower-case and the Mac convention is uppercase, and you will recall that I consider it important to support both component types in one .cabal file. But this makes things inconsistent and I'd rather like it if that inconsistency were resolved by allowing multiple Library components, with names. It would be useful to me personally; I've got another project that is broken into several pieces, which right now each have their own .cabal files out of necessity, but which I would rather merge together to make their building and testing (drastically) simpler. I'm willing to do that work, once I'm done with the rest of this, but I wouldn't hold up the merge of bundles on it; it's not crucial to them. What do people think? Having written all this, it has actually made me think twice about the wisdom of making Haskell-package .framework bundles at all - it might be better to stick with just .app bundles. But I really, really wanted to not try to run without a .nib in my fork of glfw and its Haskell wrapper, because running without a .nib is both buggy and rather hard to maintain, since it unnecessarily puts things into imperative code that are better done through GUI tools. Does anybody have an opinion? Since obviously nobody is waiting eagerly for this, I see no reason to push out a release with just .app support; I'd rather get everything working before merging, even the hard bits. The brave can experiment with my new fork anyway in the meantime, since it's on GitHub. Whew! Thank you for reading this far. :) I should make this shorter, but I'm in a rush to get home just at the moment... References: https://github.com/haskell/cabal/issues/1355 https://github.com/IreneKnapp/cabal/ -- Irene Knapp

1 0

Divin�sia - Lista dos aprovados em vestibular
by David Anderson 05 Jun '13

05 Jun '13

Divinésia ALINE MOURA FERREIRA, LARESSA RAMOS FERREIRA, FERNANDA LEONTSINIS CARVALHO BRANCO, NATIELLY ALEXANDRE CARNEIRO, JOÃO CARLOS MOREIRA DE CARVALHO, CLAUDIO LUIS GOMES PEREIRA, MARIA CECILIA ALBUQUERQUE CORDEIRO, ISABELLE PEREIRA DA SILVA. RUI ANDRADE DA SILVA, ELIANA DANTAS RIBEIRO, MATHEUS FERNANDES CAMPOS, JOSE VALDIR TEIXEIRA BRAGA FILHO, VINICIUS CANDIDO DOS REIS. Bom Jesus de Goiás. Vitória da Conquista ANA MARA DE SOUSA PEREIRA, LUANA FERNANDA FERNANDES ANDRADE, FRANCISCO ROGER GARCIA DE ALMEIDA, POLLYANNA DE O, JOÃO CARLOS MOREIRA DE CARVALHO, DANIELLA FERNANDES DA SILVA, MARIA JOSÉ DA SILVA FERREIRA, JÉSSICA VENTURA FREIRE. SOLANGE PAULINO CORREIA, BRUNA KETHEY DA SILVA PEIXOTO, LUIS HENRIQUE FREITAS GOMES, HELIO SOARES DE ARAUJO, RENER QUEIROZ VIEIRA. Barra do Garças. Alterosa ALINE MOURA FERREIRA, LARESSA RAMOS FERREIRA, FERNANDA LEONTSINIS CARVALHO BRANCO, NATIELLY ALEXANDRE CARNEIRO, JOÃO CARLOS MOREIRA DE CARVALHO, CLAUDIO LUIS GOMES PEREIRA, MARIA CECILIA ALBUQUERQUE CORDEIRO, ISABELLE PEREIRA DA SILVA. RUI ANDRADE DA SILVA, ELIANA DANTAS RIBEIRO, MATHEUS FERNANDES CAMPOS, JOSE VALDIR TEIXEIRA BRAGA FILHO, VINICIUS CANDIDO DOS REIS. Barra do Garças.

1 0

ANNOUNCE: haskell-packages-0.1
by Roman Cheplyaka 27 May '13

27 May '13

I am happy to announce the first release of haskell-packages. http://haskell-suite.github.io/haskell-packages/ There are two cases when you may need haskell-packages: if you are writing a Haskell compiler (or any tool that processes Haskell source code, such as a static analyzer), or if you want to integrate with an existing Haskell compiler that uses haskell-packages. ## Writing a compiler If you are writing a compiler, you typically want to integrate it with Cabal, to be able to build ordinary Haskell packages. If you go the hard way, this involves: 1. **Parsing command line parameters**. Sounds easy — just take a list of files to compile. In reality you also need to handle package ids and package dbs, CPP options (`-DFOO=1`), language extension flags (`-XRankNTypes`) etc. To integrate with Cabal, you also need to tell it the list of installed packages, supported languages and extensions etc. 2. Actual **integration with Cabal** means understanding how Cabal works and hard-coding support for your compiler. And then getting it accepted and waiting for the next Cabal release. You may pretend that you are GHC or other compiler that is already supported by Cabal. It might work, but often it won't, for various reasons. Also, GHC's command line protocol is quite complex. 3. **Package management**. You need to implement a package db mechanism, which would let you to keep track of installed packages. Then you'd have to implement a `ghc-pkg`-like tool to manage those databases, for both Cabal and your users. **Or**, you can simply use this library! It already has command line options parsing, Cabal support, and package management. All you need to do is to provide the function to do actual compilation and tell a couple of other things about your compiler. See the `Distribution.HaskellSuite.Compiler` module for details. ## Using other compilers Some compilers produce artifacts that you may want to use. A good example is the `gen-iface` compiler from haskell-names which generates an *interface* for each module — the set of all named entities (functions, types, classes) that are exported by that module. This information can be then used either by other compilers, or by tools like IDEs. Assuming the compiler uses haskell-packages and exports its database type, it's very easy to use its artifacts. See `Distribution.HaskellSuite.Packages` for package resolution and `Distribution.HaskellSuite.Modules` for module resolution. ## Installation Note that haskell-packages uses (yet unreleased) haskell-src-exts 1.14. Get it [here][hse]. It doesn't matter what Cabal version you use together with haskell-packages, but if you want to invoke a haskell-packages compiler from Cabal (see [Usage](#usage)), you need to build our [fork of Cabal][Cabal]. Eventually it will be merged into Cabal. [hse]: https://github.com/haskell-suite/haskell-src-exts [Cabal]: https://github.com/feuerbach/Cabal ## Usage To compile a Haskell package using a haskell-packages tool: cabal install --haskell-suite -w $TOOL where `$TOOL` may be either a full path to the compiler, or just an executable name if it's in `$PATH`.

1 0

Re: [Haskell-cafe] How to throw an error if using "cabal-install" < version XYZ?
by Ryan Newton 23 May '13

23 May '13

Great! Thanks. I adapted that trick and it worked fine: https://github.com/rrnewton/haskell-lockfree-queue/blob/cb8ca1a5d8b4c02e45e… On Wed, May 22, 2013 at 11:53 PM, Carter Schonwald < carter.schonwald(a)gmail.com> wrote: > Hey Ryan, > I ran into a related issue, heres a a way you can do this safe IN the > cabal file (or at least you can modify my hack for your purposes) > > heres a link to the workaround I did for making LLVM-hs work across >= > 1.17 and < 1.17 cabal, but you could abuse it to make sure setup.hs barfs > on old cabal > https://github.com/bos/llvm/blob/master/base/Setup.hs#L89-L116 > > heres a quick one off gist that takes my trick and does something helpful > for you variant + makes sure the tool can't build otherwise > > https://gist.github.com/cartazio/5632636 > > I just wrote a snippet that you can just add to your setup.hs and it > should guarantee the setup.hs will barf with a helpful error message on > cabal < 1.17.0 > > > On Wed, May 22, 2013 at 10:50 PM, Ryan Newton <rrnewton(a)gmail.com> wrote: > >> A cabal-install bug <https://github.com/haskell/cabal/issues/1284> was >> fixed recently that pertains to building C libraries with profiling. >> >> As a result, I want a certain package<http://hackage.haskell.org/package/atomic-primops-0.1.0.2>to test if cabal-install < 0.17.0 is used, and throw a preemptive error. >> Otherwise this package fails in weird ways at runtime (it's a nasty one). >> >> I noticed with some surprise the following sequence: >> >> * $ cabal --version* >> * cabal-install version 1.16.0.2* >> * using version 1.16.0.3 of the Cabal library* >> * $ cabal clean* >> * $ cabal install* >> * $ cat dist/build/autogen/cabal_macros.h | grep VERSION_Cabal* >> * #define VERSION_Cabal "1.17.0"* >> >> Alright, so that, in retrospect, makes sense. The version is which *my* >> library is linked with is the relevant one, not the one cabal-install was >> linked with [1]. >> >> So the natural next thought is to move the MIN_VERSION_Cabal test into >> Setup.hs, and force cabal to use it by setting the build type to Custom. >> But... I just learned from this ticket that the cabal macros are not >> available in Setup.hs: >> >> http://hackage.haskell.org/trac/hackage/ticket/326 >> >> Uh oh, what's left? >> >> -Ryan >> >> [1] P.S. Personally I'm now using a bash function like below, to force >> the two versions to be the same: >> >> function safe_cabal_install () { >> VER=`cabal --version | tail -n1 | awk '{ print $3 }'` >> cabal install --constraint="Cabal==$VER" $* >> } >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >

1 0

How to throw an error if using "cabal-install" < version XYZ?
by Ryan Newton 23 May '13

23 May '13

A cabal-install bug <https://github.com/haskell/cabal/issues/1284> was fixed recently that pertains to building C libraries with profiling. As a result, I want a certain package<http://hackage.haskell.org/package/atomic-primops-0.1.0.2>to test if cabal-install < 0.17.0 is used, and throw a preemptive error. Otherwise this package fails in weird ways at runtime (it's a nasty one). I noticed with some surprise the following sequence: * $ cabal --version* * cabal-install version 1.16.0.2* * using version 1.16.0.3 of the Cabal library* * $ cabal clean* * $ cabal install* * $ cat dist/build/autogen/cabal_macros.h | grep VERSION_Cabal* * #define VERSION_Cabal "1.17.0"* Alright, so that, in retrospect, makes sense. The version is which *my* library is linked with is the relevant one, not the one cabal-install was linked with [1]. So the natural next thought is to move the MIN_VERSION_Cabal test into Setup.hs, and force cabal to use it by setting the build type to Custom. But... I just learned from this ticket that the cabal macros are not available in Setup.hs: http://hackage.haskell.org/trac/hackage/ticket/326 Uh oh, what's left? -Ryan [1] P.S. Personally I'm now using a bash function like below, to force the two versions to be the same: function safe_cabal_install () { VER=`cabal --version | tail -n1 | awk '{ print $3 }'` cabal install --constraint="Cabal==$VER" $* }

2 1

Hackage2 does not always read the package category properly
by Henk-Jan van Tuyl 22 May '13

22 May '13

L.S., I found, amongst others, the SDL package (at page http://new-hackage.haskell.org/packages/ ) in the Unclassified category, while the cabal file of this package says "Foreign binding". On page http://new-hackage.haskell.org/package/SDL , clicking on the link "Foreign binding", leads to the top of the package listing, instead of the Foreign binding section. Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0

install --builddir
by Benjamin Scarlet 15 Apr '13

15 Apr '13

I'm having trouble with install --builddir. If I run $ cabal install --builddir /some/absolute/path test-framework I get an error after regex-posix is installed, during the build of test-framework: Text/Regex/Posix/Wrap.hsc:141:8: Could not find module `Text.Regex.Base.RegexLike' It is a member of the hidden package `regex-base-0.93.2'. Perhaps you need to add `regex-base' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. But if I run $ cabal install --builddir /some/absolute/path regex-posix $ rm -r /some/absolute/path $ cabal install --builddir /some/absolute/path test-framework I do not get the error. Between experiments I'm removing my ~/.cabal and ~/.ghc and running cabal update. Naively, it looks to me like using an absolute builddir has changed things so successive packages share the same intermediate files, which in turn has caused a later package to erroneously recompile a previously generated file. My ultimate aim is only to be able to use cabal-dev for my development builds, but without writing into my source tree. Is there any way to specify a build directory outside the source of a package without it winding up shared? Could/should cabal instead create a separate subdirectory within the specified builddir for each package to be built, so that specifying an external location didn't break things? Thanks, Ben Scarlet

2 1