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

[vcpkg] Fix '/' incorrectly replaced by '-' on Linux. #24098

Merged
merged 16 commits into from May 7, 2022

Conversation

Nemirtingas
Copy link
Contributor

Describe the pull request
This PR makes the '/' to be kept on Linux when cross-compiling using a MSVC compatible compiler (like Clang-CL) instead of behind replaced by '-'.

Same as before, No.

Yes.

  • If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

Yes.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

PRs must add only one version and must not modify any published versions

When making any changes to a library, the version or port-version in vcpkg.json or CONTROL must be modified.

Error: Local changes detected for vcpkg-cmake but no changes to version or port version.
-- Version: 2022-04-12
-- Old SHA: 5aee0d861b593c164bb3362288ae9e926b62d8a8
-- New SHA: 7865bb6a8f7c708eaa93ff34e2c5ab0c97c479e3
-- Did you remember to update the version or port version?
-- Pass `--overwrite-version` to bypass this check.
***No files were updated.***

@@ -143,7 +143,7 @@ foreach(incdir IN LISTS CMAKE_C_STANDARD_INCLUDE_DIRECTORIES)
endforeach()

foreach(flag CXX C SHARED_LINKER EXE_LINKER STATIC_LINKER RC)
if(MSVC)
if(MSVC AND "${CMAKE_HOST_SYSTEM_NAME}" MATCHES "Windows")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's an unusual setup. Without an extra comment, the AND part will look as if implied by MSVC and might get removed in future cleanup.
(IMO if something is claiming to be MSVC, it should really accept the same parameters as MSVC.)

