On Fri, Feb 05, 2021 at 09:57:48PM -0800, Greg Steuck wrote: > James Cook <[email protected]> writes: > > >> Would you like to try your hand in extending post-install target with > >> some man formatting magic like we have in other ports? > > > > Done (commit a1c5aec8) in my "git-annex" branch: > > > > https://github.com/falsifian/ports/commits/git-annex > > Very nice! > > > It's not pretty. I replicated some logic from Build/Man.hs, which is > > called from Setup.hs. > > Some quick observations. Makefile allows line-continuation with \ and > this is how people write long command lines. The for loop would be more > readable if it were split like that. I also don't see a lot of places in > ports make files with quotes around variables. I suspect we just expect > people to not go nuts with spaces in directory names when building > ports.
Thanks. I split up the long command and removed quotes: https://github.com/falsifian/ports/commit/e24278e3c1d7fca1b3c4961a0e81a5bb2ca5bcf0 Two notes: * Currently "make post-build" fails if you run it twice. Adding -p in "mkdir ${MAN1_STAGING_DIR}" would fix that. I don't know if it's better to fail or not if "make post-build" gets run more than once. * I see you put "@" before the ln -s lines. I wasn't sure whether to add them to the other commands. The output is not that interesting. > > Normally cabal v2-install would do that work for > > us (putting the result in .cabal/store/ghc-XXX/git-annex-XXX) but I > > don't know if it's worth getting that working. > > > > Caveat: I took a shortcut when testing this: instead of re-running > > "make build" I just made the post-build target after adding this in. > > I'll try building from scratch later if you don't beat me to it. > > I believe `make rebuild` should reuse the cabal built pieces. post-build > seems like a reasonable place for this kind of work. Alternatively > sticking those man-formatting commands into post-install also seems > acceptable to me. I confirmed the port works by installing on a different machine. One hitch: I needed to manually uninstall the current cabal-install port because it conflicts with the new cabal port. Is there a way to tell ports that cabal is a successor to cabal-install? (I considered putting the man-building commands in post-install, but I wasn't sure where to put the staging directory if I did that. I wanted the staging directory because I assumed I should use the ${INSTALL_MAN} macro if possible to put the files in their final place.) > > On that branch I also removed the runtime dep on devel/git-lfs (it's > > just one of a large number of optional backends). > > Good call. > > >> From what I gathered the v2-install target is largely unusable for > >> installing packages outside of .cabal tree. At least neither I nor > >> FreeBSD maintainer found a way to leverage that. Hence the manual > >> install flow. > > > > I probably don't know all the subtleties, but when I run > > "cabal v2-install", I get a nice set of files under > > ~/.cabal/ghc-XXX/git-annex-XXX, including the man pages and all three > > needed binaries. I would guess that just copying those files to the > > destination would do the trick for most cabal executable packages, but > > I haven't actually tried it. Maybe it's better to be cautious. > > I'll dig into this a bit. I simply didn't need to worry about this up > until now as all the other ports don't do much custom Setup.hs work. I don't know if there will be any cases other than man pages and git-annex's command aliases. Not sure how much effort it's worth. > Thanks > Greg -- James
