Avoid requiring Visual Studio for Windows development

codec-abc commented 3 years ago

Hi,

Sorry if the point below was already brought to attention but searching Visual Studio here matches too many Github's issues.

Use case

You surely know this as well, but Visual Studio isn't free. It is when using Community for learning, open-source and one man company. On the others cases, a license is needed which, of course, cost money. Since Windows is the major desktop platform and will probably remains as such for at least a decade it would be great if Flutter could be used to build Windows application in a commercial environment without needing a Visual Studio license. Otherwise, it will probably limits the growth of Flutter for commercial projects on the desktop which is rather unfortunate.

Proposal

Regarding solutions, I don't have any to propose since I don't know Flutter internals. But a few imaginable ones (I don't know if they are barely possible):

Provide a ready to use binary.
Use a free toolchain like MinGW

ghost commented 3 years ago

Hi @codec-abc, I completely agree with this suggestion. It should not be necessary to have Visual Studio for Windows development. In fact the initial compilation of a windows project is very slow, it cannot be compared to compilers like Delphi which is extremely fast. Regards, Jose

stuartmorgan commented 3 years ago

and one man company

The actual restriction is for "enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue)", which it's not the same thing as 'a more-than-one-person company'.

Since the build definitions are CMake, you could locally modify your Flutter tool to use a different generator relatively easily, and set up your own build toolchain. The hard part of supporting such a thing would be all the associated logistics:

What toolchain or toolchains do we support instead?
How do users get them?
How do users get the Windows SDK?
How do we support users who have issues setting up their toolchain?
Maintaining doctor checks for everything.
Automated tests and CI for every supported configuration.
Ecosystem compatibility concerns (if a plugin author only tests with one toolchain, will it work in an app being built with a different toolchain?)

Otherwise, it will probably limits the growth of Flutter for commercial projects on the desktop

Do you have supporting evidence you can provide for the idea that there are significant numbers of $1M+-revenue companies for whom needing a Visual Studio license would be the deciding factor in their development framework choice? Actual data would be useful in prioritization.

ghost commented 3 years ago

@stuartmorgan,

But, have you seen that other compilers need Visual Studio to do their work? For example, Delphi, uses its own import files from the Windows SDK, and has its own compiler, it does not need an external environment to work. Dart should have its own compiler for each operating system and be independent from external proprietary tools. Yesterday I found out that Dart does not have reflection, or dynamic loading of libraries, this is essential for the development of large business applications, especially now that desktop is supported (windows, linux, mac). https://github.com/dart-lang/sdk/issues/10530 If google wants Dart and Flutter to be first class they must support at least the features of other languages like C#, Delphi, ... Maybe LLVM could be used. Many other companies are using it for their developments.

Regards, Jose

codec-abc commented 3 years ago

The actual restriction is for "enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue)", which it's not the same thing as 'a more-than-one-person company'.

Yeah you are right. I mixed up, individual and company requirements. But still, $1 Million US Dollars in annual revenue come so fast that many companies will hit the limits. To me, that means that any western company that have revenues to cover up ~20 developers (and even less) would be around the limits. In other words, only really small companies won't be affected by it.

Do you have supporting evidence you can provide for the idea that there are significant numbers of $1M+-revenue companies for whom needing a Visual Studio license would be the deciding factor in their development framework choice? Actual data would be useful in prioritization.

There is at least my company. A consulting (mostly in IT) company of 30k people. Here, Visual Studio installation is blocked and would have to justified for the projects where we want to use it. And also, the license prices would be put in the project cost reducing that profitability which could impact the technology chosen if the client left the choice to use . Also, VS comes with tools to build GUI application (UWP, Winforms to name a few). So if the project consist of building Windows GUI only, then Flutter has not the edge over such technologies regarding cost which is rather unfortunate since Flutter is by itself free of charge.

But really, it comes down to the fact that requiring Visual Studio put Flutter for Windows in the non free category for this platform which means any GUI toolkit that is free for Windows (for example Qt) has an advantage over Flutter regarding cost. How it will limits it growth is hard to evaluate.

TahaTesser commented 3 years ago

Hi everyone I like the idea of not having to install Visual Studio, let's be honest, it will add more components, as a result, adds more complications, and bugs. There are a lot of unknowns as well from https://github.com/flutter/flutter/issues/77638#issuecomment-793195328

Since this proposal is a bit unrealistic at the moment, I feel safe closing the issue Thank you

ghost commented 3 years ago

Example 2:A Fortune 500 firm has outsourced the development of its store-locator mobile application to a small agency. The application is not an open source project. The agency has 5 employees working on the project and would like to use Visual Studio Community 2019. Since the agency is a contractor developing this application for the Fortune 500 firm, and since the application is not an open source project, the agency cannot use Visual Studio Community 2019for developing and testing the application.

This totally limits the ability to make applications with Visual Studio Community, even for small businesses.

Regards, Jose

stuartmorgan commented 3 years ago

Dart should have its own compiler for each operating system

Dart has its own compiler. VS is used to build the runner application and plugins (C++), not compile the Dart code. Just as on iOS and macOS, Xcode is used to build those components.

If you want to build a binary purely in Dart, you can do so without VS. See https://medium.com/dartlang/dart2native-a76c815e6baf

Flutter applications are not just Dart, however.

Since the agency is a contractor developing this application for the Fortune 500 firm, and since the application is not an open source project, the agency cannot use Visual Studio Community 2019for developing and testing the application.

You'd need to consult a lawyer and/or Microsoft about that use case.

stuartmorgan commented 3 years ago

@TahaTesser please allow the desktop leadership to make final decisions about significant feature requests. This is not an invalid or impossible request, just something that would need to be weighed against the additional effort to build out and maintain.

ghost commented 3 years ago

@stuartmorgan,

Example 2:A Fortune 500 firm has outsourced the development of its store-locator mobile application to a small agency. The application is not an open source project. The agency has 5 employees working on the project and would like to use Visual Studio Community 2019. Since the agency is a contractor developing this application for the Fortune 500 firm, and since the application is not an open source project, the agency cannot use Visual Studio Community 2019for developing and testing the application.

This is an fragment from the Microsoft license document, so there is no need to consult a lawyer. It is a serious limitation. A small agency or individual cannot make applications that are used by large companies.

Dart has its own compiler. VS is used to build the runner application and plugins (C++), not compile the Dart code. Just as on iOS and macOS, Xcode is used to build those components. Flutter applications are not just Dart, however.

Dart, like other programming languages, should have its interface libraries to use the Windows SDK or the SDK of other operating systems, other companies have done it and they are much smaller than Google. It should not be necessary to use C++ to create the plugins, however, if it is an internal design decision, you could use LLVM to have the C++ compiler itself, and not use Visual Studio, although I do not see the need, Dart should to have all the possibilities of directly using the libraries of each operating system.

Thanks Stuart, Regards, Jose

TahaTesser commented 3 years ago

@stuartmorgan Based on the point you raised, it didn't look feasible to me. I should've let "desktop leadership" decide, my bad I would love nothing more than this feature, it would be nice to not have to install VS.

codec-abc commented 3 years ago

Dart should have its own compiler for each operating system

Dart has its own compiler. VS is used to build the runner application and plugins (C++), not compile the Dart code. Just as on iOS and macOS, Xcode is used to build those components.

If you want to build a binary purely in Dart, you can do so without VS. See https://medium.com/dartlang/dart2native-a76c815e6baf

Flutter applications are not just Dart, however.

Could a Electron like approach solve a part of the problem? By that, I mean having the runner application with common prebuild and ready to use? While it is more limiting regarding plugins it might be enough for a wide range of applications specially if there are enough plugins out of the box. After all, that's what Qt does: It offers a unified set of API for all 3 major platforms and since its wrap quite a lot many applications don't need to dig in each specific OS API.

stuartmorgan commented 3 years ago

It should not be necessary to use C++ to create the plugins

It isn't necessary (see Dart FFI), but it is a supported and common configuration.

you could use LLVM to have the C++ compiler itself, and not use Visual Studio

It would be possible to use a different compiler and build system, yes. I described that above.

ghost commented 3 years ago

@stuartmorgan,

I think you have complicated everything unnecessarily, Flutter/Dart should have been powerful enough not to depend on C++. It is not bad that it can use "compiled" libraries from other languages for specific needs (DLLs, ...), but your plugin system should not be based on "compiling source code" from other languages (C++, ....), it should be based exclusively on Dart code and already compiled libraries. In my opinion this would have been powerful enough to do anything and not have the need for other compilers. :) Everything should be more Dart-centric.

