- cabal-devel - Haskell.org

patch applied (cabal): "Bump Cabal lib version" and 1 others
by Duncan Coutts 08 Jul '11

08 Jul '11

Thu Jul 7 18:32:45 PDT 2011 Duncan Coutts <duncan(a)community.haskell.org> * Bump Cabal lib version M ./cabal/Cabal.cabal -1 +1 M ./cabal/Makefile -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=… Thu Jul 7 18:32:48 PDT 2011 Duncan Coutts <duncan(a)community.haskell.org> * Bump cabal-install version M ./cabal-install/cabal-install.cabal -7 +2 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): "Fix withComponentsLBI and move Components to LocalBuildInfo module" and 1 others
by Duncan Coutts 08 Jul '11

08 Jul '11

Thu Jul 7 18:21:22 PDT 2011 Duncan Coutts <duncan(a)community.haskell.org> * Fix withComponentsLBI and move Components to LocalBuildInfo module An annoyance of the current Simple build system is that each phase (build, install, etc) can be passed additional HookedBuildInfo which gets merged into the PackageDescription. This means that we cannot process the PackageDescription up front at configure time and just store and reuse it later, we have to work from it each time afresh. The recent addition of Components (libs, exes, test suites) and a topoligical sort of the components in the LocalBuildInfo fell foul of this annoyance. The LocalBuildInfo stored the entire component which meant they were not updated with the HookedBuildInfo. This broke packages with custom Setup.hs scripts that took advantage of the HookedBuildInfo feature, including those with configure scripts. The solution is to store not the list of whole components but the list of component names. Then withComponentsLBI retrieves the actual components from the PackageDescription which thus includes the HookedBuildInfo. Also moved the Components into an internal module because (for the moment at least) it is part of the Simple build system, not part of the package description. M ./cabal/Distribution/PackageDescription.hs -39 +10 M ./cabal/Distribution/Simple/Build.hs -4 +4 M ./cabal/Distribution/Simple/Configure.hs -6 +9 M ./cabal/Distribution/Simple/Haddock.hs -4 +4 M ./cabal/Distribution/Simple/LocalBuildInfo.hs -50 +110 M ./cabal/Distribution/Simple/PreProcess.hs -4 +4 M ./cabal/Distribution/Simple/SrcDist.hs -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=… Thu Jul 7 18:30:12 PDT 2011 Duncan Coutts <duncan(a)community.haskell.org> * Couple of trivial code changes M ./cabal/Distribution/Simple.hs -1 M ./cabal/Distribution/Simple/PreProcess.hs -5 +3 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): "Relax some dependencies"
by Ian Lynagh 06 Jul '11

06 Jul '11

Wed Jul 6 12:26:19 PDT 2011 Ian Lynagh <igloo(a)earth.li> * Relax some dependencies M ./cabal/Cabal.cabal -3 +3 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

Re: [Hackage] #543: ghc global package db should live in /var not /usr
by Hackage 05 Jul '11

05 Jul '11

#543: ghc global package db should live in /var not /usr ----------------------------+----------------------------------------------- Reporter: nr | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- Comment(by duncan): Note of course that following the `./configure` file layout convention and having relocatable packages are orthogonal. It is still possible to `./configure` and put everything under one prefix (e.g. /opt/ghc-x.y/). Then whether ghc defaults to one or the other scheme is up to the packager. Generic binary tarballs should probably be relocatable and self contained, while Linux distros will continue to use their current scheme. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/543#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

Re: [Hackage] #543: ghc global package db should live in /var not /usr
by Hackage 24 Jun '11

24 Jun '11

#543: ghc global package db should live in /var not /usr ----------------------------+----------------------------------------------- Reporter: nr | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- Comment(by Syzygies): The real problem is accepting the dubious, ancient custom of scattering an installation across multiple bin, lib, share, doc directories rather than localizing everything in say /usr/local/ghc-7.0.4a. Giving the installing user write permission for this directory avoids the need for root permissions, and can insure that the install actually takes place exclusively within this directory. I'm baffled how others do side-by-side installs of different versions of GHC without following such a scheme. I'm opposed to this /var proposal. The convention of spraying files across hell and high water is what's broken, and we should do nothing to make matters worse. Adding /var to the spray list would be making matters worse. A number of modern projects similar to GHC default to localized installs in the style of /usr/local/ghc-7.0.4a; we should do the same. GHC is important enough to warrant a separate PATH entry, or aliases in /usr/local/bin. "This is one reason we do per-user installs by default." Cabal should check for a global config file parallel to `which ghc` according to the current path, defaulting to global installs and ignoring ~/.cabal/config if possible. The existence of ~/.cabal/config is like a global variable, and interferes with multiple side-by-side installations of GHC. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/543#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): "Add files needed by the GHC build system"
by Ian Lynagh 24 Jun '11

24 Jun '11

Thu Jun 23 17:36:54 PDT 2011 Ian Lynagh <igloo(a)earth.li> * Add files needed by the GHC build system A ./LICENSE A ./ghc-packages View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

Re: [Hackage] #179: support GHC's main-is extension
by Hackage 22 Jun '11

22 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by Evi1M4chine): Replying to [comment:26 cjs]:[[br]] To be honest, I’m no fan or build systems. A compiler that doesn’t figure out dependencies and how to make a executable from it all for itself, is just deeply wrong in my eyes. This is essentially all you should ever ''have'' to do, no matter how the sources are structured: {{{ compile $allExternallyCompiledParts $allMySourceDirectories }}} (Of course what you ''could'' do, should include optimization, to what to compile it and code checking / debugging. But that should be it.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:27> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #179: support GHC's main-is extension
by Hackage 22 Jun '11

22 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by cjs): Giving each target its own build directory works, but causes a lot of extra building when you have a lot of targets in a large system. E.g., in one recent major project I had perhaps a hundred source files and 20-30 targets (including test targets--only a dozen or so were production targets). Separate build dirs for each target would have turned a 5-10 minute full build into 2-3 hour full build. I was told the solution is to use libraries, but when you have test framework "main" targets within a number of library modules, that still doesn't fix the problem unless you also do do some interesting work on your build system to build a library and then a single module within that library separately that links to the rest of the library. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:26> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #179: support GHC's main-is extension
by Hackage 21 Jun '11

21 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by Evi1M4chine): Replying to [comment:23 cjs]:[[BR]] I always thought of it like this: * The `--main-is` for a build target doesn’t change. * Every build target should have its own separate build directory. * If `--main-is` ''is'' changed, that invalidates the object file that was previously set as main, causing it to get deleted. * As early as possible, it is checked that there can always be just one module that has a program entry point. Those rules would prevent the problem, no? P.S.: Aren’t universal binaries executables with two program entry points, where the correct one for the arch is chosen by the OS? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:25> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0