Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

About "add_custom_target(man ALL DEPENDS ${man_MANS})" #13324

Closed
hammlee96 opened this issue Apr 9, 2024 · 10 comments
Closed

About "add_custom_target(man ALL DEPENDS ${man_MANS})" #13324

hammlee96 opened this issue Apr 9, 2024 · 10 comments
Labels

Comments

@hammlee96
Copy link

I did this

No response

I expected the following

In "curl/docs/libcurl/CMakeLists.txt",can "add_custom_target(man ALL DEPENDS ${man_MANS})" this line add an option to whether to execute or not?Currently conflicting with libzip,the error string is "See documentation for policy CMP0002 for more details.".Change to something similar to the following
if(${xxxxxxx})
add_custom_target(man ALL DEPENDS ${man_MANS})
endif()

curl/libcurl version

8.2.0

operating system

Windows 10

@bagder bagder added the cmake label Apr 9, 2024
@vszakats
Copy link
Member

vszakats commented Apr 9, 2024

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?

@vszakats
Copy link
Member

vszakats commented Apr 9, 2024

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?

@hammlee96
Copy link
Author

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

@jzakrzewski
Copy link
Contributor

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.

@hammlee96
Copy link
Author

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?

@vszakats
Copy link
Member

vszakats commented Apr 9, 2024

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.

@vszakats
Copy link
Member

vszakats commented Apr 9, 2024

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

(Via #13326)

@hammlee96
Copy link
Author

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.

@hammlee96
Copy link
Author

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

(Via #13326)

After verification, this patch has resolved this issue

@vszakats
Copy link
Member

vszakats commented Apr 9, 2024

Thanks for testing and your feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

4 participants