Use `--merge-install` for colcon so that `gz` can be found during build

[azeey]

Our windows builds are not running UNIT_gz_TEST or similar tests because gz is not found at build time. This is because we are using isolated builds and colcon doesn't seem to expose the bin directories of each of the dependencies at build time. Using --merge-install fixes this and this is also what we've been recommending for our users (see https://gazebosim.org/docs/harmonic/install_windows_src#building-the-gazebo-libraries)

[azeey]

Test build:

[j-rivero]

Let's discuss first if we are prepared to merge this since it can potentially trigger new test / new test failures all across the Windows builds.

[mjcarroll]

This is because we are using isolated builds and colcon doesn't seem to expose the bin directories of each of the dependencies at build time.

If we preserve isolated installs, we can also generate colcon hooks to set the path. There may be some value in doing this to make sure that we aren't inadvertently depending on a merged install for one reason or another.

[azeey]

If we preserve isolated installs, we can also generate colcon hooks to set the path. There may be some value in doing this to make sure that we aren't inadvertently depending on a merged install for one reason or another.

The issue is that gz is not found by CMake during configuration. Do colcon hooks apply during build time?

[mjcarroll]

Do colcon hooks apply during build time?

I thought that they did such that CMAKE_PREFIX_PATH/LD_LIBRARY_PATH, etc would be set correctly for dependencies, but I haven't verified it first hand.

It does have the disadvantage of adding a colcon-specific mechanism in this case, but the benefits may outweigh that.

[azeey]

Do colcon hooks apply during build time?

I thought that they did such that CMAKE_PREFIX_PATH/LD_LIBRARY_PATH, etc would be set correctly for dependencies, but I haven't verified it first hand.

It does have the disadvantage of adding a colcon-specific mechanism in this case, but the benefits may outweigh that.

So CMAKE_PREFIX_PATH/LD_LIBRARY_PATH appear to be set properly without any hooks. That's why the build succeeds. But I don't think PATH is being set. I'm guessing that only happens at runtime (e.g. colcon test), but I might be completely off.

[azeey]

Adding package.xmls fixes this problem because colcon knows how to add the correct paths based on the package.xml as opposed to scraping find_package calls. So maybe we can merge this once all the Harmonic package.xml PRs are in with green CI.