[PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows
Erik Joelsson
erik.joelsson at oracle.com
Fri Dec 14 22:56:05 UTC 2018
On 2018-12-14 14:22, Magnus Ihse Bursie wrote:
> Hi Erik,
>
> I missed your comments a bit down in the message. Replies inline.
>
> On 2018-12-14 19:23, Erik Joelsson wrote:
>> In configure today, we generate the SYSROOT_CFLAGS but we do not use
>> them in the configure script. Instead we rely on INCLUDE/LIB being
>> set. This is of course not ideal, but having to set
>> WSLENV=INCLUDE:LIB makes it more obvious. It would be better to
>> append SYSROOT_CFLAGS to CFLAGS for Cygwin and msys as well, but that
>> change is not required for WSL to work.
> I see. I agree that we should change this behavior for all windows
> envs to use SYSROOT_CFLAGS. But for now, I accept the WSLENV solution
> then.
>>
>> Replacing the path works for Cygwin, but not for WSL. At least not
>> the way we generate the VS_PATH in this patch. The VS_PATH will not
>> inherit the PATH from the WSL environment as base, it will get the
>> Windows PATH that was set before WSL was launched. We could perhaps
>> improve the extraction logic to make this work better. See below.
>>
>>> * This is a question as much to Erik as to you: is it really correct
>>> to *always* rewrite VS_PATH to unix style? (I'm talking about lines
>>> 470..486 in toolchain_windows.m4) I think not; this sounds like it
>>> will break cygwin. I think we should to this either conditionally on
>>> us running on WSL, or we should convert it to a VS_WSL_PATH instead.
>>> Or maybe I'm just missing something, I'm starting getting a bit
>>> confused about all these paths and conversions...
>>>
>> In configure today, we do rewrite it, but it happens implicitly in
>> the extraction script. The current version of the patch looks like
>> what I posted. I will try to explain. In configure today, we generate
>> extract-vs-env.bat, which end up containing lines like this (in cygwin):
>>
>> C:/cygwin64/bin/bash.exe -c 'echo VS_PATH=\"$PATH\" > set-vs-env.sh
>>
>> (note the unbalanced '. This is baffling me, but currently works in
>> Cygwin.)
> ! :-o
>>
>> The bat file calls back to bash to evaluate the env variable. When I
>> tried to get this to work for WSL, I had trouble getting the quoting
>> to work. I had also forgotten about WSLENV so $PATH would not be
>> translated, it would hold the default bash path, and for the other
>> variables (INCLUDE and LIB) they simply did not get values in bash.
>> My solution was to ditch bash here and just generate lines like this
>> instead:
>>
>> echo VS_PATH="%PATH%" > set-vs-env.sh
>>
>> This outputs the pure windows versions of the variables. For Cygwin,
>> the old construct resulted in an implicitly converted PATH variable
>> (though still with spaces!), but LIB and INCLUDE still pure windows.
>> This is why we already have the conversion loops for those below.
>> With the new construct, all variables remain pure Windows, which is
>> arguably more consistent.
>>
>> So to work around now having pure windows paths in VS_PATH, I added
>> another rewrite loop. This is a bit inefficient, but has the benefit
>> of generating space safe paths in VS_PATH, which is a must if we are
>> to prepend them to FIXPATH.
> I don't think we need to worry too much about efficiency in this case.
> We have a lot of inefficiencies in the path handling on Windows. The
> important thing is to get good and sane paths out of configure, so we
> can work with them easily in make.
>
I just tried the patch on Cygwin and it isn't working. The new PATH
variable we create this way does not contain /usr/bin, but instead
/cygdrive/c/cygwin64/usr/bin, which doesn't actually exist. Cygwin fakes
/usr/bin internally, but if it's expressed as a /cygdrive path this
faking fails. The consequence is that make fails to find "gawk" later.
This variable extraction will need an overhaul before we can take i this
patch.
/Erik
More information about the build-dev
mailing list