> > A few notes / questions: > > > > * I fixed a couple of typos in > > > > https://github.com/falsifian/ports/commit/98111e702634842865a3d27675b6848e3fb2b7ca > > > > * I added example usage for cabal-bundler. I hope I got it right: > > > > https://github.com/falsifian/ports/commit/f21cb097f215831b1d08443f9074073895a13731 > > Neat. I'll pick these up. > > > * If I find more time to work on this, should I polish my git-annex > > port, or is there something more useful I could be doing with your > > Cabal infrastructure? (I installed darcs and it seems to work.) > > Great! I don't think there's much else to do besides waiting for > cabal-install 3.4.0.0 to be pushed to Hackage. Depending on how this > aligns with 6.9 release we may or may not ship it then. > > You could try to build your own port of a Haskell binary you use that we > don't have yet. Your experience will likely tell us something about the > level of maturity of this infra.
The only unported Haskell binaries I use are personal projects that are not on Hackage. I could try locally porting one of those as an experiment. > > * I tried to enable tests, partly because Darcs has a comprehensive > > test suite. I ran into some trouble. My WIP is here: > > > > https://github.com/falsifian/ports/commit/99cb0e33e2263cf15979a19bf068d3ffff45630c > > One problem is that cabal-bundler doesn't seem to be outputting test > > dependencies. > > I keep track of this issue in https://github.com/blackgnezdo/ports/issues/13. > See if you agree with my assessment there. Thanks, I commented there. > > * It's a pity that your approach doesn't allow Cabal-based ports to > > share dependencies. > > I chose to trade-off compute to gain simlpicity and flexibility: > https://github.com/blackgnezdo/ports/issues/3#issuecomment-650823377 > > Until this choice turns to be expensive enough to cause port builders to > complain I'm inclined to keep this approach. Okay, that's reasonable. My only concern: later on if people do complain and it's decided it's a real problem, is there a path forward that builds on what you've already got? Or would you have to start from scratch to address it? (I could complain already, but for me at least your solution is a definite improvement over the status quo. The build times aren't the end of the world.) > > Some thoughts on mitigating or solving this, in decreasing order of > > plausability: > > * Is it possible to hand-pick some particularly slow ones, make > > packages for them, and then tell Cabal to use those packages? E.g. > > aeson takes a while to build. > > Sadly this will move towards tree-wide configuration management which > was a very non-fun thing to do as you experienced first-hand trying to > deal with a ton of ports when you tried to add git-annex. Maybe there could be a rule of thumb, like adding a reusable port is only worth it if it reduces the total time to build all ports by at least X hours? I don't know if there are any libraries that meet that definition for an appropriate value of X. > > I guess it would be ugly to fill the ports tree with hundreds(?) of > > directories each with an auto-generated package. I'm not sure if > > there's a way to smoosh it all into one big file. E.g. I see > > there's something called "multi-packages", but I'm guessing that's > > not designed to handle hundreds of subpackages. > > I've seen how these things play out in much bigger code bases with many > people over time. We don't have enough people working on ports@ to > manage this. That makes sense. I imagine your approach will keep things easier for maintainers: e.g. I'm not going to accidentally break darcs by updating the dependencies of git-annex. > > * Is it possible to cheat, by having all the Cabal-based ports share > > their Cabal directory? So if I build darcs then git-annex, Cabal > > has access to all the build products from darcs when it builds > > git-annex. I guess one problem is this might make the build output > > depend on the order in which you build things, if Cabal > > opportunistically uses whatever versions are there. > > The root of the problem is GHC compilation speed. My preferred and > universally useful optimizations would be: > > * Use/build something like ccache for ghc > * Speed up ghc itself Those would be cool! > > * Are you planning to commit these changes all at once? Or is there > > some way to have an intermediate state where both old-style and > > new-style packages work? > > I don't see how it would be possible to have the old and new coexist. > ghc-8.10 is incompatible with the haskell ports in the tree. My plan is > to land this as a bundle. I wrote it up in an email to ports@ before. I didn't know about the incompatibility. Maybe there could be two separate ghc versions for a while, but I guess that's more trouble than it's worth. > Thanks > Greg -- James
