 My talk is basically a short update on my work on getting a LibreOffice build working in the WSL environment and basically we can go straight to it. What is WSL? WSL is a Windows subsystem for Linux and that is basically a lightweight emulation layer that allows you to run Linux distributions within Windows and you can have multiple different versions installed by side by side without issues. You can use them simultaneously and what's also a nice feature is that you can seamlessly share files between the Linux realm and the Windows realm and this works both ways and also calling the applications. Linux tools from Windows side works by just prefixing the command with WSL and then the command in the Linux container but you can also do the opposite way just call a Windows program by using the path to the Windows executable from your Linux container. And this virtualization doesn't block you from using other tools like a virtual box so the use can run in addition to having a WSL system running and the WSL2 version also gained the capability to use graphical applications seamlessly on your Windows desktop and it's even integrated in the Windows start menu so if it's a default application entry for this in your Linux distro you don't have to configure anything you can type the Windows key and start typing the first letters of the Linux applications and you can run it seamlessly and also with a pretty good speed so there's no slugginess like if you were to set up a manual VNC for example on a Linux box and try to use VNC to call into that box there's always the delay of the screen refresh but with the GUI support in the WSL there's none of that so it's a great way to use Linux tools on Windows when there's no equivalent available but yeah why would you even consider building a Linux version when you are a Windows user? And I guess the main point why I started looking at into it is the point of reliability. The Windows builds we are currently using the setup is pretty flaky and it fails randomly and in an unpredictable way. That doesn't mean that our Linux builds are without fault but at least the compilation stage the the building stage is reliable so you usually only get problems when you start the testing phase when there's timing issues or similar stuff but the build itself using Linux is pretty reliable and stable and of course it's also a matter of convenience if you're using Windows because your bank application requires a special tool that doesn't run on Linux or if you're a gamer and that's why your primary desktop is a Windows you don't have to set up a dual boot system or use a VM with an additional overhead to be able to use Linux tools and compile LibreOffice for Linux for example and then there's a nice benefit of being able to just compile faster on the one hand because you can use a system libraries instead of compiling ship versions quite easily on Linux and you can use Ccash and this is especially handy if you're starting from scratch often but yeah and the other point is ease of deployment because Linux machines or at least the software that is needed to build LibreOffice is all freely distributable it's easy enough to create either a recipe that other people can follow to install it in one or two command lines or you can also create a full copy of the of the VM image that other people could then import yeah and if you're familiar with building LibreOffice on Linux then you don't have to learn anything else it's exactly the same procedure so they need the the same packages and the build works exactly the same way and as mentioned you can use Ccash without a problem right now on Windows Hossine is trying to get Ccash support for Windows builds but in my experience it on the one hand doesn't even accelerate the build compared to pre-compiled headers and also the subsequent build making use of the Ccash results fails for me for example so none of those problems exist on Linux so this is a way to speed up a development process and another selfish more or less point is that it's easy enough to create the release baseline with that Alma Linux the new baseline for master branch and the new versions is even available as an image that can be installed using the Microsoft Store app so you don't even have to to browse the internet where to find the image to import you can just use the Microsoft Store and tell it to create an Alma Linux 8 installation and then install the packages that are listed on the wiki for that release build baseline and yeah as mentioned it's possible to create exports and imports images so if you want to use a random other distro of your choice that is not readily available in the Windows Store you can usually just start by finding a docker image and import that and just go from there and yeah basically you you're not restricted to what's available in the Microsoft Store but basically any Linux distribution can be used it's a just a matter of preference then and yeah speed again this is probably the most important thing why people would want to use it if you ever used git within sequin I think you can appreciate how much fast it is for example on a Linux box or even in the native git version and yeah I cannot underestimate how how frustrating it is to have to wait for felt eternity for a simple git status command and of course this is also a problem with CI when a build gets interrupted during the checkout phase the repository can leave the lock file behind and then it fails at tons of builds in quick succession just because the build got interrupted or about it during the checkout stage and yeah why then do the effort of building the Windows version from the Linux environment and to prepare the system and something new we used a sequin because it basically offers the same kind of environment for a build so the goal is just to replace sequin with a wsl instead and it still would use the visual studio compiler and not something like min gw or something similar it's basically just replacing sequin and still using all the Microsoft tools for the actual build and yeah you might ask why you replace sequin and yeah again the speed the sequin is pretty slow especially when it comes to file operations as well as when it comes to forking your processes creating new instances of the processes and this is of course heavily used in our build especially when you're building with all languages or also building with help then this really hurts the build time and also related to this sequin especially when used on the CI system can be quite a diva it's very temperamental and there are random failures that basically result in a failure to launch a program and Windows then just displays a dialogue waiting for a user to close dismiss the dialogue for the build to actually fail and this is one of the causes for leftover issues on RCE system that in the meantime were kind of worked out by just taking the bot offline if it detects such a situation but of course this is only a workaround it doesn't solve the problem and with the wsli I hope that is a step in the direction to solving this issue and another is near problem depending on how you look at it is that it's hard to have a single or a uniform baseline when using sequin as a baseline because it's more or less a rolling type of a fair worth of sequin so depending on when you install or set up the system you might have different versions of the utilities and libraries installed and compared to half a year later and while this hasn't been a problem recently it has been in the past and required users to back to a specific version of the segment DLL and stuff like that and of course if you have a Linux distro that is not of the rolling type then it's much easier to to have a unknown state so to speak and yeah with so many things there are too many ways to do stuff and I indicated or mentioned earlier that there's a difference between working in the Linux container run where this working on the on the Windows side and file access and stuff is speedy within wsl2 but if you were to access files from the Windows side or the opposite way then there is overhead not quite as bad as with sequin but at least I noticed a drawback and the prior version of wsl didn't have this problem so the interoperability between the cross access of files was much better but of course the access times within the container would be much lower as in some cases I read it wsl to improve the within Linux access up to up to 20 times so this is of course one of the drawbacks you have to weigh in on designing which way which approach you take and yeah for the moment I just didn't go with the wsl one approach because yeah then you lose the the benefits from using wsl2 for also using it as a as a tool to create Linux versions but of course since they are pretty similar it can be tested later and yeah as mentioned yeah my approach is different from the initial hack that was created by Tor he I think tried to use it control the build from the Linux container side but yeah I didn't go that throughout I wanted to have it much as few things as possible from the wsl container and do as much as possible on the on the on the Windows side but of course this then poses the question how do you bootstrap this environment and PowerShell or Windows command prompt are pretty different from a bash shell and that's why I said that pretty risky to try to to hack our configure system into something that is completely alien to what was done before so I basically took a shortcut so to speak and I'm using a git bash that can be installed from Visual Studio and it's using mcs2 which is similar to sqn basically based on sqn but not quite sqn and of course just this single component and the build then starts off by running the autocan.sh within the container you see the wsl.slash.autocan.sh command this tells it to run this command the autocan.sh and the linux container and since sqn already is a Linux like environment this more or less works but of course all the stuff that is specific to Windows needed addressing for example we have a lot of detection for a file path that are looking up the registry and in sqn this is exposed using the proc sudo file system bent yeah of course this is not available in wsl so I had to create a little helper it just uses a simple bed file to get the relevant registry keys and yeah also our configure is quite inconsistent when it comes to how a file name or file path should be handled so there's a valid mix of using linux style path versus the mixed style windows path which means forward slashes and the traditional windows path or file names using the backport slashes and of course this also needed addressing because wsl itself only can deal with the linux path and if it accesses a path of the windows side it has to be using a mount path and there's a unfortunate thing regarding the difference between sqn and wsl both have or helper functions to convert paths between the two systems but wsl is path convert function for example fails hard if it's already in the form you want to get so if you're requesting it to get a unix style path and pass in an already unix style path then you get an empty result and of course this was messy and made a configure very bloated in my first attempts and yeah I decided it's not worth to spend too much time on making the configure situation nice or ready to to integrate straight away instead I just ignored all the specifics about the differences between wsl and sqn and just tried to make a configure pass and then to make it actually suitable for use with wsl I created a helper script that just modifies the values from config underscore host.mk the the file that it makes reads with all the variables that are needed for the build all the different utilities out of the path and during that script I also unified the path to work like that and yeah it's not nice not something that is ready to be integrated but it worked just fine and let me proceed with the rest of the work and yeah unfortunately unfortunately LibreOffice is not just a single piece of software it requires or uses lots of eternal stuff and every project more or less has its own little quirks here and there and expect different environments rather best or not and so honestly I didn't want to again before even working out the main part it didn't want to spend much time in fixing each and every external project this so I tried to disable using the real-time config switches as much as possible and yeah at least this got me going and there was another unexpected side effect of using the AMSYS version of of bash there because it tried to convert everything that it thought was a path that did not exist already and example we are using many options for the compilers that start with the forward slash option the one of their ways on Windows 2 specify optional flags and this then was turned by AMSYS into C program files git bash slash over and of course this broke the build obviously and one way to fix this or address this was to change the switches to just using the hyphen style that is also supported and this made the problem go away or also as a way to use double slashes at the first instance of a slash this also prevents this behavior but of course yeah this was quite a teacher's approach and you know made the make files a little ugly and especially and with the idea behind you that I don't didn't want to break support just by adding support for WSL this made me question the the viability of this approach and yeah even if many external libraries and stuff are optional not everything is so either you have to use a system component or compile it as part of liberal office and at some point I just had to add support for the for the external libraries and this is where I hit a roadblock that would turn out to be a blessing in disguise and it's a pearl of all things there's a different way to configure pearl in which it should have a file path and open SSL just insists on having a pearl that uses a window style path and patching the build system of an external is always very flaky and might change within next update and so I certainly didn't want to do major changes to the externals and how that work so instead look for alternative solutions and found it in the means of strawberry pearl this is a windows version of pearl that behaves as expected from the open SSL points of view and is also available as a portable distribution so it doesn't conflict with anything else you have on the system you just track it into the directory and can use it from there but without impacting the rest of your system and yeah this of course made it no longer necessary to call a pearl from within WSL so this cleared up lots of calls by just using the strawberry pearl runtime instead not just for open SSL but in other places and that in turn saved me from quoting path for the make shell invocation and then to make sure to convert them to the WSL convention using the mount point style of path and as a side effect it also comes with some additional tools that I also then didn't have to call from within WSL like for example the resource compiler or thinker tool and yeah I said a blessing in disguise turns out because yeah that allowed me to strip a lot of special casing in the in the new build portion of our make files and then another blessing I found the magic invocation on how to disable the path conversion that msys does and yeah this was really the the breakthrough in quotes that made me have confidence in this whole thing again this made me make files so much cleaner and it started to look pretty clean and I hadn't adopted anymore that I can make it work without breaking the second way of building and yeah I of course as a release engineer I'm focused on also providing the installation sets and this was the last thing that needed fixing and again this was surprisingly easy again it's just the most tedious because the install set code is this pearl in disguise only it's not using pearl way of doing things it's just using pearl language and it's unnecessary convoluted and has lots of leftovers from ages ago that are not really longer used and make finding your way around who are complicated and also uses the anti-patterns of of removing the interesting bits of error logs the actual error of the command that failed is submitted to most of the times and this makes it annoying because then you have to dig where so the command called let me get you the error message and once you see the error measures usually particularly what needs to be actually fixed and yeah the result of all this is that I got it to work it I had none of those random failures that I had with Sigmund but this is of course not conclusive because my build machine at home is not as powerful cannot build with that high parallelism like the CIM machines can and of course they don't my machine doesn't do build or after build after build and unfortunately there is a new issue that's popped up and windows tries or randomly suspends one of the accessibility processes that I used during creation of help and I was really thankful this is a wrong word but I was relieved that it wasn't related to the WSL environment because also I'm not sure who it was in Micah Gansky or maybe Noel also head of the Sigmund based building environment so yeah this is just an annoyance because the build doesn't proceed it just waits forever until the command is either either killed or handled in in another way and I honestly expected the build to be a little faster but it turns out it actually a slight a slight penalty of using this approach and if you're talking about a four hour build time it's around 10 minutes so it's not that much of a slowdown but still I would have expected the build to be a little faster but yeah it was summertime and the my laptop was thinner throttling so it was hard to have reliable numbers and I still need to look into what exactly is causing the slowdown compared to a second build but even if it's slower it's not significantly slower if you factor in the benefits of an offset if a build fail and need to redo a whole build because of the random failures so I still want to go ahead with the approach and yeah and basically make it integration ready and yeah there's an easy thing that can be tried still is by just using WSL and see how that stands but yeah getting to get around to try that yet but at least in my approach there's nothing specific to a WSL for the Windows build part but of course yeah you're not getting the GOI support in this case but for building the Windows version that's not necessary sorry yeah what's next next things is to clean up Convicker and remove all of my nasty print style debugging stuff and make it work with not my hardcoded parts but yeah make it happily coexist with the SIGWIN way and I'm thinking of keeping the post-processing of Convicker host mk because it's much easier approach if it was all handled in Convicker you basically have to duplicate every SIGWIN section and the Windows handling in the Convicker is already so so fast so I'd rather avoid that but yeah I'm not fixed on that yet but at least it looks to be the the simple option and yeah and of course I need to actually put it through its paces by using the same hardware where the errors with the green pop-up and this requires me to deploy Windows 10 or 11 on the build machines first and then I can do a larger scale test by looping the build basically and replacing the current Windows baseline is on the is planned anyway because the current systems which are Windows server 2012 R2 are reaching the end of life so I will be switching to Windows 11 anyway and yeah then I can test the SIGWIN versus WSL performance on the on the real CI setup yeah and I think I were in time just in time so if you have questions I'll be around so or maybe Stefan you can come down and set up already then if you have any questions thank you