having the "+test" or "+tests" variant propagate causes unexpected builds

[Ken Cunningham]

Various ports implement a “test” or “tests” variant to allow extra features and deps required for testing to be enabled.

This variant, when requested, will propagate up the chain to all the ports, however.  There is no real use case where someone would desire the test/s variant to propagate up.

This generates needless builds, and often enables features people neither need nor want, and then guarantees manual rebuilds, forever, of the involved ports.

I recently came back to a massive building project involving clang and llvm when I was trying to build “mesa +tests”. Because clang-15 and llvm-15 also have a “+tests” variant, and had not yet been installed, port was building those (and possibly others) with the tests variant rather than use the prebuilt binary.

Of course I just aborted the huge llvm/clang-15 build, cleaned them up, and installed them separately. But others would probably not know to do this.

I had suggested a few years ago we might namespace the test/tests variants, by having a convention that the portname be prepended to the test variant, to be more specific and avoid this — but not a widely acceptable idea at that time. So we’re still in the same situation…

Is it possible that a “test” or “tests” variant might not be propagated up the ports chain by base, instead? 


K



PS. A similar thing happens with “+debug” variants, another common variant that you *usually* don’t want propagated up to *every single port* in the chain either. 

This one is occasionally something that people would want up their chain, but it is so fragile of a plan to rely on variant propagation (ie if you have the port installed already, it won’t be reinstalled with the “+debug” variant), that such rare users might best install each port they want to be installed as “debug” do that specifically. Certainly most of us don’t want clang-15 installed with it’s debug variant when you’re trying to debug some little port.