Regards, Jose

stuartmorgan commented 3 years ago

I think you have complicated everything unnecessarily, Flutter/Dart should have been powerful enough not to depend on C++.

You keep conflating Dart and Flutter, which is making this discussion needlessly confusing.

Dart does not depend on C++. Flutter is based on a model of a hybrid of Dart and native code.

It is not bad that it can use "compiled" libraries from other languages for specific needs (DLLs, ...), but your plugin system should not be based on "compiling source code" from other languages (C++, ....)

The Flutter plugin system predates Dart FFI by years. You're welcome to your opinion that Flutter should have made different decisions three years ago, but it doesn't change anything about the fact that we have an actual plugin ecosystem right now. Throwing it away and starting over is not going to be the resolution of this issue.

it should be based exclusively on Dart code and already compiled libraries.

We do not share the opinion that having the entire ecosystem being based on precompiled binaries, rather than source, is a good idea. There are severe downsides to that. Even in a world where FFI was the only way to write plugins, we would still want source, not binaries, to be the basis of plugins.

Everything should be more Dart-centric.

You are welcome to write your native code exclusively as FFI calls to prebuilt libraries if you like. It's already supported. That is not the only model we will support, however.

And, again: none of what you are describing is necessary for resolving the request that this issue is tracking. It is possible for Flutter to support the current models using a different compiler and build system. It's a question of the engineering tradeoffs of doing so.

