On Thu, 13 Apr 2017, Jed Brown wrote: > Satish Balay <[email protected]> writes: > > > On Thu, 13 Apr 2017, Jed Brown wrote: > > > >> Satish Balay <[email protected]> writes: > >> > I'm on the new one. (version 1703, buid: 15063.138) > >> >> > >> >> Windows <-> Linux Interop > >> >> > >> >> https://blogs.msdn.microsoft.com/commandline/2017/04/11/windows-10-creators-update-whats-new-in-bashwsl-windows-console/ > >> >> > >> > > >> > Notice the path (/mnt/c/temp) - its Windows FS - not WSL FS. That > >> > works fine [as I mentioned earlier with my example usage] > >> > >> Oh, well if all the Linux tools work for Windows paths then you could > >> just build on a Windows path? That would seem natural if you're trying > >> to create a Windows-native build. > > > > Sure - and all build tools have to do that [i.e override /tmp usage by > > configure with TMPDIR etc..] > > > > I'm just counteracting the notation [which I think is implicit in such > > discussions] > > - WSL is here - so its time to dump cygwin [ => cygwin is bad; WSL is good] > > - cygwin is hard - but WSL is easy > > etc.. > > > > We should view is as another additional system that we plan to support > > [with its own quirks] - and requires similar amount of work.. [Chris > > spent considerable amount of time coming up with win32fe] > > I don't use Windows for anything, but I always hear Windows users being > reluctant to use Cygwin, even if only to build software. My perception > is that they would be more amenable to using WSL to build.
Users might perceive WSL to be easier than cygwin - but that doesn't remove the complexity that exists. Satish > If that's not true, there's no need to pay attention to WSL > updates.
