Support running cabal v2-test

[blackgnezdo]

This may require a separate test-only manifest and careful distfiles tracking. This fragment will probably be useful.

modified   devel/cabal/cabal.port.mk
@@ -125,3 +125,12 @@ do-build:
 do-install:
 	@${MODCABAL_INSTALL_TARGET}
 .endif
+
+MODCABAL_TEST_TARGET = \
+	cd ${WRKBUILD} \
+	&& ${MODCABAL_CABAL} v2-test --offline --disable-benchmarks
+
+.if !target(do-test)
+do-test:
+	${MODCABAL_TEST_TARGET}
+.endif

[blackgnezdo]

A more honest attempt is in falsifian@99cb0e3 which still ran into some limitations of the currently available cabal.port.mk.

[blackgnezdo]

The main reason to defer or not ever implement this feature is this will require extra complexity in ports infra (cabal.port.mk). At the very least we'll have to classify the dependencies into 'main' and 'test' buckets. While there's value in exposing the test functionality to ports flows, it doesn't obviously pull its weight.

I'm inclined to say we should manually run cabal v2-test when importing a port and then rely on the OS not changing under us in an incompatible manner.

[falsifian]

Two thoughts:

• Could we just include all the build and test dependencies, without trying to separate them? If I understand right, the only cost is some unnecessary fetches for people who want to build and not test. (I haven't been able to get testing working, so maybe I don't understand.) The benefit is you stay within the normal ports testing framework. I don't know if that's a net gain.

• I haven't been able to test a port, even manually. Have you been able to? If you stick with manual testing only, it would be nice to have instructions, e.g. in cabal.port.mk. Here's an example attempt:

falsifian moth ~ $ cd /usr/local/ports/pobj/darcs-2.16.2/darcs-2.16.2 && doas -u _pbuild sh -c 'HOME=/usr/local/ports/pobj/darcs-2.16.2 cabal v2-test'
Warning: No remote package servers have been specified. Usually you would have
one specified in the config file.
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: random-1.2.0 (user goal)
[__1] trying: splitmix-0.1.0.3 (user goal)
[__2] rejecting: splitmix:*bench (cyclic dependencies; conflict set: random,
splitmix)
[__1] fail (backjumping, conflict set: random, splitmix)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: random, splitmix