[yasm/yasm-tool] Incorporate yasm-tool into yasm#18816
[yasm/yasm-tool] Incorporate yasm-tool into yasm#18816JackBoosY wants to merge 27 commits intomicrosoft:masterfrom
Conversation
|
cc @BillyONeal |
|
Note that if the |
|
note also the DEPENS typo (should be corrected into DEPENDS - or even better DEPENDENCIES?) |
BillyONeal
left a comment
There was a problem hiding this comment.
I agree with @dg0yt 's feedback
|
Successfully tested the following affected ports:
|
|
Ping @dg0yt @ras0219-msft @BillyONeal for review again. |
BillyONeal
left a comment
There was a problem hiding this comment.
I think this is a good change in concept; I didn't realize that we already had a yasm port that produced the yasm binaries when I added yasm-tool and friends, and smashing that all together is great. However, I don't understand the value we gain by adding things to a shared helper over it, particularly in a way that mixes positional and named parameters.
Can the yasm-tool port just contain the right renames itself?
If that is unreasonable for some reason or we expect this to be common, can we add a new function that copies these dynamic DLL dependencies rather than piggybacking on vcpkg_copy_tool_dependencies and its associated applocal.ps1 baggage?
| vcpkg_copy_tool_dependencies(<${CURRENT_PACKAGES_DIR}/tools/${PORT}>) | ||
| vcpkg_copy_tool_dependencies( | ||
| <${CURRENT_PACKAGES_DIR}/tools/${PORT}> | ||
| [DEPENDENCIES <dep1>...] |
There was a problem hiding this comment.
This documentation suggests that the function uses named arguments but the implementation appears to use positional arguments.
Why can't the yasm port issue the right file(COPY calls itself rather than modifying a shared helper like this?
There was a problem hiding this comment.
The yasm example shows that there are still other ports that use the same method (load_library) to depend on other libraries, which cann't be analysis by dumpbin.
So this is a common change.
There was a problem hiding this comment.
I mean, there are ports that do that, yes, but I'm not seeing what's made clearer about this vs. just issuing the file(COPYs, and doing it like this creates the problems I listed below about mixing positional and named parameters.
| function(vcpkg_copy_tool_dependencies tool_dir) | ||
| if(ARGC GREATER 1) | ||
| cmake_parse_arguments(PARSE_ARGV 0 arg "" "" "DEPENDENCIES") | ||
| if(ARGC GREATER 2) |
There was a problem hiding this comment.
ARGC is going to be greater than 2 if tool_dir and DEPENDENCIES are both used; I don't think we should be mixing up positional and named parameters.
There was a problem hiding this comment.
tool_dir should only be passed one value. what is your opinion?
There was a problem hiding this comment.
I don't understand this response. tool_dir is only passed one value, but given
vcpkg_copy_tool_dependencies("C:/this/is/tool_dir" DEPENDENCIES "foo.dll")
ARGC is 3 so we're going to print that warning, which seems unintended.
|
|
||
| configure_file("${CMAKE_CURRENT_LIST_DIR}/vcpkg-port-config.cmake.in" | ||
| "${CURRENT_PACKAGES_DIR}/share/${PORT}/vcpkg-port-config.cmake" @ONLY) | ||
| SET(VCPKG_POLICY_EMPTY_PACKAGE enabled) No newline at end of file |
There was a problem hiding this comment.
Should this print a warning that it's now defunct?
There was a problem hiding this comment.
According to Robert's comment, we should not remove any ports.
So I think that's okay, both yasm-tool or yasm[tools] can be used.
There was a problem hiding this comment.
We can't remove it because that would break people's scripts and stuff, but we can warn that they aren't using the canonical one.
|
In favor of #23218. |

Since port
yasmandyasm-toolrepo is same and generate the same files, remove portyasm-tooland switch the related dependency itemyasm-tooltoyasm.Add option
DYNAMIC_DEPENDStovcpkg_copy_toolandvcpkg_copy_tool_dependenciesto copy the dynamic dependencies (Dynamically load dependencies in code) too tools/${PORT}.Fixes #18746.