November 2006 - cabal-devel

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

05 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 01 Dec '06

01 Dec '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

Re: Cabal preprocessing
by Ulf Norell 30 Nov '06

30 Nov '06

On Nov 30, 2006, at 11:13 AM, Henrik Nilsson wrote: > > The problem with that is that someone getting the sources might get > > the idea that the preprocessed file is an actual source file and > try > > to modify it (or just make sense of it, imagine someone trying to > read > > a happy parser...). > > True (although I'm not sure how much of a problem that really is). You'd be surprised :) I've been teaching a course in programming language implementation where I have had to stop several students from "fixing" generated code. / Ulf

1 0

Re: Cabal preprocessing
by Duncan Coutts 30 Nov '06

30 Nov '06

On Wed, 2006-11-29 at 17:12 +0100, Ulf Norell wrote: > Hi. > > Currently when Cabal preprocesses a module the result ends up in the > source directory. I would have expected it to end up in dist, since > it's a generated file and not a source file. I would tend to agree. Wherever possible I think it'd be preferable to put generated sources in the build tree not the source tree. > So, > - are there strong reasons for putting preprocessed files in src? Mostly, not having got round to doing it. If you're volunteering to look into doing this, then great! There are cases, as Stefan mentions, where it's less clear cut, like generated sources that we expect to distribute. > - if not, is there a simple (and robust) way to have them end up in > dist? I expect not. I think it needs changes to Cabal. I think it should be possible though, since most tools either allow the locations of all the source files to be specified explicitly, or provide a search dir feature. Duncan

2 1

Re: Cabal preprocessing
by Ulf Norell 30 Nov '06

30 Nov '06

On Nov 29, 2006, at 10:21 PM, Stefan Holdermans wrote: >> - are there strong reasons for putting preprocessed files in src? > > One reason could be that, when distributing *sources*, you'd want > the generated file to be included as well (that is, you want to > regard it as a source file), for the system your program is to be > compiled on might not have the preprocessor available and you don't > want to make that a hard requirement... Of course, you can still > achieve this by putting it in dist and put the file from dist in > the generated tarball, but, arguably, the way it's done now, makes > explicit that the file might be viewed as a source file. The problem with that is that someone getting the sources might get the idea that the preprocessed file is an actual source file and try to modify it (or just make sense of it, imagine someone trying to read a happy parser...). Including parts of dist in the tarball makes it clear that what you get is not a vanilla source distribution. > Also, building executables with GHC --make requires (?) modules to > be present in designated locations in the directory tree... You just have to run GHC with -idist/... This is the way I had it set up before migrating to Cabal. / Ulf

1 0

Configurations proposal, take n
by Ian Lynagh 29 Nov '06

29 Nov '06

