-
Notifications
You must be signed in to change notification settings - Fork 337
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
CMake plugin overhaul #703
Comments
I'm using a similar method to discover visual studio installation and platform SDK found in a "LLVM-based D compiler project" bat utility Pros:
Cons:
Thanks for making this moving forward |
Thanks @Jordibastide! The whole point of my approach is to free the result from batch to not suffer from 8k/2k character limits. It's a bit sneaky but my results so far have been quite encouraging. |
FYI I have a working implementation on this - but I'll wait for #707 since it relies on it to fix |
I've pushed my hacky WIP of the cmake overhaul to https://github.com/bfloch/rez/tree/feature/cmake_generators_overhaul (Not a PR. Please don't use this in production) EDIT: To not confuse matters: |
I am not sure if this information helps in any way, but I am dropping it here just in case. For running x86 Powershell (call it from SysWOW64 folder.... I know... weird) For running x64 Powershell (call it from System32 folder..... weird again) This blog talks more about where 32 vs 64 Powershell live: And this talks more about the DevShell.dll: Again, not sure if this info helps at all. Ps: All that in Windows 10 |
Thanks! Finally a powershell dev environment.
Two things to notice:
If you use the If you don't use the option that you get In my test I ran this before the lines above:
My point stands: Microsoft fix you development environment - don't just wrap it in PowerShell. For us it means nothing. My suggested workaround solution would still be superior as we would get the variables and append to exiting paths in PowerShell. This powershell dev prompt does not add anything since it is a batch file in disguise. |
Just as a sanity test: All of this is to replace something as simple as |
Here's what I use for x64: $vswhere = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe"
$vspath = & "$vswhere" -latest -property installationPath
Import-Module "$vspath\Common7\Tools\Microsoft.VisualStudio.DevShell.dll"
Enter-VsDevShell -VsInstallPath "$vspath" -DevCmdArguments "-arch=x64 -no_logo" -SkipAutomaticLocation (See EDIT: On a side note, for powershell core you may need |
rez-bind --quickstart E:\rez_packages\example_packages\hello_world>rez-bind python |
I get the error when use the rez-bind python command line, i dont know how to relove it |
EDIT: The proposal might depend on later CMAKE version?! Have to verify how 2.8 could still work in case we need to support it for some reason.
In order to support cmake on windows (and to improve the plugin in general) I am proposing the following changes to the cmake plugin:
Allow
build_system
andchild_build_system
to beNone
(new default)cmake
without specific generator andcmake --build build_path --target {ALL}
whereALL
isall
in unix andALL_BUILD
on windows.all
andALL_BUILD
distinction is unfortunate, but can be verified by listing all targetsDeprecate the hardcoded generators
cmake --help
that will always match a cmake-executable.This would allow building on Windows (or other platforms?) with the default settings but still keep backwards compatibility.
I am already working towards a PR on this. Feedback appreciated.
Other necessary changes for better path handling will be in a separate issue.
Related note for the curious
Windows is very special.
In order to support other generators on windows I am looking at options for manual discovery of the visual studio installation and platform SDK - which is needlessly painful. This is not necessarily cmake related so I think its best to keep outside of core-rez/the plugin. It can be implemented as a package instead. My personal generic approach with least maintenance overhead is to rely on
vswhere
[1] to findvcvarsall.bat
. Yes since they made Visual Studio only discoverable via COM in the latest releases you need a compiled executable to find the compiler to compile an executable ... 👏 Then I parse the difference of the resulting environment in terms of set, append and prepend env and reconstruct it within commands as@early()
-binding. Since all this happens at build time and generates the right commands in thevisual_studio
andplatform_sdk
packages that evaluate instantly. Users with non default installation paths just need to rebuild the packages locally.That's crazy you say? The benefit is you use Microsoft's official logic (thousands lines of horrifying batch files) to setup the environment but dodge the
cmd
related limitations [2] of the environment and just evaluate the resulting environment (fast!). This works correctly in any shell.Other approaches are to reconstruct the partial/complete discovery and setup of the environment as seen in
microsoft_crazyness.h
[3] or CMake's Visual Studio generator [4] implementation. But this would mean maintaining it and so far there does not seem to be a pattern in the way both Visual Studio and the platform SDK change structure between releases. It's like they try hard to make you not use their platform for development¯\_(ツ)_/¯
[1] https://github.com/microsoft/vswhere
[2] https://devblogs.microsoft.com/oldnewthing/20100203-00/?p=15083
[3] https://threader.app/thread/1125902959789740032
[4] https://github.com/Kitware/CMake/tree/master/Source
The text was updated successfully, but these errors were encountered: