About "add_custom_target(man ALL DEPENDS ${man_MANS})" about curl HOT 10 CLOSED

And I suppose we also need the if() because CMake might invoke the curl script twice and complain about an existing target on the second one?

• I haven't encountered a situation where the same CMakeLists.txt is called twice yet

• I still agree with what you said before, using a unique name may be the best solution

from curl.

Using unique (prefixed) target names seems to be best practise for libraries. Especially since FetchContent exists, and people embed 3-party code in their build trees.

Dependencies brought in with FetchContent are all mashed together with the main build.

from curl.

Does this patch fix this issue?:
https://github.com/curl/curl/commit/a4385903f364da4e55c3a7092ea9ac99e43cba4d.diff

(Via #13326)

from curl.

Does this patch fix this issue?: https://github.com/curl/curl/commit/a4385903f364da4e55c3a7092ea9ac99e43cba4d.diff

(Via #13326)

After verification, this patch has resolved this issue

from curl.

Thanks for testing and your feedback.

from curl.

Looks like target names share a common namespace in CMake. If so, an if() would only hide the problem and break building curl manpages. Instead we should probably aim to use unique target names to avoid colliding with other projects.

(Renaming targets also rename the generated e.g. make targets, with a slight chance of breaking builds downstream.)

Does that make sense?

from curl.

And I suppose we also need the if() because CMake might invoke the curl script twice and complain about an existing target on the second one?

from curl.

And I suppose we also need the if() because CMake might invoke the curl script twice and complain about an existing target on the second one?

Using unique (prefixed) target names seems to be best practise for libraries. Especially since FetchContent exists, and people embed 3-party code in their build trees.

Dependencies brought in with FetchContent are all mashed together with the main build.

If curl is included in other third-party libraries called in my project, and I also compile curl in my own code, then curl's CMakeLists.txt will be called multiple times. At this point, even if a unique name is used, an error may still occur: "See documentation for policy CMP0002 for more details.". Is there a win-win solution?

from curl.

I propose handling the self-duplicate issue separately as it's less clear-cut and also distinct from the namespace one.

I don't understand the details of that, which (or a sub-case of it?) also seems to be CMake version dependent based on past issues. Also we don't seem to have any protection for this, yet this hasn't come up in practice.

from curl.

I propose handling the self-duplicate issue separately as it's less clear-cut and also distinct from the namespace one.

I don't understand the details of that, which (or a sub-case of it?) also seems to be CMake version dependent based on past issues. Also we don't seem to have any protection for this, yet this hasn't come up in practice.

Okay, the issue of self repetition is currently only theoretical.
Thank you very much for fixing this issue.

from curl.