ghost commented 3 years ago

Okay. Thank you very much for all the information and explanations @stuartmorgan.

gspencergoog commented 3 years ago

(Desktop Triage) We would love to be able to build entirely using Clang, but the effort involved in removing the dependency on VC++ makes this a very low priority compared to all of our other tasks.

ghost commented 3 years ago

@gspencergoog It is a pity that you did not use CLang from the beginning, now everything would be compatible. But keep it in mind, since in this way Flutter will honor its Open Source spirit and it will not cause any problems for its users due to licensing issues. :) Thanks.

stuartmorgan commented 3 years ago

@Josua2012 When that decision was made, desktop embeddings were an experimental stand-alone project (flutter-desktop-embedding) that was not part of Flutter, and had fewer engineers working on the entire project than platforms we were trying to support. Sinking a lot of time into handling complex toolchain setup and dependency management for Windows (rather than leveraging the fact that requiring VS solved essentially all of those issues) was much, much lower priority than getting basic functionality working on every platform.

That was an open-source project as well; anyone with strong feelings about toolchains could have contributed PRs to use something other than VS. Nobody did. Second-guessing decisions years after the fact without any knowledge of the context in which those decisions were made and what the constraints were is not productive.

And of course, anyone who feels that this should be higher priority is welcome to address that as described at https://github.com/flutter/flutter/wiki/Issue-hygiene#escalating-an-issue-that-has-the-wrong-priority

ghost commented 3 years ago

@stuartmorgan, Okay. Don't worry, it was just a thought expressed out loud. You are imbued in the project and more than other people you can evaluate the priority of each issue. Keep up the good work, everything you are doing is fabulous. :)

cbracken commented 3 years ago

Just a quick note. Let's please try to keep focused on the issue specifically, since rehashing prior decisions isn't going to help resolve this. If this is a high priority to you, as @stuartmorgan suggests, we have a documented escalation process. Other things that help get this issue resovled, if you are passionate about it:

Document all current bits of the build where we have a dependency on VC++
Document how those steps could be replaced with clang steps
If you're really keen, we'd gladly take a look at PRs!

Worth noting that personally, I would love for us to be rid of the dependency on Visual Studio and on a consistent build toolchain across the board, but as @stuartmorgan points out, we have a limited number of people focused on desktop and a lot of issues that are higher priority in our backlog before we get to this.

codec-abc commented 3 years ago

@Josua2012 : I think you should open another issue for this. This an issue asking to have alternatives to Visual Studio for Flutter Windows on Desktop, not to help you compiling your program against the release version of the MSVC runtime.

Back to the subject, are there workarounds for testing Flutter Windows Desktop in the mean time? I will be pretty happy to test it even with big limitations (no native plugins and so on will be fine for me). Since, a strong point of Flutter is hot reload, it mustn't recompile the application every time so maybe there is a way to "lure it" so it uses a default pre-compiled version. I guess this is rather hard since some parts probably have strong dependencies on the toolchain and won't accept to continue the running and debugging without it. Yet, if anybody has ideas to circumvent VS2019 I will be happy to test them.

ghost commented 3 years ago

@codec-abc I had put this problem in this ticket because of the relationship it has due to the dependency with Visual Studio, but I have been able to verify that in release mode they have solved the problem and do not need those dll's. Thanks. At the moment I have no ideas for circumvent VS2019. :( Regards,

