Switch Windows to CMake#60629
Conversation
|
Bonus advantage: no more |
| // included by the main CMakeLists.txt, so relative paths must be relative to | ||
| // that file's directory. | ||
| final String makefileDirPath = project.windows.cmakeFile.parent.absolute.path; | ||
| final path.Context cmakePathContext = path.Context(style: path.Style.posix); |
There was a problem hiding this comment.
interesting, this uses posix paths on windows too?
There was a problem hiding this comment.
Yes, CMake always uses posix-style paths. That's what the use of TO_CMAKE_PATH in the other generated file is for, but here it was easier to just convert it before writing it.
(The reason for all the escaped Windows paths in the other file is that those aren't used by CMake, but passed through back to the tool script, so I want them to stay untouched.)
jonahwilliams
left a comment
There was a problem hiding this comment.
LGTM
This is fantastic, so much deleted code 😆
The analysis error is caused by ToT being red, should be fixed by #60638
| '-B', | ||
| buildDir.path, | ||
| '-G', | ||
| 'Visual Studio 16 2019', |
There was a problem hiding this comment.
nit: maybe put this in a constant, with some docs on where exactly it comes from, like "we only support this particular sdk, see doctor blah blah".
There was a problem hiding this comment.
Done.
It hadn't occurred to me that this may mean that the next major version of VS won't actually work since the generator is hard-coded; I don't know if these values are forward-compatible. But since this is in the tool, not the ecosystem of plugins and projects, we can easily add switching logic here later if that turns out to be the case. (Unlike the requirement in the old method of having a hard-coded toolchain version in the project file, which was one of the things that really worried me about the ecosystem longer term.) I added a comment to that effect on the constant.
* First pass at CMake files; untested * First pass of adding CMake generation logic on Windows * Misc fixes * Get bundling working, start incoprorating CMake build into tool * Fix debug, exe name. * Add resources * Move cmake.dart * Rip out all the vcxproj/solution plumbing * Fix plugin cmake generation * Build with cmake rather than calling VS directly * Adjust Windows plugin template to match standard header directory structure * Pass config selection when building * Partially fix multi-config handling * Rev template version * Share the CMake generation instead of splitting it out * VS build/run cycle works, with slightly awkward requirement to always build all * Update manifest * Plugin template fixes * Minor adjustments * Build install as part of build command, instead of separately * Test cleanup * Update Linux test for adjusted generated CMake approach * Plugin test typo fix * Add missing stub file for project test * Add a constant for VS generator
Description
Switches Window builds from Visual Studio solution file + vcxproj to CMake.
Advantages:
reducing the number of build systems Flutter developers need to know by one.
difficult to move the ecosystem forward to new tool versions.
version control.
Disadvantages:
additional CMake step.
line, then opening the solution in the build directory. The build-and-run of the primary target won't
work, since there's no way to add the copy step in the right place with CMake (it doesn't support
setting VS custom build steps, which is how that was done before), so developers using the
VS workflow will need to 'build solution' then run the correct target.
Related Issues
Fixes #52753
Tests
I added the following tests: Updated all VS-specific tests to expect/use CMake instead.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]). This will ensure a smooth and quick review process.///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.