On Tue, Dec 7, 2010 at 1:50 PM, Brian Gerkey <gerkey@willowgarage.com> wrote:
> On Mon, Dec 6, 2010 at 9:38 AM, Jack O'Quin <jack.oquin@gmail.com> wrote:
>> On Mon, Dec 6, 2010 at 10:55 AM, Brian Gerkey <gerkey@willowgarage.com> wrote:
>>> To address the problem of unwanted dependencies from testing, we've
>>> taken to creating separate test packages (e.g., `test_rospack` has the
>>> tests for `rospack`).  That solves things at a package level [*].  But
>>> you still need somewhere to put, e.g., the `test_camera1394` package.
>>> If it goes in the `camera_drivers` stack, then the stack still has the
>>> test-induced dependencies.  This may or may not be acceptable.  If
>>> it's not, you could create a separate stack to contain the tests; I
>>> don't believe that we've done that yet.
>>
>> I would not want it in the camera_drivers stack for the same reason it
>> should not go in the camera1394 package.
>
>> I don't see anything in ros-pkg/stacks that looks like a collection of
>> tests. I am reluctant to add a test_camera stack at that level, but
>> don't have a better idea, so suggestions are welcome. Would a
>> ros-pkg/stacks/tests subdirectory be awkward?
>
> Just having a tests subdirectory won't be that useful, because we
> would need to release that code, to ensure that tests are run, in
> prerelease and postrelease builds.  Otherwise, we'd have to add some
> special handling to tell Hudson, e.g., also check out the tests
> subdirectory and run some tests from in there.
>
> As hesitant as I am to suggest a potential doubling of stacks,
> creating a `test_camera_drivers` stack may be the best way to go.
> Hopefully this situation (i.e., the tests bring unwanted dependencies
> at the stack level) is uncommon; it feels like something that will
> happen most often with driver-like things.

I'll leave it to Blaise and Patrick to decide if a test_camera_drivers
stack is a good idea.

Unless there is more justification than just some tests for one
package, I doubt it would be worth the effort.

I suppose a test stack could have fairly broad scope, minimizing
dependencies might not matter much.
-- 
 joq