Hi James, James Cook <[email protected]> writes:
> Incidentally, I asked the maintainer how man pages are supposed to be > installed, and they said it's best to use the Makefile if you want a > complete installation. Probably not worth changing our port, but > something to keep in mind in case this turns out to be a pattern. > https://git-annex.branchable.com/bugs/__91__Patch__93___fix___34__mdwn2man__58___cannot_execute_-_...__34__/ Thanks. We can leave this as is unless it proves more trouble than adjusting the recipe going forward. > 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. > * 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. > * 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. > 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. > * nixpkgs (the only package system I'm really familiar with) deals > with Cabal by automatically generating package descriptions for > everything on hackage. I wonder if something along those lines > would be do-able. cabal-bundler --openbsd is a play in this area. I just limited it to the absolute minimum I could get away with. > 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. > * 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 > * 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. Thanks Greg