(And maybe updates to this PR can wait for a low-load time on CI? We have several changes to vcpkg-cmake now, all building for hours, and affecting more common setups.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I should add a comment about cross-compilation so it doesn't get removed by someone else in the future ?
MSVC only implies a MSVC compatible compiler, not that its compiling on Windows.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MSVC only implies a MSVC compatible compiler, not that its compiling on Windows.

So is your toolchain providing "a MSVC compatible compiler" if it is not fully simulating the Visual C++ cl command-line syntax?

I don't want to say that assuming Windows is right. I'm saying that people might easily accept the assumption that MSVC implies CMAKE_HOST_WIN32.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My toolchain just setup LLVM + Clang + Clang-CL (the CL.exe syntax emulator) for Linux to build Windows binaries on Linux.
Here are my sources:
https://github.com/Nemirtingas/clang-msvc-sdk # The toolchain
https://github.com/Nemirtingas/windowscross_vcpkg/tree/msvc2019_win10.0.18362.0 # The Ubuntu docker image to use the toolchain + vcpkg.

As far as I tested, it understands the CL.exe flags/options and transcribes them to Clang valid flags/options (or ignoring them if not needed like /MP (multi-processor compile)). But it also adds some other options that are not provided by CL.exe.
I have this kind of extra options for clang-cl: (Remember clang-cl is a frontend, it's not a compiler like clang is).

-imsvc /clang_windows_sdk/msvc/include
-imsvc /clang_windows_sdk/winsdk/Include/10.0.18362.0/ucrt
-imsvc /clang_windows_sdk/winsdk/Include/10.0.18362.0/shared
-imsvc /clang_windows_sdk/winsdk/Include/10.0.18362.0/um
-imsvc /clang_windows_sdk/winsdk/Include/10.0.18362.0/winrt

Which pass the include directories to the clang compiler.

-Xclang -ivfsoverlay -Xclang /vcpkg/buildtrees/boost-exception/x86-windows-nemirtingas-rel/winsdk_vfs_overlay.yaml

Which pass a virtual FS overlay to clang for case-insensible include files/libraries.

Thoses options are rewritten by this rule and destroys all the Toolchain logic. (Note the first '/' is replaced by a '-')

-imsvc -clang_windows_sdk/msvc/include
-imsvc -clang_windows_sdk/winsdk/Include/10.0.18362.0/ucrt
-imsvc -clang_windows_sdk/winsdk/Include/10.0.18362.0/shared
-imsvc -clang_windows_sdk/winsdk/Include/10.0.18362.0/um
-imsvc -clang_windows_sdk/winsdk/Include/10.0.18362.0/winrt
-Xclang -ivfsoverlay
-Xclang -vcpkg/buildtrees/boost-exception/x86-windows-nemirtingas-rel/winsdk_vfs_overlay.yaml

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The condition I added might not be fixing the issue but only my specific issue. If you run LLVM + Clang + Clang-CL on Windows, the bug should be still there because "${CMAKE_HOST_SYSTEM_NAME}" MATCHES "Windows" is true in that case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the right thing to do here is to just add the comment; something like # for cross-compilation, we don't want to do this in case we have absolute paths starting with `/` (otherwise I'm happy with this change, personally)

@@ -143,7 +143,7 @@ foreach(incdir IN LISTS CMAKE_C_STANDARD_INCLUDE_DIRECTORIES)
endforeach()

foreach(flag CXX C SHARED_LINKER EXE_LINKER STATIC_LINKER RC)
if(MSVC)
if(MSVC AND "${CMAKE_HOST_SYSTEM_NAME}" MATCHES "Windows")
# Transform MSVC /flags to -flags due to bash scripts intepreting /flag as a path.
# This is imperfect because it fails on directories with trailing spaces, but those are exceedingly rare
string(REGEX REPLACE "(^| )/" "\\1-" ${flag}_FLAGS "${${flag}_FLAGS}")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ras0219-msft I would be curious about the actual cases which motivated this line. Bash shouldn't treat paths different from other arguments, exept that it may do expansion of * or ~. (In a bash world, you would resolve this with single quotes.)
But MSYS2 has special treatment for converting Unix paths to Windows paths in command line arguments and environment variables. This could probably be resolved by setting enviroment variables to declare the known flags.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bash scripts

Means libtool and other stuff run via configure. Just try to remove it and see the vcpkg_configure_make world burn ;)

See #12936. Especially 65e71b1 (I aborted the CI run since I already saw it failing) vs 723b9d7

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Means libtool and other stuff run via configure.

Means MSYS2 runtime, not bash.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Illustration

$ /usr/bin/echo.exe /libpath/users
/libpath/users
$ /C/Windows/System32/findstr.exe a /libpath/users
FINDSTR: D:/msys64/libpath/users kann nicht geöffnet werden.
$ MSYS2_ARG_CONV_EXCL=/libpath /C/Windows/System32/findstr.exe a /libpath/users
FINDSTR: /libpath/users kann nicht geöffnet werden.

I see that the MSYS2_ARG_CONV_EXCL doesn't scale to all combinations of tools and parameters, even if scoped via wrappers.
But sometimes it is necessary to understand that the transformation is not in bash itself (cf. bash -> echo) but a MSYS2 service at the border between MSYS2 runtime (bash) and windows runtime (findstr).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Means MSYS2 runtime, not bash.

libtool is just a bash script. But I really don't care about the details anymore. vcpkg should just build the msys stuff all by itself and no longer have to deal with MSYS2 since it has often enough shown to be instable by removing downloadable stuff.

@LilyWangLL LilyWangLL added category:vcpkg-bug The issue is with the vcpkg system (including helper scripts in `scripts/cmake/`) requires:vcpkg-team-review This PR or issue requires someone on the vcpkg team to take a further look. labels Apr 13, 2022
@strega-nil-ms strega-nil-ms added requires:author-response and removed requires:vcpkg-team-review This PR or issue requires someone on the vcpkg team to take a further look. labels Apr 14, 2022
@LilyWangLL LilyWangLL changed the title Fix '/' incorrectly replaced by '-' on Linux. [vcpkg] Fix '/' incorrectly replaced by '-' on Linux. Apr 15, 2022
@Nemirtingas
Copy link
Contributor Author

Nemirtingas commented Apr 15, 2022

I think the right thing to do here is to just add the comment; something like # for cross-compilation, we don't want to do this in case we have absolute paths starting with `/` (otherwise I'm happy with this change, personally)

I'm happy with the change too. I added the comment and updated the version hash.
This change + adding set(VCPKG_POLICY_SKIP_ARCHITECTURE_CHECK enabled) to my custom triplet fixes my compilation issue.

@strega-nil-ms
Copy link
Contributor

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@LilyWangLL LilyWangLL added the depends:different-pr This PR or Issue depends on a PR which has been filed label Apr 18, 2022
@LilyWangLL
Copy link
Contributor

Depends on #24169

@Nemirtingas
Copy link
Contributor Author

Depends on #24169

Why does this PR depends on #24169 ?

@LilyWangLL
Copy link
Contributor

Depends on #24169

Why does this PR depends on #24169 ?

This PR mark zeroc-ice doesn't support staticrt on windows, it should fix the pipeline failed.

@Nemirtingas
Copy link
Contributor Author

Depends on #24169

Why does this PR depends on #24169 ?

This PR mark zeroc-ice doesn't support staticrt on windows, it should fix the pipeline failed.

Oh, ok, that was about the pipeline :).

@LilyWangLL LilyWangLL removed the depends:different-pr This PR or Issue depends on a PR which has been filed label Apr 20, 2022
Copy link
Member

@BillyONeal BillyONeal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is OK to me assuming CMAKE_HOST_SYSTEM_NAME contains Windows under all our "desktop" and "uwp" triplets and does not under MinGW.

ports/vcpkg-cmake/cmake_get_vars/CMakeLists.txt Outdated Show resolved Hide resolved
@LilyWangLL
Copy link
Contributor

Ping @Nemirtingas for response, could you resolve the conflicts?

@Nemirtingas
Copy link
Contributor Author

Ping @Nemirtingas for response, could you resolve the conflicts?

Done.

# Conflicts:
#	versions/v-/vcpkg-cmake.json
Copy link
Member

@BillyONeal BillyONeal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Slash dot dash dot slash dot dash dot slash dot com

@BillyONeal BillyONeal merged commit d5ea966 into microsoft:master May 7, 2022
@BillyONeal
Copy link
Member

I merged this despite not having a full build for it since there were no 'interesting' merge conflicts outside of the version database.

Thanks for the fix!

@Nemirtingas Nemirtingas deleted the fix_slash_replaced_by_dash branch May 24, 2022 15:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:vcpkg-bug The issue is with the vcpkg system (including helper scripts in `scripts/cmake/`)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[vcpkg] Compile flags are wrongly modified.
6 participants