* 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
First pass at fixing #57985 and implementing #59602
This doesn't have enough metadata to be useful for IDEs yet, but it prevents the issue from getting worse while we iterate on it.
Remove the version checking and associated warnings. The Linux template
and build process will now be subject to more typical Flutter breaking
change policy, and should no longer require regularly deleting and
recreating the platform directory.
Updates the tooling to use the GTK embedding, rather than the GLFW embedding:
- Adds new requirements to `doctor`
- Updates the app and plugin templates to make GTK-based runners and plugins
- Stops downloading and installing the GLFW artifacts
Final part of #54860, other than cleanup.
This install step fails if the list is empty, which is the case for projects without plugins (or Dart-only plugins, so flutter/plugins presubmits are currently broken).
PR #57749 included changes to the way the project interacts with the
build process (e.g., bundling the necessary library), so should have
incremented the template version to trigger the messaging to developers.
BundleUtilities apparently doesn't do build-system-style timestamp
analysis when deciding what to copy, and instead just doesn't copy
things that are already present. This cleans that bundle directory on
each build, so that it includes the up-to-date library versions.
Since this is just copying from build artifacts, this is very fast; the
build steps themselves are not affected.
Fixes https://github.com/flutter/flutter/issues/58049
The CMake plugin build wasn't setting visibility to hidden by default,
which meant that plugins exported everything by default. This would make
bad interactions between plugins much more likely; only the intended API
should be exported by the shared library.
The Linux CMakeLists.txt are intended to be compatible with 3.10, but
accedintally used a list construct that wasn't added until 3.12. This
adds a custom replacement function.
This makes the build compatible with 3.10 as originally intended.
Updates the Linux templates to use CMake+ninja, rather than Make, and updates the tooling to generate CMake support files rather than Make support files, and to drive the build using cmake and ninja.
Also updates doctor to check for cmake and ninja in place of make.
Note: While we could use CMake+Make rather than CMake+ninja, in testing ninja handled the tool_backend.sh call much better, calling it only once rather than once per dependent target. While it does add another dependency that people are less likely to already have, it's widely available in package managers, as well as being available as a direct download. Longer term, we could potentially switch from ninja to Make if it's an issue.
Fixes#52751
Redirects stdout/stderr in the Windows template when creating a console. This fixes the console opened when running from Visual Studio to actually show output, instead of being empty.
Fixes#53169
Plugins, and the library, should be able to use COM without special
setup. This adds COM initialization to the runner template so that it's
available for any code on the main thread.
This moves the app template more toward being a more generic starting
point for any Flutter application, eliminating some hard-code
assumptions about there being a single window/engine pair that is
directly bound to the life of the application:
- Moves the runloop into its own class, making it capable of servicing
any number of engine instances.
- Moves the logic for setting up a window containing only a Flutter view
into a window subclass for ease of re-use.
- Makes quit-on-window-close an optional property. (Long term this
should be even more generic, like a quit-when-last-window-closes
option, but this is a short-term improvement that removes the binding
between the runloop and the window).
- Allows for multiple instances of Win32Window to exist without issues
relating to the window class registration.
Since there are getting to be a non-trivial number of files associated
with the runner, this moves the source into a runner/ directory, as is
already done on some other platforms.
Note that creating multiple Flutter windows at the same time still
doesn't work correctly even with this change, but this addresses some of
the known issues, and makes it easier to test in the future (e.g., for
debugging engine-level issues with multiple instances).
Fixes#45397
