May 2011 - cabal-devel

[Hackage] #821: Add support for Apache license
by Hackage 25 Oct '11

25 Oct '11

#821: Add support for Apache license ----------------------------+----------------------------------------------- Reporter: bos | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have several projects licensed under the Apache license due to upstream dependencies, but Cabal doesn't know about it. This would be good to add for e.g. license compatibility checkers (I believe Galois has such a tool). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/821> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #847: Cabal ignores multiple test options given with "--test-option{, s}"
by Hackage 17 Jul '11

17 Jul '11

#847: Cabal ignores multiple test options given with "--test-option{,s}" ----------------------------+----------------------------------------------- Reporter: ttuegel | Owner: ttuegel Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When using {{{--test-option}}} or {{{--test-options}}} on the command line, {{{cabal test}}} only passes the last option given to the test executable. Thanks to waern for reporting. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/847> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal): "build-tools-extend-namespace" and 2 others
by Duncan Coutts 08 Jul '11

08 Jul '11

Mon Oct 5 22:58:31 PDT 2009 intractable(a)gmail.com * build-tools-extend-namespace M ./Distribution/Simple/Configure.hs -9 +27 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=… Wed May 4 18:41:44 PDT 2011 intractable(a)gmail.com * intrapackage-deps-and-per-component-preprocessing This patch adds intrapackage dependency resolution so that components (libraries, exes, test suites) are build in the correct order. This mean it's now possible to have, e.g., executables that depend on other executables defined in the same package description: the build-tools namespace has been extended accordingly. Related to this change is the refactoring of the do-it-all preprocessSources function, formerly invoked by initialBuildSteps, into a a function preprocessComponent that is invoked when a component is being built. This lets us use executables defined in a package to be used as a custom preprocessor when building other components. Finally, a number of functions now operate on values of the sum type PackageDescription.Component rather than specifically operating on Library or Executable and so forth. M ./Distribution/PackageDescription.hs -11 +40 M ./Distribution/Simple/Build.hs -89 +88 M ./Distribution/Simple/Configure.hs -13 +45 M ./Distribution/Simple/Haddock.hs -94 +98 M ./Distribution/Simple/LocalBuildInfo.hs -1 +32 M ./Distribution/Simple/PreProcess.hs -66 +64 M ./Distribution/Simple/Program/Types.hs -1 +17 M ./Distribution/Simple/SrcDist.hs -5 +10 M ./Distribution/Simple/Utils.hs +1 M ./tests/suite.hs -2 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=… Sun May 8 12:09:44 PDT 2011 Duncan Coutts <duncan(a)community.haskell.org> * Do not include disabled tests into the component build graph M ./Distribution/PackageDescription.hs +1 M ./Distribution/Simple/Configure.hs -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

3 3

Re: Any remaining test patches?
by Duncan Coutts 29 Jun '11

29 Jun '11

