[CMake] [cmake-developers] Using FetchContent fails when two subprojects have a target with the same name

[Timothy Wrona]

Okay that makes sense. I will give ExternalProject_Add a try. I think it
would be very useful if FetchContent were able to support targets with the
same name and that would be a great feature to add (although it is
understandable if it is a language limitation).

I much prefer the simplicity of FetchContent :)

Thanks,
Tim

On Wed, Feb 20, 2019 at 8:22 AM Craig Scott <craig.scott at crascit.com> wrote:

>
>
> On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona <tjwrona1992 at gmail.com>
> wrote:
>
>> (Included cmake-developers list as well in case this may have just been
>> something that should work that was overlooked with the FetchContent module)
>>
>> On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona <tjwrona1992 at gmail.com>
>> wrote:
>>
>>> I am having an issue with using FetchContent to grab two subprojects
>>> that both contain a "doxygen" target to build the documentation.
>>>
>>> Both of these subprojects need to be able to be built independently and
>>> when built on their own they compile fine (along with their documentation),
>>> but when I pull them into one project using "FetchContent" I get an error
>>> saying I can't define the "doxygen" target more than once.
>>>
>>> I imagine this kind of issue would come up all of the time when using a
>>> "superbuild" pattern. Is there a typical way of handling this?
>>>
>>
> I thought this limitation was already mentioned in the FetchContent docs,
> but it seems it isn't. If two different dependencies define the same global
> target name, then they cannot be combined into the same build via
> add_subdirectory(). CMake doesn't allow a target to be redefined (although
> it does allow additional commands to be added to an existing custom
> target). I'll try to add some docs to FetchContent to mention this
> limitation, but they will not make it into the 3.14 release - the
> limitation has always been there right from when FetchContent was first
> introduced in 3.11.
>
> A traditional superbuild that uses ExternalProject won't have a problem
> with this because a subproject's own targets are not combined with targets
> of other subprojects into a single build. Instead, the top level project
> only sees the targets that ExternalProject itself creates. This is most
> likely the best workaround if you are not able to modify the target names
> used in the subprojects you want to combine.
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get the hand-book for every CMake user: Professional CMake: A Practical
> Guide <https://crascit.com/professional-cmake/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190220/e4b60ca6/attachment.html>