| 1 |
On Tue, 10 Mar 2009 00:25:49 +0100 |
| 2 |
Christian Faulhammer <fauli@g.o> wrote: |
| 3 |
> > Uh, you *are* testing things that use a library before you stable |
| 4 |
> > that library, right? |
| 5 |
> |
| 6 |
> When I was an architecture developer I tried to. But when |
| 7 |
> stabilising a minor version of curl (for example), testing all |
| 8 |
> reverse dependencies is no option. But this broke tests for Bazaar |
| 9 |
> for example in stable. |
| 10 |
|
| 11 |
Then this is a legitimate problem that someone needs to know about and |
| 12 |
fix. So having src_test turned on globally is a *good* thing. |
| 13 |
|
| 14 |
> Badly written Autoconf systems which will break in src_test() with a |
| 15 |
> different version of intltool, which is not a direct dependency. |
| 16 |
|
| 17 |
Again, finding this is good. |
| 18 |
|
| 19 |
> That pitfall hit me several times in the last years. The more, x86 |
| 20 |
> e.g. ranges from embedded Geode platforms to dual core desktop |
| 21 |
> systems and running the sqlite test suite on the first is no fun. As |
| 22 |
> a user I would not accept two hours of build time. Test-driven |
| 23 |
> development is great, but not so widely used as one could wish it to |
| 24 |
> be. |
| 25 |
|
| 26 |
And if you're on an especially slow platform, as a user you can turn |
| 27 |
tests off. |
| 28 |
|
| 29 |
-- |
| 30 |
Ciaran McCreesh |
Archives