On 18 May 2011 15:01, Thomas Tuegel <ttuegel(a)gmail.com> wrote: > On Wed, May 18, 2011 at 4:34 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: >> Sorry for having to leave so abruptly yesterday. Could someone please >> summarize the discussion? Are we going with GetOpt? > > We didn't reach a decision; primarily, I think, because I had to leave > before Duncan really had a chance to review the patch. (There really > wasn't any discussion after you had to leave.) But, my understanding > of the discussion before you left is that Duncan would prefer a custom > solution, rather than GetOpt. (Duncan, please correct me if that isn't > the case). Ok, I've looked at the Distribution.TestSuite API and had a go at designing something along the lines of what I was thinking. I'll try and explain this design and compare three designs: Thomas's current patch, my prototype and the the test-framework test interface. So the design in the current patch is nice and short: class Testable t where name :: t -> String options :: [OptDescr (t -> t)] defaultOptions :: t -> IO [String] run :: t -> IO Result data Result = Pass | Fail ErrorMessage | Error ErrorMessage deriving (Read, Show, Eq) data Test = forall t. Testable t => Test t The test suite will then expose a value of type [Test]. So the interesting aspects are: * the API uses a type class and an existential wrapper to hide the specific type of each test. * the default options are obtained using IO * it uses GetOpt to accumulate key/value style string options into the test instance, which can then be run (Presumably at least the default options must be added before the test can be run.) Here's the equivalent bit of my design (the TestResult is the same): data TestInstance = TestInstance { run :: IO TestResult name :: String, concurrentSafe :: Bool, expectedFail :: Bool, options :: [OptionDescr] setOption :: String -> String -> Either String TestInstance } Minor difference: extra flags for indicating whether the test is safe for concurrent execution (e.g. if it's pure or has only local side effects) and whether the test case is in fact expected to fail (so numbers of expected vs unexpected failures can be reported). The first major difference is that we do the "OO" bit differently. Instead of using a type class and an existential wrapper, we use a record. These two styles are pretty similar but the record avoids the use of existential types. Since the test agents using this interface never know or need to know the actual type of the test (they will always use Test above and manipulate it via the type class interface) then there is no advantage to using a type class. The option setting is rather similar in both designs. In both you end up using a function of type String -> String -> Test -> Test to accumulate a key/value option pair into the test instance. This lets the user add any number of options before running the test. The slight difference in style is down to the different OO encoding (class based vs record based). The major difference with the options is of course how they are validated and described (which I have not yet detailed). GetOpt does not actually provide any validation of options, that is, for an option --foo=bar, there is no parsing/validation of the string "bar". GetOpt just parses the overall command line string ["--foo=bar", ...]. This setOption function gives the possibility of validating the value string and producing an error message. Note that I don't have an IO action to get any default options. In this design it must always be possible to run the test with no options supplied. Internally, if a test does need some options specified then it just has to fill them in with its internal defaults. So, all the options are just (String, String) key value pairs and we can validate them. Obviously we also need some discoverability of what options are available and some information to construct a sensible user interface (either command line, config file, web UI or IDE GUI). data OptionDescr = OptionDescr { optionName :: String, optionDescription :: String, optionType :: OptionType, optionDefault :: Maybe String } The name and description are much like in GetOpt. The optional default is purely informative, for user interfaces that are able to display defaults (eg a web form). The OptionType is to give a user interface some extra info on what is expected so that they can present an appropriate interface and do some up front validation. Of course the real validation is done via setOption, or for things that can only really be validated by doing IO (like reading files) then they have to be deferred to when the test is actually run. So this list is just informative: data OptionType = OptionFile { optionFileMustExist :: Bool, optionFileIsDir :: Bool, optionFileExtensions :: [String] } | OptionString { optionStringMultiline :: Bool } | OptionNumber { optionNumberIsInt :: Bool, optionNumberBounds :: (Maybe String, Maybe String) } | OptionBool | OptionEnum [String] | OptionSet [String] | OptionRngSeed You can imagine how each of these could be used as hints to make a more helpful web form or GUI interface. They could also let a command line ui do some up front validation too. The most general case is OptionString for when no more specific alternative is appropriate. Now, I also looked again at what test-framework does and it has some interesting things and some things that are unnecessary for our purposes. There are two things there that I think we should consider. The first is the grouping of tests into a related bundles, or in general a hierarchy: data Test = forall i r t. Testlike i r t => Test TestName t | TestGroup TestName [Test] | PlusTestOptions TestOptions Test So we either have a individual test or a group of tests (which themselves can contain groups etc). I'm sure this is nice for displaying in a UI what tests can be run and displaying results of a run. Imagine an interactive UI that lets the user select a group of tests to be run, or an html report showing results by group. We could do something like this: data Tests = Test TestInstance | TestGroup TestName [Tests] The PlusTestOptions is interesting. As I understand this, it is really from the point of view of the author of the test suite: they are providing additional default test options for this test or group of tests. I don't think this is necessary from the point of view of the test agent, they do not need to know this. The above could be lifted into a structure without PlusTestOptions simply by pre-applying the test options to that subtree. On the other hand, perhaps it is useful for an agent presenting a user interface to be able to know that a whole group of test all take the same set of options. So perhaps we should have: data Tests = Test TestInstance | TestGroup TestName [Tests] | ExtraTestOptions [OptionDescr] Tests So this means that all of the tests below this ExtraTestOptions take the given set of options. Then individual tests would usually have an empty options set, or perhaps just add one or two for that special case. This grouping of test options should enable better user interfaces. Another interesting part of test-framework is what you get when you run a test: runTest :: t -> IO (i :~> r, IO ()) So I the main point here is that it gives us progress / logging while the test is being run. The i :~> r thing is basically just a lazy list with values of type i spat out along the way and finally ending in a result of type r. The way it's done in test-framework is to have a pure i :~> r lazy list and a separate IO () action that does the real work. The IO action performs the test and pokes the results into a Concurrent.Chan. The i :~> r lazy list is extracted from the Chan using getChanContents. Honestly, I don't know why Max did it this way, seems to me a much more direct approach is: data TestProgress = Finished TestResult | Progress String (IO TestProgress) So it's not a lazy list, it's a list with explicit IO to get the tail. The test-framework approach could be lifted into this fairly easily I think. Note that this kind of progress reporting is actually quite important. You cannot have each test logging information to stdout if you're going to run any tests concurrently. But it is quite nice to see progress (e.g. from QuickCheck) for the tests that are currently running, which is exactly what test-framework does using a 'top' like console interface (you can imagine GUI ones too). Comments, thoughts on any/all of this appreciated. Duncan