Ross, Duncan, Ian and Simon M met in the morning before the Haskell "fun in afternoon" event in Oxford to thrash out a revised design for Cabal configurations. We think it was quite productive. Here we will try to summarise the state of the proposal at the end of the discussion. We've filled in some details that weren't (well) discussed, so Ross and Simon might not be in total agreement with all of the below. Let's start with some BNF. It's a bit vague (e.g. the string and cabal_stanza productions are not defined, and we haven't said anything about disallowing certain kinds of stanzas inside conditional blocks), but hopefully it gives the right idea. cabal_file: flag_introductions "\n" body flag_introductions: flag_introduction "\n" flag_introductions | <nothing> flag_introduction: "flag:" flagname [ "\n" "description:" string ] body: cabal_stanza "\n" body | "if" conditional "{" body "}" [ "else" "{" body "}" ] body | <nothing> conditional: "os(" string ")" | "arch(" string ")" | "flag(" flagname ")" | "True" | "False" | "!" conditional | conditional "||" conditional | conditional "&&" conditional | "(" conditional ")" Now an example: flag: fps_in_base description: Use a base library that contains fps flag: debug description: Show debugging information if flag(fps_in_base) { build-depends: base >= 2 } else { build-depends: base < 2, fps >= 0.8 } if flag(debug) && os(windows) { cpp-options: -DDEBUG_WINDOWS_STUFF } First we declare two flags, fps_in_base and debug. We've also put in descriptions that might be shown by some Cabal GUI frontend. Now we look at the body. Any os(foo) and arch(foo) conditionals are immediately reduced to either True or False. True, False, if/else, !, ||, && and (...) do what you'd expect. flag(foo) where foo is not introduced is an error. Flags use a three valued logic: They can have the value True, False or Unknown. If the value True or False is given by the user for a particular flag then that flag behaves as that value. The interesting case is when flags have the (default) value Unknown. We start off by assuming all Unknown flags have the value True (the reason for starting with True is that we expect people to normally want to write flags in the sense new_thing_is_available, and we generally want to use new things when possible; there is scope to include a "default: False" in the flag introduction stanza to give the user control over this) and see if we can satisfy the build-deps. If we can, then we are done! Otherwise, we try with the last introduced flag being False, and so on, i.e. we do something like head $ do fps_in_base <- [True, False] debug <- [True, False] guard (satisfies_deps fps_in_base debug) return (body fps_in_base debug) Note that the order is determined by the order in which flags are introduced. Intuitively, it is equivalent to trying the rest of the file with first "True" then "False" for each flag introduced. There is scope for optimisation of this process, but it nevertheless remains exponential in the worst case, with 2^n possibilities (given n flags) needing to be tried. Things are even worse if using cabal-get, which then needs to go off and try to install other packages (making sure to not allow the package we are currently working on to be depended upon by them!) in order to satisfy build-deps. However, we believe that in practice this should not be a problem. We don't think that the blocks-of-stanzas format fits well with configurations, so we have used a style with braces. This also allows us to nest conditionals, which should eliminate some duplication. We also think that the cabal syntax may be made clearer to the user if this style was employed for the basic cabal syntax itself, e.g. library { cabal stanzas } executable { cabal stanzas } executable { cabal stanzas } rather than the current cabal stanzas cabal stanzas cabal stanzas but that is a proposal for another day! Ian and Duncan

2 2

Automagic cabalising of projects?
by dons＠cse.unsw.edu.au 28 Nov '06

28 Nov '06

So, on the joy of functional infrastructure. As previously discussed at the cafe, there's a bit of a plan to make a cabalising wizard. Yesterday I hacked up a quick tool[1] to do 2 things: [1] http://www.cse.unsw.edu.au/~dons/code/mkcabal/ 1) create a stub cabal file: $ runhaskell ../mkcabal.hs Project name: haq What license ["GPL","LGPL","BSD3","BSD4","PublicDomain","AllRightsReserved"] [BSD3]: BSD3 Created Setup.lhs and haq.cabal $ ls Setup.lhs haq.cabal $ cat haq.cabal Name: haq Version: 0.0 Description: Project description License: BSD3 License-file: LICENSE Author: Author Name Maintainer: user(a)email.address Build-Depends: base Executable: haq Main-is: Haq.hs $ cat Setup.lhs #!/usr/bin/env runhaskell > import Distribution.Simple > main = defaultMain 2) create a stub project repo, including cabal files and readmes $ runhaskell ../mkcabal.hs --init-project Project name: haq What license ["GPL","LGPL","BSD3","BSD4","PublicDomain","AllRightsReserved"] [BSD3]: Created new project directory: haq $ ls haq $ cd haq $ ls Haq.hs LICENSE README Setup.lhs haq.cabal Neil et al have suggested that the core should be abstracted out as a library, in order to write clients. This is a good idea. I'm interested, oh Ancient and Justified Developers of the Cabal, about where this should go. Should the tool try to fill in more details? If so it should probably be part of the cabal distro and use the existing cabal library. Should it stay lightweight? Should it try to discover the project src tree? Should it suggest hierarchical names to use? How can we make this most useful? Do people know of package wizards for other infrastructure that works well? What plans for automagic cabalisation have people been thinking about. Cheers, Don

2 1

Re: [Gregory Wright] Cabal 1.1.6: an infelicity and a bug
by Isaac Jones 28 Nov '06

28 Nov '06

Gregory Wright <gwright(a)comcast.net> writes: (snip) > If you can tell me where the include/ directory is created I can take > a stab at making > a patch. If you can't, I can still try. It just might take me longer > :-) If this is happening during registration (I can't remember offhand), the it's probably in the file GHCPackageConfig.hs. Grep around for createDirectoryIfMIssing. Maybe that function could take an extra flag "thisDirectoryMightBeEmpty" or something: grep createDirectory Simple/Register.hs Simple/GHC.hs Simple/GHCPackageConfig.hs Simple/Register.hs: (createDirectoryIfMissing,removeDirectoryRecursive, Simple/Register.hs: createDirectoryIfMissing True libdir Simple/GHC.hs: ( createDirectoryIfMissing ) Simple/GHC.hs: createDirectoryIfMissing True libTargetDir Simple/GHC.hs: createDirectoryIfMissing True odir Simple/GHC.hs: createDirectoryIfMissing True targetDir Simple/GHC.hs: createDirectoryIfMissing True exeDir Simple/GHC.hs: createDirectoryIfMissing True cSrcODir Simple/GHC.hs: = do createDirectoryIfMissing True pref Simple/GHC.hs: createDirectoryIfMissing True incdir Simple/GHCPackageConfig.hs:import Distribution.Compat.Directory (getHomeDirectory, createDirectoryIfMissing) Simple/GHCPackageConfig.hs: createDirectoryIfMissing True (dirName f) BTW, I committed a bunch of comment changes last night all over the place, so to avoid conflicts, everyone will want to pull before making any changes. peace, isaac

1 0

[Gregory Wright] Cabal 1.1.6: an infelicity and a bug
by Isaac Jones 25 Nov '06

25 Nov '06

Gregory & cabal-devel, I like his suggestion about --register for applications. I've attached a patch (which I can't push at the moment becuase I have no internet.) About the macports empty directories, that's a bit more strange. Is there any way to instruct macports to NOT delete empty directories? Alternately, it would be nice if ghc-pkg were a bit more fault-tolerant. What does the --force flag do? Does it actually create the directory? peace, isaac

2 1

Allow the user to get at the actual default hooks
by Ian Lynagh 22 Nov '06

22 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/101 ] Currently, if you want add a hook then there seem to be two starting sets of hooks you can use. One is emptyHooks, but this really is empty. If you use these hooks then setup build will do nothing, for example. The other is defaultHooks, but this does more than the defaults; for example, it will also run configure. The actual defaults should be available as a UserHooks, and a UserHooks rather than a Maybe UserHooks should be passed around. At first look, the current code is quite hard to follow. It would also be nicer if extra hooks could be composed with suitable combinators, e.g. theRealDefaultHooks :+: runConfigureHooks :+: someOtherHooks and the extra stuff in defaultHooks was broken up into smaller pieces. Thanks Ian

2 1