stuartmorgan commented 3 years ago

Back to the subject, are there workarounds for testing Flutter Windows Desktop in the mean time?

Trying it out with local workarounds should be fairly straightforward. The actual tool changes should be minimal since most direct dependencies on VS were removed in the transition to CMake:

Replace the way CMake is located. For a quick hack, you could just hard-code it based on your installation.
Change the generator passed to CMake. We use ninja for Linux, and the CMake files are very similar between the two platforms so I would give that better odds of just working, but you could try make if you wanted to.

You would need to make sure that your compiler was in your path, that ninja or make is in your path, that you had a Windows SDK installed and findable, etc. In short, you would need a fully working setup to build a Win32 application with CMake. (As I mentioned above, it's productionizing all of this--and making sure it's future proof, such as having a path to C# support--that's non-trivial, not the tool changes).

The error-surfacing regex in the build has only been tested with MSBuild, so you'd want to use verbose builds to make sure you see errors.

I will be pretty happy to test it even with big limitations (no native plugins and so on will be fine for me).

In theory I would expect plugins to work; they use CMake as well. In practice, any given plugin may or may not actually compile with a different compiler without slight adjustment.

Since, a strong point of Flutter is hot reload, it mustn't recompile the application every time so maybe there is a way to "lure it" so it uses a default pre-compiled version.

This would be harder to get working than the above, and would have no chance of supporting plugins.

stuartmorgan commented 3 years ago

One potential area of issues is that VS and ninja are very different kinds of generators, since they handle build configurations at different points. I don't know that the Windows CMake file can correctly handle a generator like ninja or make. If you have issues there, comparing to the Linux CMake files may be instructive.

codec-abc commented 3 years ago

@stuartmorgan Thanks for the tips. I really appreciate it. I tried giving a shot at hard-coding the path to my CMake installation but it didn't work. The error message stays the same ( Exception: Unable to find suitable Visual Studio toolchain. Please run `flutter doctor` for more details.) I changed the message to see if at least it changed something in the console, but no luck. So I guess, I either edited the wrong file or the dart file was already compiled and the build process used a cached version.

Anyway, I think I will let this settle down for a bit.

Regarding my idea of having an already compiled executable, do you think it is worth opening an issue so in a distant future such uses cases could work? As a user of Flutter I think there is some appeal. The workflow would be the same for all platforms: On a freshly installed operating system, downloading the Flutter SDK would be enough to get started without additional dependencies nor install. No need for VS on Windows, no need for XCode on MacOS, etc..

I am quite sure this would be even more difficult to do in practice (especially regarding plugins) but it would also lower the entry barrier for Flutter which in the long term would be nicer. What are you thoughts on this?

stuartmorgan commented 3 years ago

or the dart file was already compiled and the build process used a cached version.

If you edit flutter source locally you need to delete bin/cache/flutter_tools.* so that the next run will rebuild from source, otherwise it'll use the previously-built version.

Regarding my idea of having an already compiled executable, do you think it is worth opening an issue so in a distant future such uses cases could work?

It's occasionally been discussed; I'm not sure if there's an existing issue for it. You could certainly file it, and if there is one it can be marked as a duplicate later.

codec-abc commented 3 years ago

I gave this another shot and run into a problem. I went further thanks to your help and the Visual Studio 2017 solution was generated without problem. By the way, I have a full VS 2017 setup working on my computer) :

Yet, the compilation fails because there are undefined C++symbols for Flutter internal stuff:

This is the output I got

