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 |