SWIG Python wrapper for libavrdude #1714
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Config file handling and basic list handling is there.
|
This does not work under MSYS2 mingw64. Personally I always find Python bindings using swig to be problematic to build under Windows. I have never tried to use swig with MSVC either. Failed build log under MSYS2 mingw64 |
|
Thanks for testing. Kinda interesting, as my compile command is supposed to be the same as for standard avrdude itself … |
I will test under Linux and macOS as well. BTW, I was kind of the de-facto libftdi Windows binary packager last time. I always find it a bit troublesome to build the Python binding under Windows. So I myself actually use pyftdi (libusb/pyusb based) and pylibftdi (libftdi based). |
The CI runs already fail at MacOS, with what seems not finding the Python libraries. I guess it's merely something needed inside the CMake stuff for that. Linux and FreeBSD builds work fine, both in CI as well as physically for me. The more interesting part in your failure is that it's IMHO completely unrelated to SWIG or Python, as it happens in Code that is being compiled just like in the ordinary libavrdude/avrdude counterpart. |
|
I tried to push a quick fix for the macOS CI failure but it does not work -- it still uses the system installed Python and not Homebrew Python. |
|
I also pushed a commit to add the build test for MSYS2 mingw build and now should be able to see the errors under MSYS2 mingw builds from github action. |
|
No issues under Ubuntu 20.04 Linux. |
And I have the same linking issue under my Mac Mini M1 (macOS 14.3.1). It uses System Python and not Homebrew Python. The root cause is missing the link to the python library. I can manually fix the issue but I do not know how to do that properly in CMake. |
Basically we need to add the found github action run: |
Thanks for the analysis, very welcome! I'm almost illiterate regarding CMake. |
I tried a dirty fix but it does not work. Sorry I do not know how to fix this issue, but at least we know the root cause now for macOS build. |
No issues, same here -- not knowing much about CMake or SWIG myself... |
|
I only know libftdi SWIG Python bindings working under macOS. Not so sure if it will help or not. However, I can see that Homebrew libftdi formula actually disables the building of SWIG based Python binding. |
|
What's a little strange here: I'd have expected that the "REQUIRED" there would actually require a Python library … but on my Mac, there isn't one, and so I get the same linker error. |
|
Indeed it is strange. You can always leave the build isse aside first and concentrate on the code development first. If the build error is too distracting, you can temporarily remove the build from github action as well (macOS, Windows MSVC and Windows MSYS2 mingw build). |
Yes, that's probably what it's going to be by now. There's not much point spending time there as long as it isn't clear whether the entire result will be useful at all. |
This helps the SWIG wrapper to define them as well.
Some library functions might return AVRMEM* and AVRPART* as NULL pointers. Prevent them from being dereferenced, and return a Python None object instead.
|
Looking at the MSVC build errors, it seems to me it is due to missing extra Windows extra include files for the SWIG Python Wrapper build. https://github.com/avrdudes/avrdude/tree/main/src/msvc After manually corrected the include directories (basically copy the MSVC include directories of Then after manually adding the Python library, the build is actually successful. |
|
Then it seems to work even though I have to patch |
Adding the build directory to the module search path eases development by now.
Make the combo box editable, and apply a QValidator subclass to it so the users can type partial device names.
The default of 10 entries is way too small.
While the combobox validator prevents "QValidator.Invalid" characters to be entered, the user could still get away with any string that is considered "QValidator.Intermediate". In that caes, disable the OK button of the button box so the (intermediate) result could not be passed on.
Turns out PySide2 doesn't have a setMarkdown() method for the text widgets, only setHtml().
50 seemed to be a bit too large for some displays.
While typing the combobox text, the validator adapts the contents of the dropdown menu to only those entries that match the text typed. So one can enter "64", and will only be presented all device that have a 64 in their name (which are a few more than just those with 64 KiB of flash).
This category triggers for all programmers that have PM_SPM set.
This offers the same feature as for the device selection: typing a partial programmer name filters the dropdown list to all possible matches for a programmer.
Was: Attribute Qt::AA_ShareOpenGLContexts must be set before QCoreApplication is created.
|
@dl8dtl @mcuee @MCUdude I have created 27 PRs, one for each programmer, to bring them up to speed for use in the GUI:
When you review new programmer code in future please remember to watch out for exit(), static or global variables etc. With serious libavrdude use these can no longer be here. Please, if you can, give those PRs a quick test. @mcuee already has tested quite a few (thanks!) but he doesn't have all gear. |
|
There are still quite a few other things to do once these PRs are merged: the new return code As to names (always the most tricky part of programming 😄): I'd like to use This must be allocated at the start of an application and only one global variable used: |
|
Would you please merge main branch to this PR? Thanks. |
Will do when being back from vacation. |
Merged
This initializes the global context pointer, similar to what avrdude's main.c is doing at startup.
This is done now. Have not been doing much testing, but at least, it starts again. |
This is meant to clean up everything that has been done before. For this to work, free up the old pointer first.
stefanrueger
changed the title
Beyond initializing the cx pointer, it turns out more cleanup might be required when re-initializing the context pointer. (Normal CLI only initializes it once, so that's not an issue there.) Thus, join all the required actions into an init_cx() function provided by the library.
This was referenced Aug 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The purpose of this branch / pull request is to eventually establish enough of a Python wrapper to allow a full feature-compatible Python version of AVRDUDE. This will allow it to be embedded in scripting frameworks, or to be used by something like a real GUI wrapper.