This project is mirrored from https://github.com/haskell/Cabal.
Pull mirroring updated .
 21 Jul, 2017 1 commit


Moritz Angermann authored
Add more staticlib support

 20 Jul, 2017 3 commits


Francesco Gazzetta authored
Return a monomorphic TargetsMap from selectPlanSubset and put it in the final ProjectBuildContext. This causes slight duplication in CmdRun.hs, but not as bas as when we didn't return anything. In exchange, the final return type is much simpler. Note that CmdConfigure returns an empty TargetsMap, as configure doesn't accept targets.

Francesco Gazzetta authored
Previously, the extraction of the target from the targetStrings was done twice: inside the function passed to 'runProjectPreBuildPhase' and right after it. Now 'runProjectPreBuildPhase' is able to return information from that function, and the duplication was removed, along with some assumptions about the number of targets.

Mikhail Glushenkov authored
[ci skip]

 19 Jul, 2017 1 commit


Francesco Gazzetta authored
This enables the executale to find the datafiles in inplace builds. Fixes #4120

 18 Jul, 2017 1 commit


Mikhail Glushenkov authored

 17 Jul, 2017 1 commit


Mikhail Glushenkov authored
[ci skip]

 16 Jul, 2017 1 commit


Amir Mohammad Saied authored

 15 Jul, 2017 4 commits


Amir Mohammad Saied authored

Francesco Gazzetta authored

Francesco Gazzetta authored

Amir Mohammad Saied authored

 14 Jul, 2017 1 commit


Francesco Gazzetta authored

 10 Jul, 2017 4 commits


Francesco Gazzetta authored

kristenk authored

kristenk authored
The conflict set that represents the option to not choose a value for a goal, 'initial', has two purposes: 1. 'initial' contributes to a node's conflict set, because it is unioned with the other conflict sets under the same choice node, if the current variable is contained in all of them. 2. 'initial' contributes to the conflict count. When it is unioned with the other conflict sets, it is also added to the ConflictMap. Previously, 'initial' was treated as the first of a node's children for (1) and the last of the children for (2). This refactoring treats 'initial' as the last child in both cases, to make the code clearer, and renames it to 'lastCS'. There should be no change in behavior.