5 13

[Hackage] #817: "main-is" misparsed in if/else, only by sdist
by Hackage 20 Jun '11

20 Jun '11

#817: "main-is" misparsed in if/else, only by sdist ----------------------------+----------------------------------------------- Reporter: jeffwheeler | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.0.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- An if/else block which sets the main-is value for an executable based on a flag is misparsed when running "cabal sdist" (it's parsed correctly when running "cabal install"). Upon failure, it appears that it's looking for a filename that is the two main-is options concatenated together. E.g., I get the error "cabal: HackerMain.hsMain.hs doesn't exist". The problematic bit looks like: if flag(hacking) main-is: HackerMain.hs else main-is: Main.hs My entire config can be found on hpaste: http://hpaste.org/44939/yicabal (problematic lines around 268). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/817> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #813: Cabal should warn if the Cabal-Version range is too lax
by Hackage 18 Jun '11

18 Jun '11

#813: Cabal should warn if the Cabal-Version range is too lax ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have a Cabal file that contains the line {{{ Cabal-Version: >=1.6 }}} and then a test section: {{{ Test-Suite test-mypkg }}} Cabal should issue a warning like: {{{ Test-Suite feature requires Cabal-Version: >=1.10. Your Cabal version range ">=1.6" is too lax. }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/813> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #846: constructor synonyms
by Hackage 18 Jun '11

18 Jun '11

#846: constructor synonyms ----------------------------+----------------------------------------------- Reporter: DoS2RDk6HY | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: Severity: normal | Keywords: constructor, synonym, language, extension Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I want to be able to create synonyms for constructors, not only types. For example, I want to rename Left and Right to This and That. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/846> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #504: executables with a C main function
by Hackage 31 May '11

31 May '11

#504: executables with a C main function ------------------------------+--------------------------------------------- Reporter: duncan | Owner: dankna Type: enhancement | Status: assigned Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Changes (by dankna): * owner: => dankna * status: new => assigned -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/504#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #583: create application bundles on demand
by Hackage 31 May '11

31 May '11

#583: create application bundles on demand ----------------------------+----------------------------------------------- Reporter: kowey | Owner: dankna Type: enhancement | Status: assigned Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Mac OS | ----------------------------+----------------------------------------------- Changes (by dankna): * owner: => dankna * status: new => assigned -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/583#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #850: Configure fails when an Objective-C .h file is specified
by Hackage 31 May '11

31 May '11

#850: Configure fails when an Objective-C .h file is specified ----------------------------+----------------------------------------------- Reporter: dankna | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: configure mac objective-c Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When configuring a library or executable which has specified a C header with includes: in its .cabal file, and that header is actually Objective-C or includes other headers which are, configure fails. This is because of the test that Cabal does to determine whether all prerequisite C libraries are present, in which it compiles with gcc directly rather than going through the Haskell compiler as it does in the build phase. I'm working on a patch to this and should have it in about an hour. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/850> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4