| 1 |
Right now - no. It might be a nice feature to add in a conf file |
| 2 |
support later on, but there are a lot of issues with enabling tests. |
| 3 |
|
| 4 |
<begin of long spiel, feel free to bail out on me now> |
| 5 |
The problem with globally enabling SRC_TEST="do" (which is what is |
| 6 |
missing in the generated ebuilds to finalize the enabling of tests) is |
| 7 |
that we don't even do that for ebuilds we do actively maintain. There |
| 8 |
are a few reasons for that - some tests are unavoidably interactive; |
| 9 |
some are just plain broken; some require conditions we can't provide, |
| 10 |
like a db to talk to, an X display to flash on, or an outbound internet |
| 11 |
connection. Sadly, not all test sets are created equally. For the 'live' |
| 12 |
tree we enable as many as we can, because they can identify potential |
| 13 |
problems - but we don't do it for all ebuilds. |
| 14 |
|
| 15 |
The ebuilds generated by g-cpan follow a very generic template with a |
| 16 |
few fill in the blanks. There is no way to know in advance (at least via |
| 17 |
g-cpan) what you might be dealing with when you enable tests. So, |
| 18 |
because g-cpan is supposed to be a generic engine, it doesn't enable |
| 19 |
tests, much in the same way it also enables all possible keywords at |
| 20 |
once, something we couldn't do in the live tree (not a single pass :) |
| 21 |
</ spiel> |
| 22 |
|
| 23 |
Hope that explains it a bit better :) |
| 24 |
|
| 25 |
On Fri, 5 Aug 2005 15:35:30 +0100 |
| 26 |
Chisel Wright <chisel@×××××××××××××.uk> wrote: |
| 27 |
|
| 28 |
> I've noticed that g-cpan doensn't do "make test". |
| 29 |
> |
| 30 |
> Is there something I can toggle/enable/set to make it perform the test |
| 31 |
> phase? |
| 32 |
-- |
| 33 |
gentoo-perl@g.o mailing list |
Archives