Add a Github action to build for Windows X64 by LeonarddeR · Pull Request #490 · brltty/brltty

LeonarddeR · 2025-08-09T19:50:53Z

A modern Windows x64 build using msys2, including Python bindings. Uses the native Python rather than the MinGW Python.
Many thanks to @bramd for laying the ground work of this.

… bdist_egg instaat of bdist_wininst to generate an egg instead of an exe for Python bindings (wininst has been removed since Python 3.8)

LeonarddeR · 2025-08-09T19:56:48Z

Here is a workflow run including artifacts.

bramd

I'm not really sure what to think of this. It is a minimal BRLTTY build for Windows, but it differs from the builds that can be downloaded from the website for the latest releases. If the goal is to be able to release from this in the future, this would need more work so it includes all the files that are in the Windows build now and follows it's directory structure. Also, the current builds don't include a winusb variant, where this CI build does not include the libusb/libusb-1.0 variants.

I did not try the resulting brltty.exe from this build since I have no hardware to test at the moment, but the build process looks fine to me. So if this is just meant as a check in the CI process to see if BRLTTY builds on Windows, this is fine.

bramd · 2025-08-09T20:24:41Z

.github/workflows/build_brltty_windows.yml

+
+jobs:
+  build_brltty:
+    runs-on: windows-2025


You could also use windows-latest here. The risk is that it breaks when the latest reference is updated to a newer version.

windows-latest is in the middle of its shift from 2022 to 2025. I'd rather stay safe here.

bramd · 2025-08-09T20:30:31Z

.github/workflows/build_brltty_windows.yml

+        run: |
+          export PATH="$(cygpath -u "$pythonLocation")/scripts:$(cygpath -u "$pythonLocation"):$PATH"
+          ./autogen
+          ./cfg-windows --prefix=/ --enable-relocatable-install --with-usb-package=winusb


Depending on what the goal of the builds is, you might want to set up a matrix wit certain variants. The official builds offer libusb/winusb variants and are 32 bits for now, so we might want to offer a 32 bits build as well if there is still any interest in that. Also, the Python bindings are now just for Python x64, you could also add multiple Python versions there.

bramd · 2025-08-09T20:49:43Z

Bindings/Python/Makefile.in

 	set -- $(V_setup) build --build-temp .; \
 	[ "@host_os@" != "mingw32" ] || set -- "$${@}" --compiler mingw32; \
 	"$(PYTHON)" ./setup.py "$${@}"
+	[ "@host_os@" != "mingw32" ] || "$(PYTHON)" ./setup.py $(V_setup) bdist_egg --skip-build


I don't know what is going on here exactly. I guess we don't match the mingw32 in your msys-2 build? Also, the current BRLTTY release for Windows contains a Python wheel, so it would be nice if we create a wheel as well instead of an egg.

LeonarddeR · 2025-08-11T16:03:56Z

There are several reasons why I wrote this, but creating a distribution isn't one of them currently:

Have X64 brlapi and python bindings for NVDA, see Update brlapi bindings to support Python 3.13 and X64 nvaccess/nvda#18657
Proof of concept that x64 builds actually work
Laying the groundwork to update the Windows builds to something more modern. I'm however unable to take that project further.

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

@bramd

See brltty#490 A modern Windows x64 build using msys2, including Python bindings. Uses the native Python rather than the MinGW Python. Many thanks to @bramd for laying the ground work of this.

Should fix nvaccess/nvda#18657 when part of NVDA X64 builds. Updated to a brlapi build produced on Github Actions in my own fork. See also brltty/brltty#490 Tested successfully: Install Windows Narrator braille support Manually enable the brlapi service Connectd braille display,: APH Mantis Ensure braille output and key presses work

stweil · 2025-10-13T07:52:31Z

Programs/tune_builder.c

  wchar_t *operand;
-
-#if !defined(__MINGW32__) && !defined(__MSDOS__)
+#if !( (defined(__MINGW32__) && defined(__i386__)) || defined(__MSDOS__) )


What about Windows on ARM? Should it be handled like Windows for x86?

I don't think there's a toolset that supports building on ARM yet.

Sure, there are such toolsets (from Microsoft and free ones). Personally I use Clang in cross builds on Linux hosts.

Yes there is a clang toolset, but I haven't been able to build brltty with clang yet. I think for this to work, having a linux brltty build that works with Clang is a first necessary step. Unless that's already possible.

DaveMielke · 2025-10-13T19:31:52Z

