<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>The most important issues that makes running the configure script on UOW difficult are:</div><div><br></div><div>- 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.)</div><div><br></div><div><div>- 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 <a href="http://configure.ac">configure.ac</a>, 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).</div><div><br></div><div>- Environment variables don't get exported to Windows programs. This affects at least the place where <a href="http://configure.ac">configure.ac</a> 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.</div><div><br></div><div>- Some mysterious issue where redirection of stderr of a Windows program to /dev/null in a pipeline causes stdout to disappear, too.</div><div>  </div><div>- 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"'.</div><div><br></div><div>So my take at this stage would be: Let's just forget it.</div><div><br></div><div>--tml</div><div> </div></div><div><br></div></div>