When generating the plugin registrant for Linux, also generate a
makefile that can be included in the app-level Makefile to manage all of
the plugin targets and flags, exporting them in a few known variables
for use in the outer makefile.
Part of #32720
Generates a Property Sheet for Windows builds containing link and include path
information for any included plugins. This allows automating part of the process
of integrating plugins into the build that is currently manual.
To support this change, refactored msbuild_utils into a PropertySheet class so that
it can be used to make different property sheets.
This makes ephemeral symlinks to each plugin, for use by build systems.
This is similar to the logic implemented in the Podfile on iOS and
macOS, but managed internally to the Flutter tool.
Exploration for addressing #32719 and #32720
Related to #41146
* Update project.pbxproj files to say Flutter rather than Chromium
Also, the templates now have an empty organization so that we don't cause people to give their apps a Flutter copyright.
* Update the copyright notice checker to require a standard notice on all files
* Update copyrights on Dart files. (This was a mechanical commit.)
* Fix weird license headers on Dart files that deviate from our conventions; relicense Shrine.
Some were already marked "The Flutter Authors", not clear why. Their
dates have been normalized. Some were missing the blank line after the
license. Some were randomly different in trivial ways for no apparent
reason (e.g. missing the trailing period).
* Clean up the copyrights in non-Dart files. (Manual edits.)
Also, make sure templates don't have copyrights.
* Fix some more ORGANIZATIONNAMEs
* Generate projects using the new Android embedding
* Add comment about usesNewEmbedding:true
* Feedback
* Rework way to detect new embedding in new apps
Adds very preliminary support for Windows and Linux plugins:
- Adds those platforms to the new plugin schema, initially supporting just a plugin class.
- Adds C++ plugin registrant generation for any Windows or Linux plugins found.
This doesn't have yet have any build tooling for either platform, so anyone using the generated registrant still needs to do manual build configuration. This reduces the manual work, however, and creates a starting point for future tooling work.
As with all Windows and Linux work at this time, this is not final, and subject to change without warning in the future (e.g., Windows could potentially switch to a C# interface, or
'linux' may change to 'gtk' or 'linux_gtk' in pubspec.yaml).
Moves files generated in windows/flutter/ as part of the build to an ephemeral/ subdirectory, matching the approach used on macOS (and in the future, Windows).
Adds that directory to the generated properties file to minimize hard-coding of paths in the project.
* WIP on web plugin registry
* WIP on registering plugins
* WIP on web plugin registration
* Only generate `package:flutter_web_plugins` imports if plugins are
defined
* Add parsing test
* Add documentation
* Fix analyzer warnings
* add license headers
* Add tests for package:flutter_web_plugins
* Run `flutter update-packages --force-upgrade`
* Fix analyzer errors
* Fix analyzer error in test
* Update copyright and remove flutter SDK constraints
* Enable tests since engine has rolled
* add flutter_web_plugins tests to bots
* Create an empty .packages file for WebFs test
We were using the `defaults` command-line utility to parse
Plist files, but it was never supported by Apple, and it
appears that in an upcoming OS release, it will be less likely
to work:
> WARNING: The defaults command will be changed in an upcoming
> major release to only operate on preferences domains. General
> plist manipulation utilities will be folded into a different
> command-line program.
Fixes https://github.com/flutter/flutter/issues/37701