Am I correct in understanding that your intent with this PR is to generate a 64-bit brltty for Windows? If so, will your approach be to still use msys and to build with brltty's mkwin script? Note that this PR touches a number of files that have nothing at all to do with Windows. That's one reason that I've been ignoring it.

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

LeonarddeR · 2025-10-14T05:23:45Z

Am I correct in understanding that your intent with this PR is to generate a 64-bit brltty for Windows?

This is correct.

If so, will your approach be to still use msys and to build with brltty's mkwin script?

Yes and no. The build uses msys2, not msys1. They are pretty different. Therefore that's also the reason why mkwin is not used, because it assumes msys1.
Note however that it is pretty hard to setup msys1 and that it is really old.
You may wonder if there is even still a need for an x86 build of brltty.

Note that this PR touches a number of files that have nothing at all to do with Windows. That's one reason that I've been ignoring it.

What files do you mean exactly?
It looks like some log files were removed that were once committed by accident.
The change to Python/Makefile.in will only run on Windows
The changes to Programs/tune_builder.c should ensure that support for msys1 is preserved whereas building also works on msys2.

stweil · 2025-10-14T06:03:52Z

It looks like some log files were removed that were once committed by accident.

Ideally this kind of clean up should be done in a separate pull request, not here. It is unrelated to the description of this pull request.

DaveMielke · 2025-10-14T11:22:59Z

[quoted lines by Leonard de Ruijter on 2025/10/13 at 22:24 -0700]

> Am I correct in understanding that your intent with this PR is to generate a 64-bit brltty for Windows? This is correct.

I'mindeed interested in this. None of us are Windows people so it's easy for us to put this work off in favour of other work that needs to be done.

The build uses msys2, not msys1. They are pretty different. Therefore that's also the reason why mkwin is not used, because it assumes msys1.

I'd still like it to work that way. Probably the best would be to rename mkwin to mkwin32 and to create mkwin64 that works similarly.

Note however that it is pretty hard to setup msys1 and that it is really old.

Sure, but that's only for builders. I have the winsetup script. Again, it could be renamed to winsetup32 and create a similarly working winsetup64.

You may wonder if there is even still a need for an x86 build of brltty.

Maybe not but I'll still be keeping the ability to buidl it. I'm comfortable with the current msys1 way for 32-bit and with using msys2 for 64-bit. Of course, being also able to support msys2 32-bit would be cool.

> Note that this PR touches a number of files that have nothing at all to do with Windows. That's one reason that I've been ignoring it. What files do you mean exactly?

I forget, off the top of my head, and am not going to go look. It's the responsibility of the one who wants a PR to be picked up to be sure that it's clean. It's also my position that I expect a PR to be designer-tested (unless I'm explicitly told to wait) because I want our development stream to be as problem free as possible. When I get a PR that touches files that it shouldn't then, rightly or wrongly, it looks careless and untested to me so I simply don't trust it. Then I see posts like "since Dave isn't responding". Go figure!

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

…build

LeonarddeR · 2025-10-16T18:45:50Z

All unrelated changes are no removed from the pr.

To be honest, I currently do not have the time available to split out mkwin into mkwin32/64. The current GitHub action is at least a working method to create an X64 build. The split can happen in a follow up where the GitHub Action can be used to validate that it still works as expected.
If you insist on splitting beforehand, I'm afraid this must wait until around christmas.

DaveMielke · 2025-10-16T21:31:59Z

[quoted lines by Leonard de Ruijter on 2025/10/16 at 11:46 -0700]

All unrelated changes are no removed from the pr.

Maybe not. Why does Build/.gitignore contain /Logs?

To be honest, I currently do not have the time available to split out mkwin into mkwin32/64. The current GitHub action is at least a working method to create an X64 build. The split can happen in a follow up where the GitHub Action can be used to validate that it still works as expected. If you insist on splitting beforehand, I'm afraid this must wait until around christmas.

I'm not insisting. It's just that it needs to be done if we're to start providing a 64-bit build. In bindings.m4, python was moved before python3. My concern is that this increases the risk of python-2 being used on some platofrm. Maybe we're far enough along now that this is no longer an issue. You added -lsystre in configure. I haven't tested yet but am hoping that this will work for our 32-bit build. Did you test that? In the Python make file you added. [ ***@***.***_os@" != "mingw32" ] || "$(PYTHON)" ./setup.py $(V_setup) bdist_egg --skip-build So the command will be done on MinGW32. I thought you were working on a 64-bit build. Similarly (I think), in tune_builder.c we have: -#if !defined(__MINGW32__) && !defined(__MSDOS__) +#if !( (defined(__MINGW32__) && defined(__i386__)) || defined(__MSDOS__) ) Why does the __MINGW32__ test need the extra __i386__ test?

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

