-
Notifications
You must be signed in to change notification settings - Fork 610
Use a cross-platform build system #114
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
Comments
This is related to #48, although that discussion is more about a higher-level tooling abstraction. Although CMake would be a possibility, I'm actually already strongly considering moving to gn (I have a mostly complete implementation for Linux already in a local branch). It's mostly a question of making sure that the gn dependency doesn't become a significant pain point. |
meson might be nice compromise :) |
Adds an experimental GN-based build as an alternative to the Make-based build on Linux. The example application does not use GN for its own build since it is intended to serve as an example of using the embedding library, so it continues to use the more common Make as clients are unlikely to be using GN. See issue google#114
Adds an experimental GN-based build as an alternative to the Make-based build on Linux. The example application does not use GN for its own build since it is intended to serve as an example of using the embedding library, so it continues to use the more common Make as clients are unlikely to be using GN. See issue #114
I'd encourage anyone on Linux who is interested in this issue to try out: |
Please! Use a standard build system like Gradle or cmake not an exotic one that nobody knows except a few nerds from a special community. |
The Flutter engine, which is where the iOS and Android platform implementations that this project parallels live, uses GN, so it's not exotic in this context. Also, keep in mind that, as noted in the library README, "a more Flutter-like model of using an SDK containing pre-compiled binaries is likely to be supported in the future". I.e., most clients of the library will never know nor care what build system it uses. |
I just followed the GN docs and successfully built both the lib and the example. No pain points, but I hadn't any pain points with make either. Also for the exotic part, I had never heard of GN or Ninja, just followed the instructions which are super simple. |
Adds support for building the Windows embedding library using GN. Rewrites the batch scripts used by the Windows build as Dart scripts, so they can be used from GN. Part of #114
For the library and plugins, switch to GN as the only supported build system on Linux. GN will be used for the library in the flutter/engine repository, so the make build will no longer be necessary; remove it now to avoid the overhead of maintaining an extra build system until the transition happens. The example continues to use Make in order to show typical usage of the library, and the color_panel plugin has an example makefile (updated to reflect the use of GN to build the library) as an example/starting point for someone making a plugin outside of the FDE repository. Addresses google#114 for Linux.
With the upcoming migration to flutter/engine, there's no longer any doubt about switching to GN. Given that, I will be removing non-GN builds for Linux and Windows ASAP to avoid extra build maintenance between now and the migration. (macOS library code will switch to GN when moved, since the toolchain is already in place in that repository. Whether a macOS GN toolchain will be spun up here for plugins in this repo is TBD, since the plan for plugins in general is less clear at the moment.) |
For the library and plugins, switch to GN as the only supported build system on Linux. GN will be used for the library in the flutter/engine repository, so the make build will no longer be necessary; remove it now to avoid the overhead of maintaining an extra build system until the transition happens. The example continues to use Make in order to show typical usage of the library, and the color_panel plugin has an example makefile (updated to reflect the use of GN to build the library) as an example/starting point for someone making a plugin outside of the FDE repository. Addresses #114 for Linux.
I know I don't have much power here, but as developer I prefer to have gn and ninja instead of gradle, which requires java to run. |
I forgot to tag this issue in #262, but with Windows and Linux switched to GN, and macOS on GN in flutter/engine (the copy here will be removed shortly, so won't be switched), this is essentially done. Per my comment above the only thing not on GN is macOS plugins, but until there's a stabilized plan for plugin management on the desktop platforms it doesn't make sense to switch them to GN (notably, if they are distributed the way iOS plugins are currently distributed, Xcode builds would be necessary). |
Using CMake would make it easier to build multiplatform projects and use xcode / vstudio if needed only.
The text was updated successfully, but these errors were encountered: