Overwrite CMake configs by default

[azeey]

The default was set to False because we had made a manual change in gz_cmake_vendor that we didn't want to overwrite. However, this causes problems when we introduce new config files. For example, we recently added a .in files to configure PYTHONPATH for each vendor package. Since the default is False, when the vendor package is created by release-tools/release.py, it doesn't include the new config files.

The solution here to programmatically achieve what was done manually in gz_cmake_vendor and set overwrite_cmake_configs to True by default.

See gazebo-release/gz_utils_vendor#12 for a failing PR.

To test this run the following in gz_utils_vendor:

python3 <path to gz_vendor>/create_vendor_package.py <path to jetty gz-utils>/package.xml  --output_dir .

Note that <path to jetty gz-utils> is the upstream Jetty gz-utils, not the vendor package.

Before this PR, it will not generate the pythonpath.dsv.in file.

You can also test this by running it on gz-cmake in the kilted branch, which corresponds to Gazebo Ionic.

cd gz_cmake_vendor
git checkout kilted
python3 <path to gz_vendor>/create_vendor_package.py <path to ionic gz-cmake>/package.xml  --output_dir .

The generated gz-cmake-config.cmake.in will now have

if (NOT "@LIB_NAME@" STREQUAL "gz-cmake")

You can then build the workspace up-to gz_utils_vendor and test that the following CMake project
works:

// test.cpp
int main() {
  return 0;
}

# CMakeLists.txt
cmake_minimum_required(VERSION 3.10)
project(test_config_changes)

find_package(gz_cmake_vendor)
find_package(gz-cmake)

find_package(gz_utils_vendor)
find_package(gz-utils)

add_executable(test test.cpp)
target_link_libraries(test gz-utils::gz-utils)

Before this PR, the generated config files would fail at find_package(gz-cmake)

[scpeters]

this change seems reasonable

I think there might also be a problem that the new *pythonpath.dsv.in file might not be git added before being committed in release.py?

[azeey]

Ah, you're right. Well, maybe it's best to do this manually and create the PRs just adding the pythonpath.dsv.in files in.

[scpeters]

Ah, you're right. Well, maybe it's best to do this manually and create the PRs just adding the pythonpath.dsv.in files in.

I had gh pr create commands in my bash history that I used to add these files to the other packages, so I just opened the rest of the pull requests. They mention #2 in the pull request description, so look at the bottom of that issue for a list of the pull requests