-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Make Ninja the default CMake generator on Windows for the repo #49715
Conversation
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsThis PR switches Ninja to be the default generator on Windows for all native build components. MSBuild is still available on Windows with the Fixes #45955 Since this fixes #45955, it might require a jitutils update as well. cc @dotnet/jit-contrib This requires an infrastructure rollout to merge as it is an infra behavior change.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable.
Out of curiosity, why are we making this the default before CMake in VS user story is done (I see it's doesn't have the checkmark in #44761). Is it that much faster? A lot of people (me included) use the generated projects to do work, but I don't use them on a daily basis. I can see myself hitting this a couple times until I reach the "acceptance" stage of grief:
I invoke build.cmd manually a lot. Adding another mandatory parameter is a bit of a nuisance. It feels like the defaults in build.cmd are optimized for machines (the CI), not for humans. I would accept this if ninja is like 50% faster, but I don't know how much faster it is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm. Are the binaries produced identical? If not what is the size difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple small things. Also, this might be really rough on dev inner loop, if that many people use the SLN + proj files generated. Agree on the rollout part.
@MichalStrehovsky in addition to providing a speedup, Ninja can further enable #47022 by allowing us to let Ninja and CMake do an up to date check on the CMake build files instead of reconfiguring every build (and relying on CMake to not write out build files that didn't change). For your use case, there's a (apparently little known) feature in the root build scripts: If you run With the |
@jashook The last set of comparison numbers I had (#41897 (comment)) showed Ninja sizes as comparable if not better. |
…ght place to understand the Ninja vs VS layout for the native test binaries and use the Ninja=false switch on Windows to switch to expecting the MSBuild layout (same as the rest of the build scripts).
Yup, looks like it will do the trick. Thank you! |
I notice there are a ton of compiler warnings in the build. Can these get addressed before merge? e.g., Lots of:
and:
and:
|
Also, can we enable warnings as errors? I believe that the msbuild has warnings as errors enabled right now. |
Does ninja generate any build log files? I can't find any. If I have a compiler error in the JIT, the build-runtime.cmd script outputs:
but those files aren't there. (Note, these are experiences without picking up this PR, which I have been assuming aren't fixed by this PR) |
I don't believe ninja generates any build log files by default. Similar to make, it stops on the first error so it's pretty easy to find the errors that caused the build failures. I'll work on driving the warnings to 0 before merging this in. |
Warnings-as-errors is also enabled in the Ninja build, but this class of warnings are apparently excluded from warnings-as-errors behavior by CL |
…reCLR.sln and update the docs of the -vs coreclr feature.
…Lists.txt. Add dependency on inject_debug_resources since that's what was touching coreclr.dll, making it dirty and leading to a rebuild/link of the single file host.
If there are no log files, how do you debug issues with the build itself? ninja doesn't output the full list of commands and options to the command-line (nor would you want it to). What if I want to see exactly what the compile options are (e.g., warning levels, optimization levels, etc.)? |
The generated |
The release build has still a bunch of warnings in the last CI run like:
|
I must have missed those last time I looked. I’ll do another pass over the warnings now that everything builds successfully. |
…higher up in this file for Release builds.
@BruceForstall if something fails you should see the full compiler command line including all options:
If you want to see the options for a specific compilation unit without a failure then you can either look into the generated build.ninja file or pass |
Co-authored-by: Juan Hoyos <[email protected]>
…shim_mono # By Aaron Robinson (10) and others # Via GitHub * upstream/main: (108 commits) [mbr] Add Apple sample (dotnet#50740) make EstablishProxyTunnelAsync throw on failure status code from proxy (dotnet#50763) Improve RGB Min Max evaluation performance by using 2 or 3 comparison… (dotnet#50622) [mono] More domain cleanups (dotnet#50479) Fix Crossgen2 of PlatformDefaultMemberFunction methods and calls. (dotnet#50754) Disable EventSource generator in design-time builds (dotnet#50741) Fix X509 test failures on Android (dotnet#50301) Do not confuse fgDispBasicBlocks in fgMorphBlocks (dotnet#50703) Enforce 64KB event payload size limit on EventPipe (dotnet#50600) Reorganize CoreCLR native build to reduce CMake reconfigures when the build system is untouched (dotnet#49906) [mbr] Turn on hot reload for iOS, tvOS and MacCatalyst (dotnet#50458) improve connection scavenge logic by doing zero-byte read (dotnet#50545) Resolve call mdtokens when making tier 1 inline observations (dotnet#50675) Annotate APIs in System.Private.Xml (dotnet#49682) Support compiling against OpenSSL 3 headers Change Configuration.Json to use a regular Dictionary. (dotnet#50611) Remove unused BigNumFromBinary P/Invoke (dotnet#50670) Make Ninja the default CMake generator on Windows for the repo (dotnet#49715) [AppleAppBuilder] Entitlements to run tests on catalyst using the JIT (dotnet#50637) [mono] Fix delegate invokes to dynamic methods in mixed mode. (dotnet#50547) ... # Conflicts: # src/mono/dlls/mscordbi/CMakeLists.txt
Part of April's batched infrastructure rollout: #49889
This PR switches Ninja to be the default generator on Windows for all native build components.
MSBuild is still available on Windows with the
-msbuild
flag. To prevent conflicts from using both the Ninja and MSBuild generators in the same dev workflow, I've moved the MSBuild-generated sources to anide
subfolder of each native build's intermediate directory.Fixes #45955
Contributes to #44761
Contributes to #47022
If a developer wants to easily create an MSBuild solution for CoreCLR's native code and open it in VS, they can run
./build.cmd -vs coreclr.sln -c <config> -a <arch>
to create and open a solution for the given arch and config in VS.