Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Within this context, is a compilation loop, the purpose of which includes having to type "cabal build" over and over, really that outrageous? As the cabal project says in [#5252](https://github.com/haskell/cabal/issues/5252): "the main idea is that since cabal knows which files are in the dependency graph, it is a good place to stick a watch command on them."
The test cases were order sensitive and somehow a change in an upstream dependency changed the order. Here is the only line where this value was being set. The order is being determined by the keys function from Data.HashMap.Strict in unordered-containers. Well that makes sense...it is called unordered containers after all.
Cabal 3.x and nix-style builds is a partial improvement, however it still suffers its legacy, with some of the most fundamental issues unsolved or even not addressed. For example maintenance of installed packages in long runs, stale or broken packages from previous failed builds impede the workings etc. Suggested fix is usually to wipe-out whole storage and rebuild everything from scratch again sic. Even when you are lucky, like avoiding update of ghc at all costs, with new base breaking almost everything, you'll soon end up with tenths or hundreds of gigabytes wasted disk space and significantly slower operations, with half of whole Hackage packages in its their countless iterations. I would already gave up completely, unless I've run across phadej's cabal-extras, which with some minor fixes save my sanity.