Flutter-desktop-embedding: Use a cross-platform build system

[DavBfr]

Using CMake would make it easier to build multiplatform projects and use xcode / vstudio if needed only.

[stuartmorgan]

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.

[mrmcq2u]

meson might be nice compromise :)

[stuartmorgan]

I'd encourage anyone on Linux who is interested in this issue to try out:
https://github.com/google/flutter-desktop-embedding/blob/master/library/GN.md
and let me know if there are any pain points. (Since I originally looked at GN, they've added prebuilt binaries, which makes things much simpler.)

[MikeMitterer]

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.

[stuartmorgan]

not an exotic one

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.

[sirgallifrey]

I'd encourage anyone on Linux who is interested in this issue to try out:
https://github.com/google/flutter-desktop-embedding/blob/master/library/GN.md
and let me know if there are any pain points. (Since I originally looked at GN, they've added prebuilt binaries, which makes things much simpler.)

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.

[stuartmorgan]

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.)

[charafau]

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.

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.

[stuartmorgan]

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).