Uses compile definitions to avoid having to source install when running the tests.

[francocipollone]

Proposes a solution for #218 (comment)

Signed-off-by: Franco Cipollone franco.c@ekumenlabs.com

[agalbachicar]

Disclaimer: I doubt this is the right way to do things. I think we should consider using https://github.com/ament/ament_cmake/blob/master/ament_cmake_core/doc/resource_index.md , that said, it could be an implementation detail of another API we propose for the sake of this bug in particular.

Why not rely on utility::FindResource? Can't we inject another path to look at for testing purposes? I think that would be the cleaner way to avoid touching every single path resolution.

[francocipollone]

Disclaimer: I doubt this is the right way to do things. I think we should consider using https://github.com/ament/ament_cmake/blob/master/ament_cmake_core/doc/resource_index.md , that said, it could be an implementation detail of another API we propose for the sake of this bug in particular.

I agree that using ament_index for finding resources between different packages is the way to go. e.g: Using maliput_malidrive's resources from delphyne
It is something we should tackle at some point -> maliput/maliput_infrastructure#222

In this particular case, we could be benefited from it, however here we just want to address resources within the package. So for me moment, seems to make sense to go for an easier solution.

Why not rely on utility::FindResource? Can't we inject another path to look at for testing purposes? I think that would be the cleaner way to avoid touching every single path resolution.

utility::FindResourceInPath expects to receive a custom environment variable. I could clean it up a bit but not using the FindResource tool.

[francocipollone]

@agalbachicar wdyt?

[agalbachicar]

LGTM