Skip to content

Experiences trying to build Nyxt on Windows #3596

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
moneylobster opened this issue Feb 3, 2025 · 2 comments
Open

Experiences trying to build Nyxt on Windows #3596

moneylobster opened this issue Feb 3, 2025 · 2 comments
Labels

Comments

@moneylobster
Copy link

With the Electron backend (somewhat) in place, I tried to build Nyxt on Windows. I wasn't able to get a successful build, but I thought documenting the parts that caused problems might be useful in case someone else tries to run it on Windows in the future. I'm on Windows 10 with msys2 installed. I also installed node via msys2.

  1. Installing the electron backend: I wasn't able to get synchronous-socket to compile. One issue I faced here was that node-gyp has some problems generating makefiles on windows (on msys?), forgetting to escape the semicolon in paths starting with C: (should be C\:) (relevant issue here). This can be fixed by manually editing the makefile once it's been generated, adding this semicolon escape to a single line. The other issue is that synchronous-socket is written for unix sockets and depends on the sys/socket and sys/un headers, which aren't available on msys2. As I understand it the unix socket calls need to be replaced with appropriate calls from winsock2, but I decided not to go there. I also realized that there is a single reference to synchronous-socket in cl-electron, so I deleted that for now (and removed it from package deps) and hoped for the best. I was able to build cl-electron this way, though I may have broken the socket comms.
  2. Makefile: This method of building directories causes errors on windows since it ends up adding two slashes there, eg. /c/makefile_dir//nyxt.asd which asdf cannot locate. Loading the asds manually via REPL works.
  3. NASDF: The component-pathname method causes some errors while calling set-new-translation, which I wasn't able to circumvent via the NASDF_USE_LOGICAL_PATHS envvar, since the check for the var is done after the function call. Instead I replaced the whole function with (call-next-method) on win32, which (seemingly) works.
  4. iolib: This is a dependency of Nyxt which doesn't support windows. I wasn't able to find an easy way to bypass this yet, so that's where I'm stopping now.

I understand that Windows support is not a priority for the dev team, though hopefully this will be informative to anyone who's interested in running this natively on Windows. Also please let me know if creating an issue like this is not an appropriate way to share these notes.

@aadcg aadcg added the Electron label Feb 3, 2025
@aadcg
Copy link
Member

aadcg commented Feb 3, 2025

@moneylobster amazing report, thanks for sharing! I have a Windows machine but, given the amount of fires to put out, you need to focus on what matters the most.

  1. You are correct about winsock2. I understand that you bypassed the dependency to see how far you'd go, but it is a critical one. Without it, we can't handle input events. Here's a reference for Unix domain sockets on Windows.
  2. I'm not sure I understand the issue here. Are you running GNU make on Windows? Or does that mean that there's an inconsistency between GNU make on Linux and Windows?
  3. Do you want to send a patch? You could fix it via reader macros.
  4. Depending on iolib was a bad decision for many reasons. See Replace iolib by SBCL's primitives  #3461.

While I can't work on this front right now, I'm happy to help you or others towards this goal.

@moneylobster
Copy link
Author

moneylobster commented Apr 2, 2025

1: I haven't spent too much time on this, but I've noticed that sb-bsd-sockets doesn't support Unix domain sockets on Windows either, so I believe the proper way to tackle this would include adding this feature to this sb-contrib system, with some checks to ensure that the Windows version is new enough that this feature is supported.

2: Upon reflection this is probably because of msys2 and not really a Windows issue.

3: I'm not sure if my change breaks any functionality. Would NASDF's tests in tests.lisp be enough to ensure everything is working as intended? If not, fixing the other issues and verifying that Nyxt works/boots up under Windows with the NASDF change could be a way forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants