[petsc-dev] WSL upgrade

[Satish Balay]

On Thu, 13 Apr 2017, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> 
> > On Thu, 13 Apr 2017, Jed Brown wrote:
> >
> >> Satish Balay <balay at mcs.anl.gov> 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.