[Windows] [GN] Windows GN Builds

[CallumIddon]

This allows GN builds on Windows using the MSVC build tools. Currently just requesting feedback on changes before adding a post #161 patch.

This moves the main library header to include/flutter_desktop_embedding/windows and adds the flutter_desktop_embedding namespace to coincide with the Linux implementation.

The GLFW import has also been changed to coincide with the Linux implementation in preparation for including the files under common that already include GLFW with the Linux style imports.

The common files have been removed from the GN sources as they require jsoncpp to build. This patch is marked WIP as if it lands before #161 then a follow up patch would be required to allow #161 to build with GN. Once #161 has landed the common imports can be re-added as jsoncpp will be available.

Currently the example app cannot be built with GN as getting Visual Studio to build with the GN output would require more configurations. It would be more reasonable to add this later and just have 2 configurations, one for Visual Studio and one for GN, like the Linux builds instead of every combination of Static/Dynamic, Debug/Release, VS/GN. I have manually confirmed that the GN build does run correctly.

[stuartmorgan-g]

Thanks for tackling this! I won't have time for a detailed review until later this week (I left a few comments where I noticed things during my initial read-through), but in general this all looks really good.

Doing the plumbing to allow the example to build with the GN version in a follow-up makes sense to me, since there's already plenty in this PR.

[CallumIddon]

This now also adds the common files to the GN build and removes the VS static library builds to address #192.

[stuartmorgan-g]

and removes the VS static library builds

As this is unrelated to supporting GN, it should be landed separately.

[CallumIddon]

No longer addresses #192

[CallumIddon]

Not sure what is going on here. Any idea why git is marking the file as changed when they are exactly the same?

[stuartmorgan-g]

I'm not at my computer so I can't verify at the moment, but my guess would be that the line endings changed.

[stuartmorgan-g]

Sorry for the churn from #194. That should make this PR slightly simpler though, since now there's even less divergence between the list of files that the shared BUILD.gn target are building. (E.g., you don't need to move the Windows embedder.h any more since Windows just uses glfw/embedder.h.)

[CallumIddon]

This requires the run_dart_tool script you mentioned, other than that everything should be okay.

[stuartmorgan-g]

This requires the run_dart_tool script you mentioned, other than that everything should be okay.

I thought I could get to this today, but I didn't have much time and apparently writing a batch script to remove one argument and pass the rest through to another call (without it being broken for some cases) is surprisingly difficult. (I have the bash version done locally, as it's trivial.) Sorry for the delay!

[CallumIddon]

No worries. I know how painful batch can be sometimes...

[clarkezone]

Agreed

[stuartmorgan-g]

PR #210 will add run_dart_tool

(AFAICT the cases where arguments will not be passed correctly in that implementation are unlikely to matter, and at least one I found already wasn't being handled correctly by update_flutter_engine.bat, so I decided to go with something straightforward and then revisit if we ever need to pass, say, an "&" through it.)

[stuartmorgan-g]

Some small comments, but otherwise this looks ready to go!

Thanks again for taking this on, and all the iteration! (Beyond getting GN up and running for Windows, it's also just great to see so much batch be replaced with Dart, which will be much easier to maintain.)

[stuartmorgan-g]

If everything else is good we should be ready to merge.

I was doing a final once-over and realized that I hadn't checked the Dart locally; there are a bunch of analyzer warnings, and I'm trying to keep the Dart code as warning-free as possible. I can clean them up tomorrow and then merge (or if you feel like doing that before then feel free; at a glance I think most will be straightforward, but avoid_relative_lib_imports suggests I misunderstood the lib/bin structure, so we'll just disable avoid_relative_lib_imports for now until I can revisit that).

[CallumIddon]

@stuartmorgan not sure why travis is failing. I ran a Linux example build on a fresh clone with a fresh version on flutter as travis would do and had no problems, can you get the same result locally?

[stuartmorgan-g]

Sorry about that, I accidently broke trunk yesterday evening, and this branch's test ran before I landed the fix. I restarted it and it looks good now.