Historically YCM relied on a fork of ExternalProject, that ensures that the DOWNLOAD step did not deleted existing source directory. This is important to ensure that you can create multiple different build directories of the same superbuild, without each build deleting the source folders (that are shared among builds). However, this fork of the ExternalProject was difficult to mantain, so in https://github.com/robotology/robotology-superbuild/pull/1674 we switched to use the upstream CMake's ExternalProject module.
However, just using the vanilla CMake's ExternalProject module turned out to be too error prone, as any new build could just remove all the source directories of the superbuild, as found by @giotherobot . So, to restore the old behavior, I searched some way to implement the old behaviour on the top of the latest ExternalProject. It turns out that it was not too difficult, the important thing was to define a custom DOWNLOAD_COMMAND command to pass to the ExternalProject_Add function. In this PR, we move the logic that used to be in the fork of the ExternalProject module to some code that is stored in YCMEpHelper, so that we keep the old behavior even when using the latest ExternalProject.
Fix https://github.com/robotology/ycm-cmake-modules/issues/50 .
Historically YCM relied on a fork of ExternalProject, that ensures that the
DOWNLOADstep did not deleted existing source directory. This is important to ensure that you can create multiple different build directories of the same superbuild, without each build deleting the source folders (that are shared among builds). However, this fork of the ExternalProject was difficult to mantain, so in https://github.com/robotology/robotology-superbuild/pull/1674 we switched to use the upstream CMake'sExternalProjectmodule.However, just using the vanilla CMake's
ExternalProjectmodule turned out to be too error prone, as any new build could just remove all the source directories of the superbuild, as found by @giotherobot . So, to restore the old behavior, I searched some way to implement the old behaviour on the top of the latest ExternalProject. It turns out that it was not too difficult, the important thing was to define a customDOWNLOAD_COMMANDcommand to pass to theExternalProject_Addfunction. In this PR, we move the logic that used to be in the fork of theExternalProjectmodule to some code that is stored inYCMEpHelper, so that we keep the old behavior even when using the latestExternalProject.