Why a "test" variant?

[N_Ox]

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 at macports.org