- cabal-devel - Haskell.org

security/ experimental packages? authorization uncomon source locations, hackage db?
by Marc Weber 06 Jan '07

06 Jan '07

I've read the discussion about who is able to upload packages.. This is nice if you want to install most common packages.. But the packaging system is intended to save time. Thus what about I want to install an experimntal synthesizer which uses an experimental haskore interface from a person who hasn't registered his lib on hackage-db yet? In short: Would it be useful to allow speciyfing different download locations for dependencies in a cabal file? -- Lib.cabal -- depends: ExperimentalLib > 2.0 { location: http://person/haskell/ExperimentalLib.cabal } [...] This would give much more freedom .. I agree that it might be useful to "mask" those packages ... But its much more convinient to do cabal-install --allow-non-hackage-locations Lib than downloading/ installing/ updating those libs manually ? I think if you need total security you won't use this flag or use someithing like chroot (already mentioned) or user mode linux .. ;) But this issue adresses the question: What is hackage about: an automated installation system or an automated installation system + package list (centralized at hackagedb ?) Marc

1 0

where more info? comments on previous posts
by Marc Weber 06 Jan '07

06 Jan '07

Isaac showed me the Wiki. But I'm missing some pages discussing how hackage and tools should look like or pages which summarize decisions having be made on this list.. I think this missing because everything is in an early developement stage, right? What about adding some pages with summaries ? topics where I like to put my comment: 1) allow more than one atom beeing build with one cabal file? 2) configuration option, dependency handling ... a) different compilers / external dependencies b) proposal: flags my point of view c) hidden flags -> flag properties d) using availible libs e) posix os mingw cygwin detection? [4] f) build-profiles g) adding darcs-repository field to cabal h) external dependencies 1) allow more than one atom beeing build with one cabal file? ============================================================== "Cabal is the lowest-level tool for Haskell package management." I'd like to here some pro-cons about wether to allow putting libraries and executables into one cabal file: advantages multi atom cabal file: * it is one "Package" * one description/ license/ homepage field is sufficient * quote : "Configurations proposal On 10/24/06, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote: > > On the other hand, in Gtk2Hs I know one case where we do this. We have a > Graphics.UI.Gtk.Cairo api module that is only included if Gtk was built > against Cairo. In any case it could be faked by using cpp to just not > export anything rather than not having the module exposed at all. So > it's not clear that it's worth banning. Or maybe making it slightly > harder is worth it so that people don't get in the habit. Couldn't you split this into Gtk and Gtk-Cairo packages, where the latter is only built if Cairo is available? so it might be really useful to build more than one library using one package.. advantages single atom cabal file: * It does'nt make that much sense to me to allow different executables but only on lib. But allowing more than one lib will introduce another layer of abstraction as a cabal package is no longer the smallest unit. You need to check dependency within a cabal file and check dependencies not contained in cabal files * If you need library x you know you can find it in file x-version.cabal 2) configuration option, dependency handling ... ============================================================== a) different compilers versions ( see profile proposal below) Does it make sense to have more than one compiler version installed (eg ghc 6.4 6.5 and 6.6 ?) If so, whose task is to handle the different compilers? --with-hc-pkg=path --with-compiler=path or -wpath Would it make sense to have something like gcc/java-config of gentoo ? b) proposal: flags my point of view I'd like to see everything as flag. flags I'd like to add by default: - version - way = profiling | debug | optimized | distribution (user configurable ?) - stability (should be set by cabal readonly automatically) refering to [2] (build optimzed, profiling and debug version) and [3] (Duncan tells its intentional to not allow this) I agree. I'd like to be able to build different versions, too. That's why you have a packaging system that you don't have to all manually.. I yet have to look up how cabal does installing both profiling and default lib at the same time which was mentioned somewhere. One way to solve this is when building a profiling version append prof to its name. Thus if your lib L is build with profiling option it won't depend on parsec but on parsec-prof and won't be called L but L-prof. This way you have all you want, don't you? Cabal would have to add -prof option and add -prof to all names.. refering to [1]: Ian Lynagh: Why not permit declaration of flags insede a configuration? I can't see it why it should'nt be permitted c) hidden flags -> flag properties quote: " flag: fps_in_base dfault: available(base >= 2) " I like this idea (i had this tought too before reading this post) But I'd like to add "properties" to flags Thus what about: "hiden-flag: fps_in-base" ? This should mean the user can't modify it using configuration options.. d) using availible libs automatically refering to [http://www.haskell.org/pipermail/cabal-devel/2006-October/000230.html] ( On why 'availible' is evil) quote: "1. it often doesn't mean what you want 2. it allows auto-use deps 3. it makes life hard for distros and cabal-get 4. it makes the install order significant" comment to 1. If you have gtk and wxwidgets and you have the option to use either.. Then this would be a case I think its convinient to use the one already installed (?) But I agree that it wouldn't harm to set this option manually. So its cleaner to drop this auto-detection. Thanks for opening my eyes here! comment to 4. I agree. So what about determining library version which fits best independent of what can be found on the system, but add semething like emerge -p or emerge -va which tells you that lib xy is already installed having another version ? Thus if you have LibA-1.0 and wont to install LibB which would install LibA-2.0 on a plain new system I'd like to see dependencies to be installed: - LibA-2.0 (you already have 1.0, use -force-LibA-1.0 to use it) - ... This way installation order is not significant by default.. I've also read about binary packagers which don't like default flag values.. The same could be done here. Just print the automatically choosen flags and prompt for confirmation like this ./cabal-install LibA automacially determined dependencies: - LibB-2.0 unstable ( set by script, readonly) debug ( set by script, modifiable ) - haskell-db-2.0 (dependency of LibB) experimental ( set by script, readonly ) with-postgres : no with-mysql (set by command-line) with-Flat-DB (set by default) with-oracle : no - HSQL (dependency of haskell-db) with-postgres ( set by target haskell-db ) with-mysql (set by target haskell-db ) and optionally add configure option --no-defaults which prevents setting flags to default values Then everybody would be glad, right? e) posix os mingw cygwin detection? [4] Should os=windows be cygwin or mingw? no as os means operating system. mingw cygwin is no os but a build environment. I want to say it would be better to add another additional flag hasposix or is-mingw-build than changing os=windows to mingw/cygwin .. f) build-profiles What about build profiles? a build profile would consist of eg - compiler-flavour - compiler-version - flags (profile, debug, ..) - tools (use cpp = use c2hs = use greencard = ...) g) adding darcs-repository field to cabal If we talk about adding a darcs repo line to the cabal file it seems to me that cabal gets closer to maven which is a package management tool for java which handles * repositories * compilation * documentation * ide - integration (eclipse) * packaging * .. But there is one difference to cabal: It's sufficient to get the maven project description file if it contains information about how to get the source .. Thus: Does it make sense to distribute the cabal files with the source files? Why not add a general source-location: http://xy.z/.../source-2.3.tar.gz or source-location: darcs http://... line and the command ./setup fetch? but .. aeh this is the task of cabal-install, right? Sorry for this confusion.. I just don't understand yet why there are so many different tools and which task should be done by which tool.. h) external dependencies Some packages need foreign libraries (eg jnii Haskell-Java interface), (gtk/ wxwidgets) How to add them ??? i don't like to install some dependencies to notice that I also need C-lib xy .. Would it make sense to add support to install non-haskell libraries such as wxwidgets or sqlite as well ? Thus what about writing the system a little bit more general to also add a build profile for C-libraries? Unfortunately I've never used perl or CPAN.. ;( Does a page exist describing which features to implement form cpan? EG centralization ? CPAN seems to be mirrored and distributed all over the world. (But I might be wrong) Marc - sorry for this long mail quotes [1] ------------------------------------- Ian Lynagh igloo at earth.li Tue Oct 31 20:13:02 EST 2006 * Previous message: Configurations proposal * Next message: Configurations proposal * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] ----- Other bits A couple of other things occured to me. First, it should not be permitted to declare flags inside a configuration (I don't think anyone was saying otherwise, but I also don't think I saw it explicitly stated). [2] ------------------------------------- Configurations proposal Brian Smith brianlsmith at gmail.com Wed Oct 25 10:39:23 EDT 2006 On 10/24/06, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote: > > Hi All, > > Before the 6.6 release we had a longish discussion on how to do > configurations and their semantics and implementation complexity etc. > > I would like to re-propose the last scheme that I cam up with. I'll try > to make it a concrete proposal as well as giving some motivating > examples to give the intuition of the meaning. The only way I have really wanted to use configurations so far is to build debug, profiling, and optimized versions of a library. In order to build multiple configurations, is it going to still be the case that I have to "configure / build / install" separately for each configuration? I would like to be able to say something like "Setup.lhs configure --optimized --debug --profiled" to build all three versions at once. [3] ------------------------------------------ Duncan Coutts duncan.coutts at worc.ox.ac.uk Wed Oct 25 13:56:24 EDT 2006 * Previous message: Configurations proposal * Next message: Configurations proposal * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > How can I say that I want the DEBUG version of package "bar" to depend > on the DEBUG version of package "foo."? Is this allowed? No. This is not allowed. Indeed you can't express it with the syntax. That's because we don't record which configurations were active for a package that was built. This is intentional. [4] Brian Smith brianlsmith at gmail.com Thu Oct 26 11:52:48 EDT 2006 * Previous message: Configurations proposal * Next message: Configurations proposal * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [...] I agree--I wish System.Info.os worked differently, actually. But, there are apparently some people (not me) that use Haskell on Cygwin, and they need to be able to detect it, because e.g. Posix and Readline are available on Cygwin but not Mingw. Maybe os(x) should be either "mingw" or "cygwin"? - Brian [4] ---------------------------------- Configurations proposal Duncan Coutts duncan.coutts at worc.ox.ac.uk Tue Oct 31 20:34:35 EST 2006 > flag: fps_in_base > default: available(base >= 2) > > configuration: fps_in_base > build-depends: base(>= 2) > > configuration: !fps_in_base > build-depends: base(< 2), fps > > The user would be able to shoot themselves in the foot by overidding the > fps_in_base flag such that they don't have the deps installed, but > that's their own fault. Note that the right thing will happen if they > just leave it as the default. Yeah it'd work but I don't like it. It exposes too much to the user for one thing. It's not always going to do the the right thing either. In this case you can only have one version of base installed at once, but for other libs that's not the case. So imagine I do have base-1.0 and 2.0 installed then there's no

1 0

darcs patch: Add preliminary support for haddock-ghc (and 2 more)
by davve＠dtek.chalmers.se 05 Jan '07

05 Jan '07

Fri Sep 15 21:29:49 CEST 2006 davve(a)dtek.chalmers.se * Add preliminary support for haddock-ghc Fri Dec 29 20:54:39 CET 2006 davve(a)dtek.chalmers.se * Make sure haddock-ghc really creates the output dir Sun Dec 31 00:21:16 CET 2006 davve(a)dtek.chalmers.se * Add compilerPath to Paths_<pkg>

1 0

Re: [David Waern] Re: darcs patch: Add preliminary support for haddock-ghc
by Neil Mitchell 01 Jan '07

01 Jan '07

Hi, > No, it doesn't work yet. So I turn the question around: Will GADT's and > other extensions be supported by Hoogle in the future? To some degree, yes. A GADT will probably be recorded as though it was a normal ADT for type matching purposes. It's similar with forall at the moment, they are entirely dropped for type matching purposes, but are searched. > Without such > support, how useful would it be to include Hoogle support in haddock-ghc? I would have thought quite useful, for example if you are going to hoogle something like Yampa, you'll need something which can at least ignore the GADT's. My larger concern was if haddock-ghc is going to replace haddock one day, then I'll definately want --hoogle in there. Thanks Neil

1 0

[David Waern] Re: darcs patch: Add preliminary support for haddock-ghc
by Isaac Jones 31 Dec '06

31 Dec '06

2 1

Hello. some questions and suggestions
by Marc Weber 28 Dec '06

28 Dec '06

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 <marco-oweber(a)gmx.de> writes: > 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

4 5

Patch using multiple preprocessors ...
by Marc Weber 28 Dec '06

28 Dec '06

This patch seems to work. But I haven't done serious testing yet. It passes my own test. The test is in multipleextensiontest and contains the files multiple_extension/ setup.hs ( contains the test preprocessors) src_executable/Multipleextensiontest.1.2.3.a.b module Main where main = do print "start" -- P1 -- P2 -- P3 -- Pa -- Pb -- Pc print "end" multipleextensiontest.cabal The preprocessors 0,1,2,a,b,c (c not used) will each replace -- Px by print "x" and add another print line to get the reversed order of run preprocessors. The diff is made relative to darcs/haskell.org/cabal/cabal-1.1.7 Isaac told me that cabal-install is newer .. You can also get the whole repository with changes here (http://mawercer.de/marcweber/haskell/cabal-1.1.7-my/ ) Greetings Marc diff -rN old-cabal-1.1.7-my/Cabal.cabal new-cabal-1.1.7-my/Cabal.cabal 7c7 < Build-Depends: base --- > Build-Depends: base, mtl diff -rN old-cabal-1.1.7-my/Distribution/PreProcess.hs new-cabal-1.1.7-my/Distribution/PreProcess.hs 64c64 < moduleToFilePath, die, dieWithLocation) --- > moduleToFilePath, die, dieWithLocation, on) 70c70,71 < import System.Directory (removeFile, getModificationTime) --- > import System.Directory (removeFile, getModificationTime, doesFileExist) > import Data.Bits ((.|.)) 73c74,76 < (splitFileExt, joinFileName, joinFileExt) --- > (splitFileName, splitFilePath, splitFileExt, joinFileName, joinFileExt) > import Control.Monad > import Debug.Trace 76c79 < -- external program, but need not be. The arguments are the name of --- > -- /xternal program, but need not be. The arguments are the name of 144,163c147,177 < preprocessModule searchLoc modu verbose builtinSuffixes handlers = do < bsrcFiles <- moduleToFilePath searchLoc modu builtinSuffixes < psrcFiles <- moduleToFilePath searchLoc modu (map fst handlers) < case psrcFiles of < [] -> case bsrcFiles of < [] -> die ("can't find source for " ++ modu ++ " in " ++ show searchLoc) < _ -> return ExitSuccess < (psrcFile:_) -> do < let (srcStem, ext) = splitFileExt psrcFile < pp = fromMaybe (error "Internal error in preProcess module: Just expected") < (lookup ext handlers) < recomp <- case bsrcFiles of < [] -> return True < (bsrcFile:_) -> do < btime <- getModificationTime bsrcFile < ptime <- getModificationTime psrcFile < return (btime < ptime) < if recomp < then pp psrcFile (srcStem `joinFileExt` "hs") verbose < else return ExitSuccess --- > preprocessModule searchLoc modu verbose builtinSuffixes handlers = > let hslhs = zip builtinSuffixes $ repeat (\_ _ _ -> return ExitSuccess) -- .hs,.lhs or .gc using hmake with nhc : do nothing > all_handler = hslhs ++ handlers -- use builtin handler first ( you can't override .hs, lhs anyway as target and source filename would be the same, wouldn't it?) > preprocess f = let (dir, file) = splitFileName f > (fwe, ext) = splitFileExt file > in case ext of > "" -> case splitFileExt fwe of > (_, "") -> return ExitSuccess -- No extension left. do nothing > _ -> die $ "no extension found! don't know how to handle this file " ++ f > ext -> case lookup ext all_handler of > Nothing -> die $ "no handler found for extinsion pant " ++ ext > Just pp -> let dest = dir `joinFileName` fwe > in do de <- doesFileExist dest > recomp <- if de then liftM2 (>) > (getModificationTime f) > (getModificationTime dest) > else return True -- dest file doesn't exist > if recomp then pp f dest verbose >>= > \exitCode -> case exitCode of > ExitSuccess -> return () > _ -> fail $ "preprocessor beeing responsible for extension part " ++ ext ++ "failed" > else return () > -- now do next preprocessing step > preprocess dest > > in moduleToFilePath searchLoc modu (map fst all_handler) >>= \srcFiles -> case srcFiles of > [] -> die $ "!!can't find source for " ++ modu ++ " in " ++ show searchLoc > [f] -> -- run preprocessor if necessary > preprocess f > files -> die $ "muliple fitting source files found for module " > ++ modu ++ " files " ++ foldr1 (\a b->a ++ ", " ++ b) files diff -rN old-cabal-1.1.7-my/Distribution/Simple/Utils.hs new-cabal-1.1.7-my/Distribution/Simple/Utils.hs 44a45 > on, 58a60 > moduleToFilePath2, 89,90c91,93 < import Control.Monad(when, filterM, unless) < import Data.List (nub, unfoldr) --- > import Control.Monad(when, filterM, unless, liftM) > import Data.List (nub, unfoldr, maximumBy, length, isPrefixOf) > import Data.Map (union, toList, fromList) 113a117,125 > f `on` op = \x y -> f x `op` f y > > -- --------------------------------------------------------------------------- List > -- spits the list on element element > splitBy :: (Eq a) => [a] -> a -> [[a]] > splitBy list element = case break (== element) list of > (a, []) -> [a] > (a, b) -> a:splitBy b element > 213a226,249 > -- FIXME/TODO: check wether tail contains only known suffixes. Only checks matching filename yet > moduleToFilePath2 :: [FilePath] -- ^search locations > -> String -- ^Module Name > -> [String] -- ^possible suffixes > -> IO [(FilePath, FilePath)] > moduleToFilePath2 locs mname possibleSuffixes = > let mname_parts = splitBy mname '.' -- "Data.List" -> ["Date","List"] > m_path = init mname_parts > joinPathElements folders = foldr1 joinFileName folders > gDC path = catch (getDirectoryContentsWithoutSpecial path) (\_-> return []) > maxBy [] = Nothing > maxBy l = Just $ maximumBy (\a b -> compare (length a) (length b)) l > -- does file match mname? > filterFile = ( isPrefixOf ((last mname_parts) ++ ['.'] )) > -- filter names beginning with (last mname_parts) ++ ['.'], > -- omitting hs/lhs for compatibility (.gc, .chs, ..) > -- only use longest filename (thus no intermediate file) > filterModule = maxBy . (filter filterFile) > foldr_f (loc, files) l = case filterModule files of > Nothing -> l > Just f -> (loc, f):l > in do files <- mapM (\loc -> gDC $ joinPathElements (loc:m_path) ) locs > return $ foldr foldr_f [] $ zip locs files > 217a254 > moduleToFilePath locs mn ps = (liftM (map (uncurry joinFileName))) $ moduleToFilePath2 locs mn ps 219,238c256,280 < moduleToFilePath pref s possibleSuffixes < = filterM doesFileExist $ < concatMap (searchModuleToPossiblePaths s possibleSuffixes) pref < where searchModuleToPossiblePaths :: String -> [String] -> FilePath -> [FilePath] < searchModuleToPossiblePaths s' suffs searchP < = moduleToPossiblePaths searchP s' suffs < < -- |Like 'moduleToFilePath', but return the location and the rest of < -- the path as separate results. < moduleToFilePath2 < :: [FilePath] -- ^search locations < -> String -- ^Module Name < -> [String] -- ^possible suffixes < -> IO [(FilePath, FilePath)] -- ^locations and relative names < moduleToFilePath2 locs mname possibleSuffixes < = filterM exists $ < [(loc, fname `joinFileExt` ext) | loc <- locs, ext <- possibleSuffixes] < where < fname = dotToSep mname < exists (loc, relname) = doesFileExist (loc `joinFileName` relname) --- > -- moduleToFilePath :: [FilePath] -- ^search locations > -- -> String -- ^Module Name > -- -> [String] -- ^possible suffixes > -- -> IO [FilePath] > -- > -- moduleToFilePath pref s possibleSuffixes > -- = filterM doesFileExist $ > -- concatMap (searchModuleToPossiblePaths s possibleSuffixes) pref > -- where searchModuleToPossiblePaths :: String -> [String] -> FilePath -> [FilePath] > -- searchModuleToPossiblePaths s' suffs searchP > -- = moduleToPossiblePaths searchP s' suffs > > -- -- |Like 'moduleToFilePath', but return the location and the rest of > -- -- the path as separate results. > -- moduleToFilePath2 > -- :: [FilePath] -- ^search locations > -- -> String -- ^Module Name > -- -> [String] -- ^possible suffixes > -- -> IO [(FilePath, FilePath)] -- ^locations and relative names > -- moduleToFilePath2 locs mname possibleSuffixes > -- = filterM exists $ > -- [(loc, fname `joinFileExt` ext) | loc <- locs, ext <- possibleSuffixes] > -- where > -- fname = dotToSep mname > -- exists (loc, relname) = doesFileExist (loc `joinFileName` relname) diff -rN old-cabal-1.1.7-my/Setup.lhs new-cabal-1.1.7-my/Setup.lhs 1,5d0 < #!/usr/bin/runhaskell < > module Main where < > import Distribution.Simple < > main :: IO () < > main = defaultMain diff -rN old-cabal-1.1.7-my/multiple_extension-test/multiple_extension-test.cabal new-cabal-1.1.7-my/multiple_extension-test/multiple_extension-test.cabal 0a1,12 > Name: multipleextensiontest > Version: 0.0 > License: BSD3 > Author: Marc Weber > Category: > Synopsis: test multiple extensions > Build-Depends: haskell98 ,base ,Cabal > > Executable: multipleextensiontest > hs-source-dirs: src_executable > Main-Is: Multipleextensiontest.hs > other-modules: Multipleextensiontest diff -rN old-cabal-1.1.7-my/multiple_extension-test/setup.hs new-cabal-1.1.7-my/multiple_extension-test/setup.hs 0a1,56 > module Main where > import Distribution.Simple > import Distribution.Simple.Configure > import Distribution.Simple.LocalBuildInfo > import Distribution.PreProcess > import System > import System.Process > import System.Exit > import Monad > > import Char ( isSpace ) > -- #ifdef __GLASGOW_HASKELL__ > -- #ifndef __HADDOCK__ > -- import {-# SOURCE #-} GHC.Unicode ( isSpace ) > -- #endif > -- import GHC.List ( replicate ) > -- import GHC.Base > -- #else > -- import Data.Char( isSpace ) > -- #endif > > import Text.ParserCombinators.ReadP > > main= do > args <- getArgs -- check args to launch ghci > when (length args > 0) $ do > when ((args!!0) == "ghci") $ do > lbi <- getPersistBuildConfig > let packageArgs = (concat.concat) [ [" -package ", showPackageId pkg] | pkg <- packageDeps lbi ] > system("ghci " ++ packageArgs) > exitWith ExitSuccess > defaultMainWithHooks $ defaultUserHooks { hookedPreProcessors = hp } > where hp = map (testPreprocessor.(:[])) "123abc" > > testPreprocessor :: String -> PPSuffixHandler > testPreprocessor ext = ( ext, pp) > where pp _ _ src dest verb = do > print $ " preprocessing file " ++ src ++ " and writing to " ++ dest > readFile src >>= \f -> writeFile dest $ unlines . ppFile $ lines f > return $ ExitSuccess > ppFile :: [ String ] -> [ String ] > ppFile =(++ [" print \"preprocessed by "++ ext ++ "\""]) > . (map preprocessLine) > parseLine :: ReadP (String, String) > parseLine = do spaces <- many $ satisfy isSpace > string "--" >> (many $ satisfy isSpace) > char 'P' > ext <- (many1 $ satisfy (not.isSpace)) > rest <- many get > return $ (spaces, ext) > preprocessLine :: String -> String > preprocessLine line = let parseResult = (readP_to_S parseLine) $ line > in case parseResult of > [((spaces, e),_)] -> if ext == e then spaces ++ "print \"" ++ ext ++ "\"" > else line > _ -> line diff -rN old-cabal-1.1.7-my/multiple_extension-test/src_executable/Multipleextensiontest.hs.1.2.3.a.b new-cabal-1.1.7-my/multiple_extension-test/src_executable/Multipleextensiontest.hs.1.2.3.a.b 0a1,11 > module Main where > > main = do > print "start" > -- P1 > -- P2 > -- P3 > -- Pa > -- Pb > -- Pc > print "end"

1 0

package collection
by Ross Paterson 05 Dec '06

05 Dec '06

As I understand it, a package collection, like http://hackage.haskell.org/packages/unstable/ has the structure 00-index.tar.gz <pkg>/ <pkgid>.cabal <pkgid>.tar.gz ... where 00-index.tar.gz tars up all the <pkg>/<pkgid>.cabal files. Such a simple structure makes it easy to add tools. Perhaps it could be made simpler by replacing the index with a file that was just a concatenation of the .cabal files with some separator (say @), and having both gzipped and uncompressed versions. The main missing piece seems to be a means of uploading packages. Any plans there? Perhaps something along the lines of PAUSE (http://www.cpan.org/misc/cpan-faq.html#What_is_PAUSE) except that we only need to upload Cabal tarballs.

3 2

Re: cabal (./Setup.hs) options
by Duncan Coutts 04 Dec '06

04 Dec '06

On Tue, 2006-08-08 at 10:45 +0200, Johan Tibell wrote: > > Hi, > > > > I like Cabal. There are a few things that I'm used to from autotools which > > I can't seem to find: dry-runs, uninstall and a "make distcheck" equivalent. > > <snip> > > > uninstall > > Removes all files and directories created by install > > Ditto. This is really necessary since otherwise I'll have to build a > Debian package anyway before I can install the Cabal package. Getting > software of my system is almost as important as getting it on there in > the first place. Prevents my system from deteriorating over time. I think we didn't include this feature deliberately for some reason. Isaac can you remember? > Would it be hard to implement? Anything I could do to help? In general the way to help is just to submit patches with an accompanying explanation/motivation/rationale. 'darcs send' does the "Right Thing"tm, i.e. it sends them to the cabal-devel list. Oh and everyone is invited to join the cabal-devel mailing list. Subscribe here: http://www.haskell.org/mailman/listinfo/cabal-devel Our main bottleneck on Cabal development is not the lack of people pointing out shortcomings but the number of people sending patches. Send more patches, the last ones tasted great! Duncan (wearing his Cabal patch reviewer hat)

8 12

Remove Setup.hs, use Setup.lhs only
by Ian Lynagh 30 Nov '06

30 Nov '06

[forwarding this manually as the BTS doesn't send to a mailing list; the bug is at http://hackage.haskell.org/trac/hackage/ticket/100 ] I'm not sure if this should be a bug(enhancement) report or on the mailing list, but I've gone with putting it here so that it won't be accidentally forgotten about. Allowing both Setup.hs and Setup.lhs causes minor annoyances all over the place when working with cabal packages, and moreso when writing tools to work with cabal packages. There are also a couple of larger problems I've had. For example, when writing a Makefile that builds all cabal packages in subdirectories (i.e. (re)make setup if necessary, configure and build) it is hard (for me at least!) to tell make "setup depends on whichever of Setup.hs and Setup.lhs exists". The benefits of allowing Setup.hs are small. For the common case you only save a couple of copies of > , while for larger Setup.lhs files \begin{code} and \end{code} at the start and end is not significant overhead. The reason for choosing to keep Setup.lhs over Setup.hs is so that we can use #! scripts etc without having to worry about the Haskell impl trying to parse it. Thus I would like to propose dropping support for Setup.hs and supporting Setup.lhs only. It would probably be necessary for cabal to complain if it finds a Setup.hs file, as otherwise people wouldn't notice they hadn't updated their packages. Thanks Ian

8 19