DaveMielke · 2025-10-17T20:59:02Z

Merged (rebase, squash) by commit a8a0375.

DaveMielke · 2025-10-17T21:09:06Z

It's now merged but I'd still appreciate very much - for my own understanding - the answers to the questinos in my previous comment. Note that there's a follow-up commit to make the #ifdef tests in tune_builder look a bit cleaner and easier to understand.

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

DaveMielke · 2025-10-17T22:19:21Z

Okay, my 32-bit msys1 build can't find -lsystre: bin/ld.exe: cannot find -lsystre I need a solution. This is exactly what I mean by I expect changes to be tested.

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

LeonarddeR · 2025-10-18T06:57:43Z

Honestly, I find this somewhat frustrating. @bramd and I have literally spent days getting an x64 build to work on Windows. In 2025, it’s almost impossible to produce a 32-bit build on a machine unless you stash libraries like libusb in obscure locations in your file system, including Program Files.

The whole idea behind this pull request is to set up CI/CD for Windows x64 so that these kinds of tests are automated. If I want to add a new feature on Windows, as a developer in 2025 it really shouldn’t be up to me to manually run all sorts of workflows (such as testing on other operating systems I can hardly or not test on) that should already be part of the CI?CD pipelines.

Furthermore, if a pull request requires more testing, that’s perfectly fine — we have an option in GitHub to mark it as a Draft PR. Instead, you chose to close it.

I'll draw my conclusions from that. For me, this is now a closed chapter. I’m stepping away from BRLTTY and won’t be investing any more time in this product until proper CI/CD is in place.

stweil · 2025-10-18T08:17:11Z

@LeonarddeR, why did you ignore my comments regarding Windows on ARM?

DaveMielke · 2025-10-18T08:41:44Z

[quoted lines by Leonard de Ruijter on 2025/10/17 at 23:58 -0700]

If I want to add a new feature on Windows, as a developer in 2025 it really shouldn’t be up to me to manually run all sorts of workflows (such as testing on other operating systems I can hardly or not test on)

That's a total over-statement. I asked you to ensure that your PR only impacted the Windows portions of the build. Obviously, asking for changes to be designer-tested would necessarily include not breaking the current 32-bit build on which we rely. You sound like you're being very angry with me - I think you're being unreasonble. Other people's projects aren't toys and shoudl be treated with respect. I'm sure you wouldn't appreciate it if I were to treat your project in the same careless way.

that should already be part of the CI?CD pipelines.

What you think regarding someone else's project simply doesn't matter. Different people do things in different ways and it isn't for you to define what's right and what's wrong for others.

Furthermore, if a pull request requires more testing, that’s perfectly fine — we have an option in GitHub to mark it as a Draft PR. Instead, you chose to close it.

When I ignroed it - which is what one would do with a draft request - I was accused of "not responding". That's not fair!

I'll draw my conclusions from that. For me, this is now a closed chapter. I’m stepping away from BRLTTY and won’t be investing any more time in this product until proper CI/CD is in place.

Fair enough. I hope being so angry makes you feel good.

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

DaveMielke · 2025-10-18T20:14:15Z

I know that my last comment on this PR may have been seen as rude by some, but that really isn't the case. I was just being honest and clear about my lack of appreciaton for changes that haven't been designer-tested. That's just the way I am, and the way that anyone who knows me expects me to be. Anyway, I'm not trying to be uncooperative. I don't mind at all resolving this problem but I need some knowledge from you (or someone else of you). What is libsystre? Which code is referencing it? Where does it come from? Is it a Windows or an msys package? What's the name of the package that it's in? If I can add it to my msys1 build environment then I will. If I can't then I'll rework configure. If I need to rework configure then I need you to tell me what your host_os is.

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

bramd · 2025-10-20T18:57:52Z

What is libsystre? Which code is referencing it? Where does it come from? Is it a Windows or an msys package? What's the name of the package that it's in? If I can add it to my msys1 build environment then I will. If I can't then I'll rework configure. If I need to rework configure then I need you to tell me what your host_os is.

