Le 20 oct. 07 à 22:36, Ryan Schmidt a écrit :
In the sbcl port I see this code:
default_variants +test
variant test { test.run yes test.dir ${worksrcpath}/tests test.cmd sh test.target run-tests.sh }
Now, I was led to believe that this is silly and should be rewritten as follows:
test.run yes test.dir ${worksrcpath}/tests test.cmd sh test.target run-tests.sh
I was told that using "test.run yes" does not automatically run the tests. Rather, you must "sudo port test sbcl" if you want the tests. In light of this, why would anyone want to wrap this in a "test" variant? Who would ever want to switch it off? And isn't there a base bug that makes it so that if you install the port without the test variant, and then upgrade, the test variant gets turned on again? (I haven't tried it, but I thought I remembered hearing that.)
Yes, there is a bug with default_variants, which get enabled again on upgrade.
But I see several ports with a "test" variant, so I wanted to ask if there's something I'm missing here.
The only good reason to write a test variant is when there is some extra configure.args like --enable-tests or additionnal build dependencies like ghc-devel and octave. There is no reason to build the testsuite if you don't want to run it. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org