Hi Tom, On Tue, 25 Apr 2023 at 10:04, Tom Rini <tr...@konsulko.com> wrote: > > On Tue, Apr 25, 2023 at 04:59:53AM +0200, Heinrich Schuchardt wrote: > > > > > > Am 25. April 2023 01:08:05 MESZ schrieb Simon Glass <s...@chromium.org>: > > >This expands the existing work to allow sandbox to build and run on > > >Windows using MSYS2. > > > > Why do we need this? > > Wouldn't a developer on Windows be much better served using WSL > > (https://learn.microsoft.com/en-us/windows/wsl/install)? > > Depending on corporate rules that may or may not be allowed. But I too > am interested in the use case driving these changes. Sandbox is > essentially a test platform. We test that we can do host tools on > Windows via MSYS2 for semi-reasonable reasons, since those tools can be > used in a number of places. We do the same on macOS in Azure as a check > on building regular targets there too (which should work and I believe > people do, both from macOS and from *BSD which this is a stand-in for, > as we can't get free VMs for them today). What's the end goal of this > series?
It is really just an extension of the existing tools-only build. I am not sure it is strongly motivated, but the end goal is to be able to do small features / development on U-Boot on Windows, since some users seem to only use a 'pure' Windows environment and don't use WSL, which after all is for cross-compiling. For example, it is possible to build a FIT and check it using the tools, but it is not possible (without this series) to see whether U-Boot will load it and behave correctly. The binman changes are to make that work on Windows (pip install binary-manager) which is important for that tool. The 'weak' issue is something that I am hoping can be resolved (in fact Bin made a promising comment on that patch). This has all come up as we try to establish a standard 'payload' format which can be used across the industry. For better or worse, some people do use Windows for development. Regards, Simon