flutter_window.obj : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopViewGetHWND rÚfÚrencÚ dans la fonction "public: struct HWND__ * __thiscall flutter::FlutterView::GetNativeWindow(void)" (?GetNativeWindow@FlutterView@flutter@@QAEPAUHWND__@@XZ) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
utils.obj : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopResyncOutputStreams rÚfÚrencÚ dans la fonction "void __cdecl CreateAndAttachConsole(void)" (?CreateAndAttachConsole@@YAXXZ) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
win32_window.obj : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopGetDpiForMonitor rÚfÚrencÚ dans la fonction "public: bool __thiscall Win32Window::CreateAndShow(class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > const &,struct Win32Window::Point const &,struct Win32Window::Size const &)" (?CreateAndShow@Win32Window@@QAE_NABV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@ABUPoint@1@ABUSize@1@@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_engine.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopEngineCreate rÚfÚrencÚ dans la fonction "public: __thiscall flutter::FlutterEngine::FlutterEngine(class flutter::DartProject const &)" (??0FlutterEngine@flutter@@QAE@ABVDartProject@1@@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_engine.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopEngineDestroy rÚfÚrencÚ dans la fonction "public: void __thiscall flutter::FlutterEngine::ShutDown(void)" (?ShutDown@FlutterEngine@flutter@@QAEXXZ) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_engine.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopEngineRun rÚfÚrencÚ dans la fonction "public: bool __thiscall flutter::FlutterEngine::Run(char const *)" (?Run@FlutterEngine@flutter@@QAE_NPBD@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_engine.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopEngineProcessMessages rÚfÚrencÚ dans la fonction "public: class std::chrono::duration<__int64,struct std::ratio<1,1000000000> > __thiscall flutter::FlutterEngine::ProcessMessages(void)" (?ProcessMessages@FlutterEngine@flutter@@QAE?AV?$duration@_JU?$ratio@$00$0DLJKMKAA@@std@@@chrono@std@@XZ) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_engine.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopEngineReloadSystemFonts rÚfÚrencÚ dans la fonction "public: void __thiscall flutter::FlutterEngine::ReloadSystemFonts(void)" (?ReloadSystemFonts@FlutterEngine@flutter@@QAEXXZ) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_engine.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopEngineGetPluginRegistrar rÚfÚrencÚ dans la fonction "public: virtual struct FlutterDesktopPluginRegistrar * __thiscall flutter::FlutterEngine::GetRegistrarForPlugin(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?GetRegistrarForPlugin@FlutterEngine@flutter@@UAEPAUFlutterDesktopPluginRegistrar@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_engine.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopEngineGetMessenger rÚfÚrencÚ dans la fonction "public: __thiscall flutter::FlutterEngine::FlutterEngine(class flutter::DartProject const &)" (??0FlutterEngine@flutter@@QAE@ABVDartProject@1@@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_view_controller.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopViewControllerCreate rÚfÚrencÚ dans la fonction "public: __thiscall flutter::FlutterViewController::FlutterViewController(int,int,class flutter::DartProject const &)" (??0FlutterViewController@flutter@@QAE@HHABVDartProject@1@@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_view_controller.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopViewControllerDestroy rÚfÚrencÚ dans la fonction "public: virtual __thiscall flutter::FlutterViewController::~FlutterViewController(void)" (??1FlutterViewController@flutter@@UAE@XZ) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_view_controller.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopViewControllerGetView rÚfÚrencÚ dans la fonction "public: __thiscall flutter::FlutterViewController::FlutterViewController(int,int,class flutter::DartProject const &)" (??0FlutterViewController@flutter@@QAE@HHABVDartProject@1@@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(flutter_view_controller.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopViewControllerHandleTopLevelWindowProc rÚfÚrencÚ dans la fonction "public: class std::optional<long> __thiscall flutter::FlutterViewController::HandleTopLevelWindowProc(struct HWND__ *,unsigned int,unsigned int,long)" (?HandleTopLevelWindowProc@FlutterViewController@flutter@@QAE?AV?$optional@J@std@@PAUHWND__@@IIJ@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(core_implementations.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopMessengerSend rÚfÚrencÚ dans la fonction "public: virtual void __thiscall flutter::BinaryMessengerImpl::Send(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned char const *,unsigned int,class std::function<void __cdecl(unsigned char const *,unsigned int)>)const " (?Send@BinaryMessengerImpl@flutter@@UBEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PBEIV?$function@$$A6AXPBEI@Z@4@@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(core_implementations.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopMessengerSendWithReply rÚfÚrencÚ dans la fonction "public: virtual void __thiscall flutter::BinaryMessengerImpl::Send(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned char const *,unsigned int,class std::function<void __cdecl(unsigned char const *,unsigned int)>)const " (?Send@BinaryMessengerImpl@flutter@@UBEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PBEIV?$function@$$A6AXPBEI@Z@4@@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(core_implementations.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopMessengerSendResponse rÚfÚrencÚ dans la fonction "public: void __thiscall <lambda_026d1d12cd0cfb562b3371ee0ca577f8>::operator()(unsigned char const *,unsigned int)" (??R<lambda_026d1d12cd0cfb562b3371ee0ca577f8>@@QAEXPBEI@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(core_implementations.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopMessengerSetCallback rÚfÚrencÚ dans la fonction "public: virtual void __thiscall flutter::BinaryMessengerImpl::SetMessageHandler(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::function<void __cdecl(unsigned char const *,unsigned int,class std::function<void __cdecl(unsigned char const *,unsigned int)>)>)" (?SetMessageHandler@BinaryMessengerImpl@flutter@@UAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$function@$$A6AXPBEIV?$function@$$A6AXPBEI@Z@std@@@Z@4@@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(core_implementations.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopTextureRegistrarRegisterExternalTexture rÚfÚrencÚ dans la fonction "public: virtual __int64 __thiscall flutter::TextureRegistrarImpl::RegisterTexture(class std::variant<class flutter::PixelBufferTexture> *)" (?RegisterTexture@TextureRegistrarImpl@flutter@@UAE_JPAV?$variant@VPixelBufferTexture@flutter@@@std@@@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(core_implementations.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopTextureRegistrarUnregisterExternalTexture rÚfÚrencÚ dans la fonction "public: virtual bool __thiscall flutter::TextureRegistrarImpl::UnregisterTexture(__int64)" (?UnregisterTexture@TextureRegistrarImpl@flutter@@UAE_N_J@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
flutter_wrapper_app.lib(core_implementations.obj) : error LNK2019: symbole externe non rÚsolu __imp__FlutterDesktopTextureRegistrarMarkExternalTextureFrameAvailable rÚfÚrencÚ dans la fonction "public: virtual bool __thiscall flutter::TextureRegistrarImpl::MarkTextureFrameAvailable(__int64)" (?MarkTextureFrameAvailable@TextureRegistrarImpl@flutter@@UAE_N_J@Z) [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
D:\Workplace\flutter\flutter_test_windows\myapp\windows\flutter\ephemeral\flutter_windows.dll.lib : warning LNK4272: type d'ordinateur bibliothÞque 'x64' en conflit avec le type d'ordinateur cible 'x86' [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\Debug\myapp.exe : fatal error LNK1120: 21 externes non rÚsolus [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]
Building Windows application...
Exception: Build process failed.

stuartmorgan commented 3 years ago

D:\Workplace\flutter\flutter_test_windows\myapp\windows\flutter\ephemeral\flutter_windows.dll.lib : warning LNK4272: type d'ordinateur bibliothÞque 'x64' en conflit avec le type d'ordinateur cible 'x86' [D:\Workplace\flutter\flutter_test_windows\myapp\build\windows\runner\myapp.vcxproj]

You can't build 32-bit Windows Flutter applications, regardless of the build system or compiler you are using.

codec-abc commented 3 years ago

Nice catch! I didn't specify the architecture to CMake. It is not defined explicitly either in the build_windows.dart file and I don't know how I missed that. It might come from the use of cmake-gui (maybe a cached settings or something like that) when trying to debug previous issues that I had because my version was too old

So doing the following, I now have a working build using VS2017!

To sum up, with a VS 2017 env the following needs to be done:

Make sure the CMake version is up to date. I had an old version < 3.15 and the build scripts required an explicit version >= 3.15. I had strange errors because of that.
Edit packages\flutter_tools\lib\src\windows\build_windows.dart:
- Change the Visual Studio Identifier to Visual Studio 15 2017.
- Change the path to CMake.
- Tell explicitly CMake to build in 64 bits. It should be
```
result = await globals.processUtils.stream(
<String>[
cmakePath,
'-S',
sourceDir.path,
'-B',
buildDir.path,
'-G',
_cmakeVisualStudioGeneratorIdentifier,
'-A',
"x64"
],
trace: true,
);
```
Remove bin/cache/flutter_tools* and run flutter run -d windows again.

JoueBien commented 3 years ago

I hate to be that guy but the windows built tools can be installed separately. You don't need to install a full Visual Studio to get them. There is a completely separate installer for 2015, 2017 and 2019.

Built tools for 2015 https://www.microsoft.com/en-us/download/details.aspx?id=48159

There are built tools for 2017 but MS being MS have replaced all their websites with material for 2019. But you can still find it floating around.

Built tools for 2019 https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2017 Scroll down it's hidden under the Tools for Visual Studio 2019 dropdown.

If your looking for how other languages handle this: Node runs on either a full VS install or just the build tools. Someone even wrote a package to install and configure python (required because node_gypt is written in python) and either the 2015 or 2017 version of the built tools. https://www.npmjs.com/package/windows-build-tools

codec-abc commented 3 years ago

@JoueBien Are you sure you don't need a Visual Studio license to be able to use legally the build tools as well? All the information I found online seems to point that way, which, if true, means we are back to square one.

JoueBien commented 3 years ago

@codec-abc Reading through at least the 2015 and 2017 licences for the build tools and they don't appear to require a pre-existing VS licence.

The 2019 build tools seem to use an almost exact clone of the 2015/2017 licence.

Disclaimer - I am not a lawyer.

I think the main thing to note is that you can't redistribute the built tools installer or the installed files. Node requires the build tools to be installed separately and a path variable to be set before node is able to use node_gypt to recompile things.

PS sorry that 2019 link is wrong. I think this is actually the link https://docs.microsoft.com/en-us/visualstudio/install/create-an-offline-installation-of-visual-studio?view=vs-2019 scroll down a little bit and there it is under "Visual Studio Build Tools"

stuartmorgan commented 3 years ago

If your looking for how other languages handle this: Node runs on either a full VS install or just the build tools.

This is already true of Flutter.

WaleedTageldeen commented 2 years ago

@JoueBien, I am not sure about visual studio 2015 and 2017, but for visual studio 2022 it's stated in the build tools download section that you need a valid visual studio license to be able to use the build tools. Also, visual studio 2019 license states that you can use the build tools only with one of visual studio versions.

marlon-sousa commented 2 years ago

Not being a lawyer my interpretation is that vs tools would not be bound to the license needed to run the full IDE, to many open source apps would fail if the licence is needed.

If the build tools can be used in a free manner it seems to me that most part of this issue, if not all of it, would be already solved by itself. As a suggestion if I were Google I would ask folks from legal department for assistance on this matters, at least I would feel more comfortable having someone specialized in laws ratter than myself as an engineer to look at this ... and see what they think. If this could be possible it would be really great.

stuartmorgan commented 2 years ago

to many open source apps would fail if the licence is needed.

Visual Studio has specific usage provisions around open source, so that's not really relevant here. The request was specifically about commercial development.

As a suggestion if I were Google I would ask folks from legal department for assistance on this matters, at least I would feel more comfortable having someone specialized in laws ratter than myself as an engineer to look at this ... and see what they think. If this could be possible it would be really great.

The Flutter project does not provide legal advice.

Gustl22 commented 2 years ago

@stuartmorgan can we at least add docs to windows setup to optionally only install visual studio build tools and update to 2022? (I would make a PR)

cbracken commented 2 years ago

can we at least add docs to windows setup to optionally only install visual studio build tools and update to 2022? (I would make a PR)

I'm happy to review verbiage around visual studio community edition or visual studio build tools as supported for open source development. Our build infra currently uses 2019 (https://github.com/flutter/flutter/issues/96138 tracks adding 2022 tests) but 2022 is supported so I think it's fine to recommend that as well.

pc-magas commented 2 years ago

Do visual studio c++ compiler has same argument with mingw? AFAIK at CMake it is feasible to set different compiler: https://stackoverflow.com/questions/7081820/setting-default-compiler-in-cmake

Whereas platform can be checked as well: https://stackoverflow.com/questions/9160335/os-specific-instructions-in-cmake-how-to#9160449

And mingw be specified as well: https://stackoverflow.com/a/54893215/4706711

Is there a way to check it via manually running cmake and specifying the appropriate compiler instead of the visual studio offers as proof of concept?

Linux does offer mingw that can be used for cross-compiling windows apps in linux:

$ apt-cache search mingw | grep gcc
gcc-mingw-w64 - GNU C compiler for MinGW-w64
gcc-mingw-w64-base - GNU Compiler Collection for MinGW-w64 (base package)
gcc-mingw-w64-i686 - GNU C compiler for MinGW-w64 targeting Win32
gcc-mingw-w64-x86-64 - GNU C compiler for MinGW-w64 targeting Win64

$ apt-cache search mingw | grep g++
g++-mingw-w64 - GNU C++ compiler for MinGW-w64
g++-mingw-w64-i686 - GNU C++ compiler for MinGW-w64 targeting Win32
g++-mingw-w64-x86-64 - GNU C++ compiler for MinGW-w64 targeting Win64
libconfig++-dev - parsing/manipulation of structured config files (C++ development)
libconfig++9v5 - parsing/manipulation of structured configuration files (C++ binding)

mirecta commented 1 year ago

any news here , i mean use mingw64 instead m$ visual anything is not so hard ??

YouJiacheng commented 1 year ago

@stuartmorgan Can you clarify "Dart has its own compiler. VS is used to build the runner application and plugins (C++), not compile the Dart code. Just as on iOS and macOS, Xcode is used to build those components."?

According to that, only open source C++ dependencies (flutter runner and plugins, if all plugins are open sourced) are compiled by VS. Is my understanding correct?

If so, with the updates to Visual Studio Build Tools (VSBT) license, there is a new license option to use VSBT for free, even when you are working for an enterprise on a commercial or closed-source project.

Visual Studio Build Tools (VSBT) can now be used for compiling open-source C++ dependencies from source without requiring a Visual Studio license, even when you are working for an enterprise on a commercial or closed-source project.

If you are an enterprise developer or developing any closed-source projects, this change now allows you to use Visual Studio Build Tools to compile and build any C++ 3rd party open-source dependencies, without needing a paid Visual Studio license, when you’re not using Visual Studio for active C++ development.

https://visualstudio.microsoft.com/license-terms/vs2022-ga-diagnosticbuildtools/

1. INSTALLATION AND USE RIGHTS. a. ... b. Build Tools additional use right. Regardless of whether you have a Visual Studio license as described above, you may install and use copies of the software to compile and build C++ components that both have been released by their owner under an open-source software license approved by the Open Source Initiative and are reasonably required to build your applications (“Open Source Dependencies”).

@Josua2012 WDYT?

marlon-sousa commented 1 year ago

This being true, I think we can greatly advance towards not needing visual studio at all. In theory, as far as I know, the build tools should be more than enough to complete the proces!

stuartmorgan commented 1 year ago

According to that, only open source C++ dependencies (flutter runner and plugins, if all plugins are open sourced) are compiled by VS. Is my understanding correct?

The C++ runner source in the windows/runner/ subdirectory of a Flutter application project is part of each individual Flutter application, just as the dart code in lib/ is. Whether or not any given application's C++ code is open sourced is up to the developers of that application.

YouJiacheng commented 1 year ago

So if the developers open source windows/runner/ or do not modify it (w.r.t. https://github.com/flutter/flutter/tree/master/packages/flutter_tools/templates/app_shared/windows.tmpl/runner), the C++ runner might be treated as an open source C++ dependency. And all code in lib/ won't be touched by VSBT. Thus, using VSBT for free (to compile C++ runner) in commercial flutter software development might be realistic.

stuartmorgan commented 1 year ago

@YouJiacheng Please don't post assertions about legal conclusions here, especially phrased as fact, since people may misunderstand and think that you are stating an objective fact and act accordingly. I've hidden the comment to minimize potential confusion.

This is not a forum for legal advice; anyone trying to determine whether their specific use case meets any given license's requirements needs to discuss with a lawyer. If non-lawyers want to speculate about legal conclusions, please do so in another forum. Discussion here should be focused on the technical aspects.

YouJiacheng commented 1 year ago

Okay I use "might" now. (I thought "realistic" as "realistic probability" so I didn't use "might" before) Is it correct that "all code in lib/ won't be touched by VSBT."?

stuartmorgan commented 1 year ago

Is it correct that "all code in lib/ won't be touched by VSBT."?

I don't know what you would consider to be "touched by", so I can't answer that. Unless you have forked the tooling along the lines of earlier discussion in this issue, the entire build other than some initial configuration is driven by a Visual Studio solution file (itself generated from a copy of CMake that's part of the Visual Studio installation).

mirecta commented 1 year ago

This is not about licences of M$ but about ability to build windows binary on linux or on macosx.

annymosse commented 1 year ago

This is not about licences of M$ but about ability to build windows binary on linux or on macosx.

I'm here for same reason, when talking about testing the app before releasing it "the test for my case can be done on linux/web only, since I got the same results on my Windows's VM copy", I think making this feature available optionally will open the door for more users and contributors and provide a better roadmap for future planing. (Note: I tested my application after build it on windows on linux via wine and it works fine).

pythonwood commented 1 year ago

I am a Linux cross platform DevUser. visual studio is too large/heavy. so I just want a virtual machine box for build window desktop app. but

WAY 1: after install flutter in windev, I get "no nescessary c++" so on... https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/

WAY 2: vagrant box or ova box I try to run flutter , flutter doctor still fail. https://app.vagrantup.com/senglin/boxes/win-10-enterprise-vs2015community

I hope there will be flutter windev virtual machine box in vagrant.

flutter / flutter

Avoid requiring Visual Studio for Windows development #77638

Use case

Proposal