how do I use download_test_data()?

edit

I am trying to migrate a rosbuild package to catkin. It has unit tests which require moderately large data files stored on pr.willowgarage.com. The rosbuild version did it like this:

rosbuild_download_test_data(
  http://pr.willowgarage.com/data/velodyne/32e.pcap
  tests/32e.pcap
  e41d02aac34f0967c03a5597e1d554a9
  )

So, I changed that to invoke download_test_data() with identical parameters.

But, my tests can't find the data. Formerly they did it this way:

<!-- start read with example PCAP file -->
<node pkg="velodyne_driver" type="velodyne_node" name="velodyne_node">
  <param name="model" value="32E"/>
  <param name="pcap" value="$(find velodyne_driver)/tests/32e.pcap"/>
</node>

Now it fails:

[FATAL] [1369196347.360283641]: Error opening Velodyne socket dump file.

I finally discovered a download_data_tests_32e.pcap make target. Invoking it explicitly reads the file into the build tree, and similarly for another test file.

Several related questions:

1. Where is download_test_data() documented?

2. How do it get the the unit test build targets to depend on the download targets?

3. What do I use instead of $(find velodyne_driver)/tests/32e.pcap to resolve the path name?

UPDATE: The download command puts the data here in the build tree: ~/ros/wet/hydro/build/velodyne/velodyne_driver/tests/32e.pcap, which seems reasonable.

But, rospack resolves to the source tree:

$ rospack find velodyne_driver 
/home/joq/ros/wet/hydro/src/velodyne/velodyne_driver

Is that why $(find velodyne_driver)/tests/32e.pcap does not work?

Also, experiment reveals an answer to question 2: the tests and run_tests build targets do depend on the download targets, but the more specific run_tests_velodyne_driver target does not.

UPDATE2: I tried to hack around the problem by using an absolute file name in /tmp:

download_test_data(
  http://pr.willowgarage.com/data/velodyne/32e.pcap
  /tmp/${PROJECT}/tests/32e.pcap
  e41d02aac34f0967c03a5597e1d554a9)

But, download_test_data() insists on prefixing the name with ${PROJECT_BINARY_DIR}/, even when it is fully qualified. It always goes in the build tree, although it cannot be resolved there.