Re: Using the linux subsystem on windows for building libreoffice for windows

I spent some hours this weekend to check how hard it is to make even the
configure script work in Ubuntu on Windows ("UOW"). And it is, quite
complicated. There are numerous details that cause problems. I will
describe them below.

But first, let's consider whether it would be even worth it to try to
support building LO from UOW at this stage. My take is no, not at all.
Because the only people who would be even capable of building LO that way
would be those running Windows 10 Creators Update. Knowing how conservative
developers (both those whose main platform *is* Windows, and especially
those whose main platform is Linux, and who run Windows only because they
must, but actually hate everything of it), it will take a very long time
before Windows 10 could be required. Until that we would have to support
both Cygwin and UOW. Which is not fun.

The most important issues that makes running the configure script on UOW
difficult are:

- There is no command in UOW corresponding to the Cygwin "cygpath" command.
We would have to write such a command ourselves, which isn't rocket
science, but just one more hurdle. (In my test, I worked around this by
using the Cygwin "cygpath" command from UOW, and doing a "ln -s /mnt
/cygdrive" in UOW. But obviously that is not a permanent solution if the
very point is to not need Cygwin.)

- Unlike Cygwin, UOW does not recognize files using Windows pathnames (like
"C:/PROGRA~2/MIB055~1/2017/COMMUN~1/VC") at all. Files names by such
pathnames don't exist as far as Linux (UOW) processes are concerned. I.e.
the equivalent to "cygpath" will have to be used much more in configure.ac,
and one has to be very careful to keep track of which variables represent
Windows pathnames (to be passed to cl.exe in -I switches etc) and which are
Unix pathnames (to be used in the shell script itself).

- Environment variables don't get exported to Windows programs. This
affects at least the place where configure.ac exports the INCLUDE
environment variable before trying to run cl.exe. OK, so that particular
case can be worked around by using additional -I options instead, but in
general, this seems like a fairly serious limitation, that probably would
cause much harder problems later. Like if you actually would want to run a
LO built for development purposes from a UOW shell, passing it SAL_LOG and
other environment variables.

- Some mysterious issue where redirection of stderr of a Windows program to
/dev/null in a pipeline causes stdout to disappear, too.

- The 'test' and other commands are case-sensitive, while we tend to treat
the exact spellings of files we look for in MSVS and SDK installation
directories rather randomly. This is really incredibly stupid. We would
have to carefully check all the spellings for case correctness, and change
things like 'test -f
"$WINDOWS_SDK_HOME/lib/$winsdklibsubdir/um/$WINDOWS_SDK_ARCH/user32.lib"'
to 'test -f
"$WINDOWS_SDK_HOME/Lib/$winsdklibsubdir/um/$WINDOWS_SDK_ARCH/User32.Lib"'.

So my take at this stage would be: Let's just forget it.

--tml