Skip to content
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

Update brlapi to 0.7 #14

Merged
merged 2 commits into from
Jun 25, 2019
Merged

Update brlapi to 0.7 #14

merged 2 commits into from
Jun 25, 2019

Conversation

LeonarddeR
Copy link
Collaborator

After hours of pine, I've finally been able to build the brltty bindings for Python 3.7. Here is a summary of the build steps:

  • Install mingw32 and MSYS1
  • Installed most of the dependencies noted in https://brltty.app/doc/Windows.html
  • Patched python 3 distutils to compile with my local vc++ build, linked against vcruntime140.dll
  • Only take the pyd file from the custom build. The two dll's are from the official build of the BRLTTY team, version 6.0

@josephsl
Copy link

Hi,

No errors this time. Note that just copying the CP37 extension (pyd) may suffice, as doing that produces no errors. But for sake of completeness, I think it'd be best to upgrade to brlapi 0.7.

Thanks.

@LeonarddeR
Copy link
Collaborator Author

LeonarddeR commented Jun 13, 2019 via email

@feerrenrut
Copy link
Contributor

it might be handy to have debug symbols as well. Is it possible to generate those too?

@LeonarddeR
Copy link
Collaborator Author

LeonarddeR commented Jun 13, 2019 via email

@feerrenrut
Copy link
Contributor

Producing debug versions of the dll should just require using the -g option with gcc

An intro here: https://stackoverflow.com/questions/4671900/how-do-i-use-the-mingw-gdb-debugger-to-debug-a-c-program-in-windows

I would take a look at the make file and see if it has a debug target. If you do manage to produce debug versions of the dll and debug information, I suggest we put them in a debug folder. We want to use the release version (no debug information) normally, but being able to swap it out with a debug version with debug database can help solve some tricky issues.

There is also the possibility to convert debug information to pdb.
see: https://stackoverflow.com/questions/19269350/how-to-generate-pdb-files-while-building-library-using-mingw

@LeonarddeR
Copy link
Collaborator Author

LeonarddeR commented Jun 13, 2019 via email

@feerrenrut
Copy link
Contributor

Though, since we did not have them before, we may not need them now. But since you have gone to the effort of building this, we might as well spend a little time to investigate getting debug info.

Copy link
Member

@michaelDCurran michaelDCurran left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My opinion is that we shouldn't hold this back for debugging -- we never had it anyway. Note that without this, the braille gestures unit test is freezing on appveyor.

@michaelDCurran
Copy link
Member

@LeonarddeR I assume you've been able to successfully use this in NVDA with brlTty?

@LeonarddeR
Copy link
Collaborator Author

@michaelDCurran: honestly, not yet. I only tested whether a Python 3 instance of NVDA was able to load the extension module and whether I could call functions on the module. It is likely that the brltty driver needs updates to support the update from 0.5x to 0.7x.
I can do some more tests tomorrow, though.

@LeonarddeR
Copy link
Collaborator Author

I've now come as far as connecting to the brlapi service from the new binding. Unfortunately, I can't get BRLTTY to work with my Handy Tech Active Braille, but that's definitely an issue I'm having with BRLTTY, not with NVDA.

I think it is save to merge this. Then, I will file a follow up pr to update misc-deps and the BRLTTY driver itself

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

Successfully merging this pull request may close these issues.

4 participants