How to install on Windows

[hubaishan]

I downloaded file form azure but it does not run I have a long error msg there are missing files

[alerque]

I'm a little behind on how Windows is expected to work myself. We don't have anyone actively developing it right now so it might be out of sync. That being said the std dependency is not new. On the *nix side of things it would be provided by luarocks install stdlib along with a number of other Lua rocks that SILE expects to be available on the host system.

Besides the binary that you tried to run, did you download the rest of the artifact(s)? Is there a lua_modules folder in there with the other dependencies called out in the rockspec?

[ctrlcctrlv]

Do you want my help?

I develop Qglif on Windows and although currently using Arch, patched FontForge to support drive letters. This required compiling on Windows and figuring out GDB on Windows.

Basically you should be bundling everything into the exe. My opinion. At least the zip.

User should not need to hunt down the rocks. On FontForge project we bundle an entire Python distribution which we call ffpython.exe

[alerque]

Last I know the Windows builds were setup in a way that bundled all the dependencies and a the Lua interpreter itself. The downside was there is no installer yet, it was just a dump of the build output.

One caveat is that in order for SILE to be SILE it kind of needs to play nicely with some sort of Lua ecosystem external to itself. Otherwise we'd just have written it in something more manageable and less hackable.

[ctrlcctrlv]

I see. For FontForge I think we use a freeware installer. But we also distribute artifacts which are just a dump of the build output, as you say.

[ctrlcctrlv]

A freeware installer generator, I should say

[pkulchenko]

@alerque, rockspec includes "stdlib == 41.2.2-1" reference, but I don't see the library in lua-libraries, which is probably why it fails to run (also Penlight is required, but is not present either). Penlight dependency was added in 43a790046 and std dependency in b89ca97f4; all the dependent libraries had been dropped in cebf6b48, so naturally they are not available unless luarocks dependencies are installed (which is not a valid expectation for windows binaries).

I may be an odd case, but I compile my own binaries on Windows (including SILE) and don't have luarocks installed.

[alerque]

@pkulchenko For the last dozen or so releases we have been expecting the system/user to supply the LuaRock requirements. There is an install mechanism that does this for them by running luarocks and installing into lua_madules/, then bundling that vendor directory as part of the install. We do not include the source code for those dependencies in our tree any more. The things in lua-libraries are the remnants of when we did include vendor source code in our tree and represents the bits we still haven't migrated to the new system yet. Mostly it is either vendor code we have modified and not published as a LuaRock or single-script tidbits that are not published properly. Eventually I'd like to get all of them cleaned up, I believe there are open issues to track removal of everything left in lua-libraries.

For Linux it is optional whether you install with system supplied luarocks (as most distros prefer) or vendored ones bundled in the SILE‌ install. For Windows I expect only the bundled vendor code approach to be useful. We still need an install mechanism that actually puts things where they belong.

Note if it is useful we could provide a source tarball that had that vendor bundling step done and all the LuaRocks downloaded, but some of them require system specific binaries to be built, so I think that step will need to be done by luarock as part of the install. I don't think we can just bundle the dependency sources raw and have it work.

[pkulchenko]

For the last dozen or so releases we have been expecting the system/user to supply the LuaRock requirements.

I understand; I was just pointing out that for those getting Windows binaries, the expectation may be that all the dependencies are already included (and they are not at the moment). I agree with @ctrlcctrlv on this (at least as part of the zip/installer).

Note if it is useful we could provide a source tarball that had that vendor bundling step done and all the LuaRocks downloaded, but some of them require system specific binaries to be built, so I think that step will need to be done by luarock as part of the install. I don't think we can just bundle the dependency sources raw and have it work.

I agree, but it's not too different from other dependencies that are being built in a platform-specific way. Some of the binary Lua dependencies and be built and bundled together with the rest of the platform-specific binaries.

[goyalyashpal]

Same with me. I took the build artifacts from here, which I picked assuming it to be later than the SILE v0.13.0 Release (as per the commit timestamps).

the page: https://dev.azure.com/sile-typesetter/sile/_build/results?buildId=1251&view=artifacts&type=publishedArtifacts

or the link to the zip: https://dev.azure.com/sile-typesetter/069c3e31-ee59-4bd6-b395-1f1059acd8db/_apis/build/builds/1251/artifacts?artifactName=sile&api-version=7.0&%24format=zip

my system has MSYS2 installed. It's a win 10 20H2 machine.


[goyalyashpal]

Tbh, the situation with windows seems to be really bad lol.

* The download button on site redirects to github releases site which doesnt mention anything about windows. * I downloaded .zip from there, which seems to have downloaded the whole repo. * Then I read the manual, it says the following quoted para, * Since the address is line broken in pdf, it was not parsed correctly, and resulted in a broken link * Then, even the whole link didnt result in anything meaningful > SILE may be built on Windows using CMake and Visual Studio. There is not an installer (yet), but Windows executables are generated using Azure for every commit. You may download these exe- cutables by selecting the latest build from https://simoncozens-github.visualstudio.com/sile/_build and downloading the “sile” artifact from the Artifacts drop down. * Then i went to the Readme --> "Windows Build Passing" shield/badge --> https://dev.azure.com/sile-typesetter/sile/_build/latest?definitionId=1&branchName=master --> https://dev.azure.com/sile-typesetter/sile/_build/results?buildId=1&view=results --> https://dev.azure.com/sile-typesetter/sile/_build?view=runs and here, the commit id of pipeline runs doesn't correspond to the commit id of this github repo

--> after downloading that, now this issue 😅

I get that currently, the resources are thin for devt for windows, but at least the communication should clearly say what's the situation. Currently it just feels like it's brushed under the rug. and users left on to themselves to figure it out and return empty handed.

[alerque]

@yashpalgoyal1304 Your comments are totally fair. While I would love to say the answer is "oh you just do it like this", the real answer is that with nobody supporting it at the moment Windows support has suffered in the extreme. To be fair I think the documentation accurately reflected the situation when we wrote it, but the bitrot in the Windows build support files is now reflected in the docs. I just rewrote both the readme and manual on that subject so hopefully it is clear now and won't give false hopes.

We're still VERY open to contributions to the CMake or other Windows build related files or even stories on how anybody makes it work that we can build more helpful documentation around.

[Omikhleia]

As an aside note, if we could get some Windows developers - building the applications with MingGW / Msys2 would be neat IMHO. Open source shouldn't necessarily rely on CMake / Visual Studio.

[alerque]

A big :+1: to that, although any way we get a nice installer coming out of CI with all batteries included will be better than what we have now.

Being able to cross compile wouldn't hurt my feelings either. We're not actually that far off on the C bits, the main holdup is bundling the Lua interpreter and libraries I think:

$ ./configure CC=x86_64-w64-mingw32-gcc --host x86_64-w64-mingw32 --disable-dependency-checks --disable-linklua
$ make

Libtexpdf is throwing a few compile errors that look like they might be relatively easy to deal with. Our "justenough..." foo seems to be okay already.

As the new maintainer for For luacheck I was able to cross-compile a Windows binary that bundles the interpreter, Lua dependencies, and Lua code all in one binary for this release. The script that handles that uses luastatic, which was surprisingly easy to get setup actually. That might be worth looking into for SILE as well although I think it would be even better to have an installer that left the scripting exposed so it was easier for Windows users to copy/paste bits they want to tinker with.

[alerque]

Just another quick note on build toolchains, there is one more thing to say about CMake that weighs heavily in favor of getting it working again for benefits even beyond Windows. It happens to play nice with luarocks in a way that autotools does not, so we can use the CMake build wrapped inside a Luarock so luarocks install sile would be a viable alternative on all platforms as a way to get SILE — either standalone or library.

It's going to get a bit more complicated when I start swapping out parts of SILE's Lua with Rust equivalents, but I think I can see a way forward through that too.

[goyalyashpal]

hey @alerque are you on telegram?

[alerque]

@yashpalgoyal1304 No why? For more synchronous talk about SILE I'm frequently in the Gitter channel (which is also reachable via Matrix clients such as element).