Dear Cabal-devel-list reader
I've written two mails to Isaac Jones concerning cabal.
He kindly asked me to use this list. So here I am.
Scroll to the end of this mail to get to the most important text (look for 3) )
1) ------------------------------------------------
first mail with response
Marc Weber
Hi Isaac Jones.
Hi, Marc, thanks for writing. There's a cabal-devel mailing list where you can post questions so that others can take a crack at answering them, and they can get archived on the internet :)
I wanted to learn more about greencard so I started nivestigating how to use greencard preprocessor of cabal. Then I noticed different things
When building a lib and one or more executables only one build-depends setting is allowed for all three, lib and executables, right? If so it doesn't make much sense as ghc compiles statically so libs will be included in all executables which aren't necessary. (Correct me if I'm wrong, I feel still like a noob ;)
The build dependencies are on a per-package basis so that we can track dependencies between packages (for instance, to make sure that dependency x is installed before package y). Have you verified that the so libs are compiled in and bloating unnecessary stuff? That's kinda too bad, but I'm not sure offhand what to do about it. As an end-user, you can always break things into separate packages.
Running more than one preprocessor on the same file requires writing your own PrePrecossor handler and your own extension?
Yes, we've never done chained preprocessors. We've been planning it for a while, as noted on this ticket: http://hackage.haskell.org/trac/hackage/ticket/13 If you can implement it, that would be great :)
So I came up with the idea (see post on haskelcafe) to use multiple extensions, such as
A.hs.gc.di.chs which should mean: run c2hs, DrIft and then Greencard preprocessor on file A.hs. + you can read the file extension and you know what's going on - long names - you have to configure your editor to recognize .gc.di.chs as haskell file - You can't test for existing files, you have to list all files in all source directories and remvove those allowed extensions to see wether a file matches a module name.
What do you think?
I've started implementing it and I want to write a test now.
I think that searching for the files is going to be the hard part. Might not be too bad, though.
I know I can add my own IO action hook beeing invoked by ./setup test. The runTests hook function takes a Bool flag without description. dons on #haskell suggested it might be a verbose flag. This would make sense as the test hook doesn't take the ConfigFlags argument containing the verbose Int setting. So is this the verbose flag and if so why Bool and not Int, too?
I can't remember what the Bool in runTest is for, honestly. Might be a mistake. I set up runTest so that you can pass it any flags you want (see the example in test/withHooks/Setup.lhs).
When writing tests for cabal packages, how is this done?
I think it does make sense to seperate testing compiler/ package setup flavour from the package because not everyone installing the package wants to run the tests.
Would it be nice to be able to add test modules in the cabal file such like
test-source-dirs: test test-is: MyPackageTest.hs test-build-depends: QuickCheck test-flavour: ghci
and let cabal handle compiling/ running the test when invoking ./setup test automatically?
Maybe we could do that with configurations, as discussed on the mailing list recently: http://hackage.haskell.org/trac/hackage/ticket/27 That might be a more general solution, although not implemented yet.
I think running ghci might be a little bit faster than the compiler. This would require adding flavour GHCI for those who don't have hugs installed.
Can you tell me more about the status of cabal-install?
It's mostly done, but quite a few loose ends to tie up, and work on promition and adoption needs to be done. There's a hackathon planned where some folks will work on it: http://www.mail-archive.com/haskell@haskell.org/msg19470.html Maybe you can join in, or join in remotely :) peace, isaac ------------------------------------------------ 2) ------------------------------------------------ response 2:
Thanks Isaac for your wonderful reply
You're very welcome. Thanks for your interest in Cabal. We're always looking for good hackers :)
Hi, Marc, thanks for writing. There's a cabal-devel mailing list where you can post questions so that others can take a crack at answering them, and they can get archived on the internet :)
I'd like to join, really. Would you mind pointing me to the mailinglist you were refering to? I wasn't able to locate it. (neither on haskell.org -> mailinglists nor on hackage) Is this the right one? http://www.haskell.org/mailman/listinfo/libraries
http://www.haskell.org/mailman/listinfo/cabal-devel The list of haskell mailing lists is here: http://www.haskell.org/mailman/listinfo/ :)
I've trouble compiling cabal-install because Network/XmlRpc/Internals.hs seems to be in the path of ghc sources only. Is this meant to be used with ghc distribution only?
That's an older version of cabal-install. Look at this repo, it doesn't require many dependencies: darcs get http://darcs.haskell.org/cabal-with-install/ I don't know if it works w/ anything but ghc at the moment.
I like the idea using indentation (such as the haskell language is using anyway) Thus either use {;;..} or indentation. Do you know wether this processing step can be taken from a haskell compiler parser?
Are you referring to the configurations thread?
As soon as I'll be subscribed to the list I'll repost these messages to be archived and read by others.
The archive is here, you don't have to subscribe to read: http://www.haskell.org/pipermail/cabal-devel/ peace, isaac 3) ------------------------------------------------ summary, my steps, suggestions? Refering to http://hackage.haskell.org/trac/hackage/ticket/13 (topic allow preprocessor chaining) I'm working on this. Should be finished soon. Refering to http://hackage.haskell.org/trac/hackage/ticket/27 (enhancement, configuration option, optional dependencies etc) I'd like to work on this too. But I I'm lacking some knowledge here. At the moment cabal is using ReadP, right? Am I also right that ReadP is lacking user friendly error messages compared to parsec? I like the idea of using either { ; ; } or indentation. Thus you have best of both styles, C and python such like the haskell language. So would it be ok to use parsec instead of ReadP? ------- example file name: <name of package> version: <package version> build-depends: lib: <name of lib> hs-source-dirs: version: <lib version> test: test1 { main-is: test.hs; additional-dependencies: QuickCheck } test: test2 { main-is: test2.hs; additional-dependencies: QuickCheck } executable: <name of executable> hs-source-dirs: executable1 main-is: Main.hs additional-dependencies: <dependencies additional to global package dependencies> test: test1 { main-is: test.hs } executables: executable2 { main-is: Main.hs; hs-source-dirs: ex2 } [ ... ] ----------------- ^ Notice that you can attach tests to either libraries or executables. I would run them using ./setup test <executable-name>/<test-name> ./setup test <executable-name>/* ./setup test * -- run all tests Then I would suggest a directory structure like this packagedir/ executable1/ tests/test1/test.hs tests/test2/test.hs executable2/ tests/test1/test.hs tests/test2/test.hs lib/ test/test1/test.hs test/test2/test.hs which would mean setting hs-source-dirs: to the name of executable or library by default Some thoughts about what to support: cross-compiling ? ( I mean ghc can compile via C and gcc can do cross-compiling. I've never done this before) configuration dependend on * os/ compiler flavour eg [configuration: OS=windows, COMPILER=ghc] * selected features eg ( --enable-jpeg-support ) * existance of other libraries ( either gtk2hs or wxhaskell or hscurses ? hsplugins? ( example haskelldb ) ) * custom flags : flag workaround ghc-windows bug = OS=windows compiler=ghc compiler-version < 4.0 does this mean "or" or "and" ? Both should be possible as setup.hs has to be compiled anyway, would it be a good idea to not just print the configuration to a file (.setup-config), but generate a haskell module beeing imported by setup.[l]hs ? This would mean that you can even use haskell-expressions as flags such as hasGreencard : executableInPath "greencard" && greencardVersion > (3,2,0) [configuration: hasGreencard] Thus you can easily use or, and ||, && and so on or `elem` configuration options ... This leads me to the assumption that the only difference between setup.hs and package.cabal is that it's easier to write a cabal file than a module containing the same information, right? There should be the possibility to only use some configuration option depending on others. eg: ./setup --help --use-image-lib1 --with-jpg --with-gif --use-iamge-lib2 -- no suboptions here right? Things are done in this order right now: setup.hs -> tool to * configure * build -- with user hooks * test -- with user hooks * install Would it make sense to allow user hooks when configuring, too? This would result in a two stage tool chain: configure.hs -> tool to * configure -- with user hooks (eg generating Config.hs imported by setup.hs) setup.hs + configuration options -> tool to * build -- with user hooks * test -- with user hooks * install What do you think ?? I have to think about this again. Yet another thing. This is annoying: ./setup configure ./setup build sudo ./setup install It's like doing ebuild `equery which ghc` unpack ebuild `equery which ghc` compile ebuild `equery which ghc` install on gentoo systems Is it the task of cabal or cabal-setup to just use ./setup install which should run configure/ build automatically if necessary? or at least allow ./setup configure build install (in short ./setup cbi) Packags containing libraries and executables: Am I right that there is no difference in a) isntalling lib -> compiling executable with -pacakge lib b) compiling executable with lib modules in path. as long as there lib is a static lib. shared libraries aren't used because of recompilation issues, right? It would be much cleaner to use a) in any way and let cabal install the libraries before compiling those executables automatically... Does it make sense to distribute two libraries usnig one package? Example 1: Cabal contains some functionality to join filenames. This might also be another package to be used in different applications as well? Example 2: MissingH. I think it would be best to split this into different libs (MissingH-logging, MissingH-Prelude, ...) Aeh.. Sorry for this long post and happy replying... Marc Weber