kristenk authored
In Explore.hs, the solver calculates a conflict set corresponding to the option to not choose a value for each goal, called 'initial'. That conflict set should be added to the ConflictMap when the current goal causes a conflict. However, there was a bug, and the solver added 'initial' to the ConflictMap at every level. The bug meant that the solver preferred all goals that it had already chosen. If a new goal started to cause conflicts, it would take a while for the solver to start preferring the new goal over the ones that it had previously seen. See #4595 for an example where this problem caused longer backjumps and slowed down the solver. Testing I ran "cabal install dryrun" for all packages on Hackage with master and the branch with a 90 second timeout, GHC 8.0.1, and index state 20170708T04:20:18Z. Then I filtered out all packages where both runs had the same result (success or failure) and the times were within 10%. I repeated that process three times to eliminate packages that had different run times due to noise. Then I ran "cabal install dryrun maxbackjumps=1" on the remaining packages and averaged three runs. Since this branch changes a goalordering heuristic, I expected a lot of changes in run time in either direction. Out of 105 changes, 83 were faster, 20 were slower, and 2 involved a timeout on both branches. (The two that timed out had different run times before I removed the backjump limit.) package master result master time (seconds) branch result branch time (seconds) speedup AesonBson solution 3.06 solution 2.59 1.18 DisTract no solution 1.48 no solution 1.34 1.1 GPipeExamples timeout 90.01 no solution 2.11  GuiTV solution 2.54 solution 16.05 0.16 Phsu solution 3.49 solution 1.83 1.9 Ranka no solution 2.05 no solution 1.65 1.25 RlangQQ no solution 2.97 no solution 1.89 1.57 SourceGraph timeout 90.04 no solution 11.53  Validation no solution 2.1 no solution 6.59 0.32 WebCont no solution 2.04 no solution 1.6 1.28 acmeeverything timeout 90.02 timeout 90  aesont solution 2.04 solution 1.81 1.13 alsagui no solution 1.62 no solution 1.86 0.87 aviationcessna172diagrams no solution 2.56 no solution 2.29 1.12 awsdynamodbconduit no solution 2.22 no solution 1.83 1.22 azureservicebus no solution 5.18 no solution 2.87 1.8 bamboothememinihtml5 no solution 2.51 no solution 2 1.26 bitcoinpaymentchannel solution 3.42 solution 2.73 1.25 bittorrent no solution 2.75 no solution 2.4 1.15 blazebuilderenumerator no solution 1.62 no solution 1.88 0.86 blunt solution 2.99 solution 2.5 1.19 cash no solution 1.33 no solution 1.53 0.87 cheapskateterminal no solution 2.04 no solution 1.62 1.26 clckwrkspluginbugs no solution 3.85 no solution 5.78 0.67 cmdtheline no solution 1.96 no solution 1.63 1.2 colchis no solution 1.99 no solution 2.23 0.89 colladatypes no solution 1.86 no solution 1.66 1.12 convertibletext solution 1.61 solution 1.83 0.88 cqrsexample no solution 2.64 no solution 2.32 1.14 dixi solution 4.44 solution 4.03 1.1 ethereumclienthaskell no solution 1.84 no solution 2.45 0.75 flowdock no solution 2.46 no solution 3.19 0.77 geniserver no solution 5.34 no solution 4.84 1.1 ghcimportedfrom solution 4.59 solution 2.9 1.58 gps2htmlReport solution 3.08 solution 5.58 0.55 guardedrewriting solution 1.54 solution 1.34 1.14 hack2handlerhappstackserver no solution 1.76 no solution 2 0.88 halmatelegrambot solution 4.27 solution 3.37 1.27 happstutorial no solution 2.08 no solution 1.86 1.12 happstack no solution 3.08 no solution 5.86 0.53 happstackfacebook timeout 90.01 timeout 90.03  haskelldbhsqlmysql no solution 1.73 no solution 1.5 1.16 hdbi no solution 1.92 no solution 1.66 1.15 hdbipostgresql no solution 3.05 no solution 1.95 1.56 hdbisqlite no solution 1.91 no solution 1.69 1.13 hexpatiteratee no solution 2.61 no solution 1.84 1.42 histpl no solution 2.69 no solution 2.36 1.14 hscd no solution 2.53 no solution 1.59 1.59 httpclientlens no solution 3.63 no solution 1.96 1.85 hubris no solution 3.62 no solution 1.63 2.22 infinity no solution 1.34 no solution 1.5 0.89 iterateeparsec no solution 2.01 no solution 1.74 1.16 jsontogo no solution 1.86 no solution 1.65 1.13 lat no solution 2.87 no solution 1.86 1.55 liquidhaskell solution 3.34 solution 2.25 1.48 manateecore no solution 1.79 no solution 1.6 1.12 manateecurl no solution 8.44 no solution 2.73 3.09 manateeeditor no solution 5.05 no solution 2.81 1.8 manateefilemanager no solution 29.09 no solution 2.96 9.82 manateeimageviewer no solution 1.78 no solution 1.57 1.13 manateemplayer no solution 8.98 no solution 4.05 2.22 manateeterminal no solution 3.19 no solution 2.41 1.32 minimung no solution 1.86 no solution 1.57 1.19 monoids no solution 3.02 no solution 2.68 1.13 mprover no solution 1.89 no solution 1.54 1.23 ms no solution 8.04 no solution 4.35 1.85 musicsibelius solution 3.1 solution 2.5 1.24 nerf solution 22.54 solution 3.09 7.29 nomyxapi solution 5.46 solution 4.39 1.24 nomyxlibrary solution 2.08 solution 1.86 1.11 nomyxserver no solution 4.83 no solution 3.92 1.23 opaleyeclassy no solution 2.07 no solution 3.58 0.58 openflow no solution 1.95 no solution 1.66 1.18 ot no solution 3.37 no solution 1.95 1.73 paypalapi no solution 1.89 no solution 1.64 1.15 pdfslaveserver no solution 3.21 no solution 2.15 1.49 phooey solution 2.55 solution 16.24 0.16 pipescerealplus solution 1.85 solution 1.65 1.12 pocketdns no solution 2.71 no solution 2.08 1.3 pontariusmediaserver no solution 2.29 no solution 2.7 0.85 precis no solution 2.53 no solution 3.23 0.78 proveeverywhereserver no solution 2.19 no solution 1.92 1.14 quickbooks no solution 5.86 no solution 5.17 1.13 rbpcpapi solution 2.35 solution 2.13 1.11 reacthaskell timeout 90.02 no solution 71.21  regexxmlschema no solution 1.34 no solution 1.51 0.89 remotejsonserver solution 2.1 solution 1.8 1.16 scholdocciteproc no solution 3 no solution 1.92 1.57 scionbrowser no solution 5.21 no solution 4.65 1.12 semdoc no solution 4.21 no solution 3.04 1.39 servantauthtokenrocksdb no solution 4.68 no solution 2.32 2.02 snapletauthacid no solution 2.25 no solution 1.99 1.13 snapletstripe no solution 3.46 no solution 2.97 1.16 sssp no solution 3.3 no solution 2.79 1.18 target solution 2.8 solution 2.11 1.32 tlsextra no solution 2.74 no solution 2.36 1.16 twentefprosetree no solution 1.69 no solution 1.97 0.86 twitterenumerator no solution 28.39 no solution 2.16 13.15 waimiddlewarecache no solution 1.95 no solution 1.56 1.25 waimiddlewarecatch no solution 1.9 no solution 1.54 1.24 waimiddlewareroute solution 11.9 solution 1.62 7.34 xml2json no solution 2.27 no solution 1.68 1.35 yesodauthaccountfork solution 3.33 solution 2.87 1.16 yesodcomments no solution 25.6 no solution 14.44 1.77 yesodpure solution 7.99 solution 4.45 1.79

 07 Jul, 2017 1 commit


ivanm authored
I don't know if it was there for a reason, but it looks like it wasn't.

 05 Jul, 2017 1 commit


Mikhail Glushenkov authored

 04 Jul, 2017 5 commits


Francesco Gazzetta authored

Francesco Gazzetta authored

Francesco Gazzetta authored
This reverts commit aa682f9e.

Francesco Gazzetta authored

Francesco Gazzetta authored

 03 Jul, 2017 8 commits


Herbert Valerio Riedel authored
This extends the capabilities of `allow{newer,older}` to allow for more finegrained scoping to control more precisely which packages and constraints a relaxation is applied to. See updated documentation for more details.

Francesco Gazzetta authored

Francesco Gazzetta authored

Francesco Gazzetta authored

Francesco Gazzetta authored

Francesco Gazzetta authored

Francesco Gazzetta authored

Francesco Gazzetta authored

 02 Jul, 2017 2 commits


Francesco Gazzetta authored

Francesco Gazzetta authored

 20 Jun, 2017 1 commit


bardur.arantsson authored
The idea here is to break the dependency that has crept in from the "Solver" into the "Client". (If there's ever going to be a separate solver then the dependency would become a big problem.)

 18 Jun, 2017 1 commit


kristenk authored
A DependencyReason contains flags paired with values FlagTrue, FlagFalse, or FlagBoth, where FlagBoth means that the dependency was introduced by either value of the flag and was lifted out of a conditional. In the previous commit, when a dependency led to a conflict, all flags in the DependencyReason were added to the error message and conflict set. This commit avoids adding flags with value FlagBoth to the conflict set, because they can have a negative effect on goal order: After the solver encounters a conflict involving such a flag, it starts to prefer the flag when choosing goals, due to the solver's conflict counting feature. The solver shouldn't prefer the flag goal because it didn't actually need to choose the flag to see the dependency. Flags with value FlagBoth are still useful for error messages, though. I measured the performance of the last two commits by comparing commit fc3ef2a7 (master) with this commit. I did all testing with GHC 8.0.1 and 'indexstate(hackage.haskell.org) = 20170611T02:16:39Z'. I ran each version of cabal (cabal install dryrun) on each package on Hackage and looked for packages with a difference in run time of at least 10%. Then I reran cabal on those packages to narrow down the list further (The results were noisy). Here are the average run times from five runs with the remaining packages: package master result master time (seconds) branch result branch time (seconds) speedup concraft backjump limit 5.67 backjump limit 4.89 1.16 forml backjump limit 10.26 backjump limit 8.85 1.16 hackhandlersimpleserver backjump limit 6.28 no solution 1.96 3.21 hackmiddlewareclientsession backjump limit 17.86 no solution 1.95 9.14 haskore backjump limit 5.21 no solution 1.67 3.12 haskoresynthesizer no solution 23.14 no solution 2.21 10.49 languagegcl no solution 3.06 no solution 2.31 1.33 ms backjump limit 61.68 no solution 7.95 7.76 nerf solution 4.1 backjump limit 5.87 0.7 puzzledraw solution 56.28 solution 5.31 10.6 reacthaskell backjump limit 44.23 backjump limit 14.46 3.06 reflextransformers no solution 2.18 no solution 1.9 1.15 shpider backjump limit 7.44 solution 1.88 3.95 thorn backjump limit 11.11 backjump limit 4.44 2.5 Both versions of cabal hit the backjump limit in four of the cases, so they don't really tell us which version performed better. All but one of the others are improvements. I looked at a few of the logs, and, as far as I can tell, most of the improvements are due to flags being used in conflict counting. This behavior is similar to #4147, which was reverted. The log for 'nerf', the one package that had worse performance, showed that the solver chose some flags earlier, but I didn't see any other reason for the slowdown. The solver found a solution when I used 'maxbackjumps 1'. These differences in run time are caused by differences in goal order and/or backjumping, but I also wanted to compare performance when the solver went through similar steps on master and the branch. I found two commands that led to very similar v3 output between the cabal versions. Presumably, package flags didn't cause many conflicts in these runs. cabal install dryrun maxbackjumps 1 giglib happstack cabal install dryrun yesod I took the average of three runs. There wasn't a big difference between master and the branch. packages result master time (seconds) branch time (seconds) master memory (MB) branch memory (MB) giglib, happstack no solution 30.02 30.70 245 245 yesod solution 3.53 3.55 239 239.3

 17 Jun, 2017 1 commit


kristenk authored
This commit changes the way that the solver tracks the variables that introduce dependencies, in order to fix some bugs that prevented the solver from tracking individual flags. I refactored Dep, the type that represents a builddepends or buildtooldepends dependency, so that it stores the package, flag, and stanza choices that introduced the dependency. That information is stored in a field of type DependencyReason. The DependencyReason is available to any solver phase that needs to create conflict sets, such as "build" or "validation". Whenever there is a conflict involving a dependency, the solver creates a conflict set and a log message using the dependency's DependencyReason. This means that the solver only needs to calculate the dependency reasons once, in IndexConversion.hs, rather than every time they are used, i.e., in Builder.hs (for goal reasons), Validate.hs, and Linking.hs. Another difference between this commit and master is the dependencies between solver variables. On master, each dependency or variable is introduced by exactly one other variable. For example, if package x has a flag y, which controls a dependency on package z, then the three variables depend on each other in a chain, x > y > z. If z can't be satisfied, the solver backjumps to its cause, y, and if flipping y doesn't help, it continues backjumping to y's cause, which is x. In contrast, this commit allows each dependency to be introduced by a package and any number of flags and stanzas. So z's DependencyReason would contain both x and y. Storing all flags that introduced a dependency allows the solver to correctly calculate conflict sets when there are nested conditionals. We no longer need to combine each package's flags into a single conflict set variable. This commit removes the 'simplifyVar' function and adds flag variables directly to conflict sets. See issue #4391. This commit makes another minor change. In this commit and master, if a dependency appears in the if and else blocks of a conditional, the solver lifts it out of the conditional. Previously, the solver behaved as if the flag did not introduce the dependency. This commit adds the flag variable to the conflict set or error message if the dependency is involved in a conflict. This change doesn't affect correctness, but I think it improves the error messages, since it gives the whole reason that each dependency was introduced.

 14 Jun, 2017 1 commit


kristenk authored
This just moves some functions and types into Validate.hs in preparation for #4391.

 04 Jun, 2017 1 commit


Moritz Kiefer authored
fixes #4521

 19 May, 2017 1 commit


Herbert Valerio Riedel authored
This appears to be somewhat redundant, since there's also the SetupWrapper hack in place which also filters out `+timestamp` for externally invoked commands other than `configure`, but it's "good style" to keep `filterConfigureFlags` in sync for the sake of consistency.