I haven't worked on this recently, only pointed @LeonarddeR to my old work to base his changes on, so I'm not actively working on anything related to this, but this question I can answer. It's a Msys-2 package that's also called libsystre. This provides POSIX compatible regular expressions (regex.h), which was part of the standard library in Msys-1 if I remember correctly, but not on Msys-2. Hope this helps anyone working on this.

DaveMielke · 2025-10-21T12:08:26Z

[quoted lines by Bram Duvigneau on 2025/10/20 at 11:58 -0700]

It's a Msys-2 package that's also called libsystre. This provides POSIX compatible regular expressions (regex.h), which was part of the standard library in Msys-1 if I remember correctly, but not on Msys-2.

Thank you. Could you guys please try with the latest brltty devepopment code to ensure that I haven't broken libsystre support? By the way: MSys-1 also needs an extra package - msys-libregex.

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

DaveMielke · 2025-10-23T22:48:59Z

Doing a make brltty.exe now works on 64-bit MSys2. The winsetup64 script is there. Please have a look at its package list to see if I've missed any packages that you'd like it to install as well as in case I picked any wrong ones. The mkwin64 script doesn't yet exist but I don't think you're relying on that anyway. Please let me know what else needs to be done. I know you requested for this work to be done a long time ago. I'm sorry that I didn't do it much sooner. My excuse is that working on Windwos is a bit "painful" for me as I'm not very familiar with it.

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

LeonarddeR · 2025-10-24T13:59:38Z

@stweil commented:

@LeonarddeR, why did you ignore my comments regarding Windows on ARM?

I have not ignored that comment, but it looks like it was never posted and is still listed as pending. I'm sorry for that.

LeonarddeR · 2025-08-09T20:11:42Z

configure.ac

      ;;
   mingw*)
      system_package="windows"
+      system_libs="-lsystre"


@bramd Any idea why this is necessary? Never heard about this

LeonarddeR · 2025-08-11T16:00:39Z

.github/workflows/build_brltty_windows.yml

+
+jobs:
+  build_brltty:
+    runs-on: windows-2025


windows-latest is in the middle of its shift from 2022 to 2025. I'd rather stay safe here.

LeonarddeR · 2025-10-13T09:40:46Z

Programs/tune_builder.c

  wchar_t *operand;
-
-#if !defined(__MINGW32__) && !defined(__MSDOS__)
+#if !( (defined(__MINGW32__) && defined(__i386__)) || defined(__MSDOS__) )


I don't think there's a toolset that supports building on ARM yet.

LeonarddeR · 2025-10-24T14:09:28Z

@DaveMielke Thank you very much for accepting my code in a8a0375. I readily admit that I overreacted, and I apologize for that. Unfortunately, my time is limited due to other commitments. In future contributions, I will try to take the necessary precautions regarding proper testing.
That said, I never intended to accuse you of not responding. If I did make any remark to that effect, it was meant as a factual observation.

DaveMielke · 2025-10-24T16:05:26Z

[quoted lines by Leonard de Ruijter on 2025/10/24 at 07:09 -0700]

I never intended to accuse you of not responding. If I did make any remark to that effect, it was meant as a factual observation.

Not a problem, really. I also didn't know you guys from anyone. Now I'm guessing that you might be the NVDA people. Anyway, you efectively pushed me into finally doing the 64-bit MSYS2 work. I'd appreciate it very much if you could tell me what still needs to be done. On a related issue: As I'm sure you've seen, we're getting the Pythn warning that "setup.py install has been deprecated". Are you able to give me some clues as to how to upgrade that code?

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

DaveMielke · 2025-10-24T22:41:10Z

[quoted lines by Leonard de Ruijter on 2025/10/24 at 12:01 -0700]

Yes there is a clang toolset, but I haven't been able to build brltty with clang yet. I think for this to work, having a linux brltty build that works with Clang is a first necessary step. Unless that's already possible.

I'll have a look at building with clang on msys2. I'm hoping that that'll be fairly easy given the latest changes. I'll let you know.

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

DaveMielke · 2025-10-25T19:49:14Z

MSYS2 clang update: One problem fixed and one to go. The fixed problem is that clang "leis" by claiming to have a builtin implementation of ffs() but it actually doesn't. The current fix is if on MSYS2 and using clang then provide our own inline implementation of ffs(). The one probmem left is that, when using clang on MSYS2, it gives a "section below image base" warning while linking. Again, it appears that clang on MSYS2 is somewhat broken. I know what's triggering the problem and will be making changes to the make files to resolve it.

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

DaveMielke · 2025-10-26T06:56:42Z

Okay, brltty is now building (make brltty.exe) successfully using clang on MSYS2. So are all its associated commands except: spktest (because speech is currently disabled) brltty-pty (because it imlements a pty-based pseudoterminal)

…

-- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: ***@***.*** | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)

bramd · 2025-10-29T23:18:14Z

On a related issue: As I'm sure you've seen, we're getting the Pythn warning that "setup.py install has been deprecated". Are you able to give me some clues as to how to upgrade that code?

Based on my notes from (I think) 2 years ago when I worked on this, so things might be out of date. The modern Python packaging ecosystem wants to get rid of calling setup.py with unknown side effects and standardize on binary precompiled formats like wheels. Also, setup.py is more and more replaced with static configuration like pyproject.toml. Back when I looked into this, I couldn't find a way to call arbitrary commands without having the classic setup.py install, so there was no clear path forwards. For now it seems to be working still, but if/when I've some more time I would be glad to look at this again.

bramd and others added 9 commits August 9, 2025 21:47

Add Github Actions workflow to build BRLTTY on Windows

b1a4639

Add affinity patch and install commands

5301053

Add patch dependency

098cfed

Restore verbose output

649dcce

Add git dependency, remove --with-usb option from config

aaada7b

Add systre to system_libs for mingw31 to provide regex functions, use…

f24f2ae

… bdist_egg instaat of bdist_wininst to generate an egg instead of an exe for Python bindings (wininst has been removed since Python 3.8)

Create install directories explicitly

f747248

Fix path to bat files

71fa252

Move to ucrt64 instead, use native Python

189b685

Fix tune builder

d9c1918

bramd approved these changes Aug 9, 2025

View reviewed changes

LeonarddeR mentioned this pull request Aug 11, 2025

Update brlapi bindings to support Python 3.13 and X64 nvaccess/nvda#18657

Closed

LeonarddeR marked this pull request as ready for review August 11, 2025 16:04

LeonarddeR mentioned this pull request Aug 15, 2025

Update brlapi X64 nvaccess/nvda-misc-deps#39

Merged

LeonarddeR mentioned this pull request Sep 24, 2025

Add a Github action to build for Windows X64 nvaccess/brltty#1

Merged

Apply suggestions from code review

e05ef59

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

stweil reviewed Oct 13, 2025

View reviewed changes

LeonarddeR added 2 commits October 16, 2025 20:39

Restore deleted files

6d7c6f8

Merge remote-tracking branch 'origin/master' into gh-actions-windows-…

31caa59

…build

undo gitignore

ca77f96

DaveMielke closed this Oct 17, 2025

LeonarddeR commented Oct 24, 2025

View reviewed changes

Conversation

LeonarddeR commented Aug 9, 2025

Uh oh!

LeonarddeR commented Aug 9, 2025

Uh oh!

bramd left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LeonarddeR commented Aug 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DaveMielke commented Oct 13, 2025 via email

Uh oh!

LeonarddeR commented Oct 14, 2025

Uh oh!

stweil commented Oct 14, 2025

Uh oh!

DaveMielke commented Oct 14, 2025 via email

Uh oh!

LeonarddeR commented Oct 16, 2025

Uh oh!

DaveMielke commented Oct 16, 2025 via email

Uh oh!

DaveMielke commented Oct 17, 2025

Uh oh!

DaveMielke commented Oct 17, 2025 via email

Uh oh!

DaveMielke commented Oct 17, 2025 via email

Uh oh!

LeonarddeR commented Oct 18, 2025

Uh oh!

stweil commented Oct 18, 2025

Uh oh!

DaveMielke commented Oct 18, 2025 via email

Uh oh!

DaveMielke commented Oct 18, 2025 via email

Uh oh!

bramd commented Oct 20, 2025

Uh oh!

DaveMielke commented Oct 21, 2025 via email

Uh oh!

DaveMielke commented Oct 23, 2025 via email

Uh oh!

LeonarddeR commented Oct 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LeonarddeR commented Oct 24, 2025

Uh oh!

DaveMielke commented Oct 24, 2025 via email

Uh oh!

DaveMielke commented Oct 24, 2025 via email

Uh oh!

DaveMielke commented Oct 25, 2025 via email

Uh oh!

DaveMielke commented Oct 26, 2025 via email

Uh oh!

bramd commented Oct 29, 2025

Uh oh!

Reviewers

Assignees