-
Notifications
You must be signed in to change notification settings - Fork 145
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
Parport build test #1874
Parport build test #1874
Conversation
Thanks for the PR!
How has this been built until now? Statically without DLL? I have thought for some time that |
I have not looked into what exactly the CI builds (Windows+MSYS2/mingw or Windows/msvc) do, but statical linking should work. For dynamic linking and message output functions, a usual pattern is that a library defines a C function type and offers an initialization function to its library users which takes a function of such type and some data to be handed to such a function. So a library user like avrdude or avrgui registers its respective message handler with libavrdude when it initializes the library. Then avrdude's message handler be something like its current A reasonable default implementation for such a message handler could be printing to stdout.
The respective message handler data and message handler func could be part of an opaque library context type struct. Details to be determined. |
Please forget about Parport in Windows, it is not supported and will not work as there is no driver support. |
Or |
|
This has been documented under the Wiki here.
|
I like this idea. |
So it would make sense to remove |
I like this idea. |
I have mentioned this as part of Docuementation improvement. |
avrdude does not support parallel port usage on Windows XP or later, so we can remove winppi.c. avrdudes#1874 (comment)
@dl8dtl I look at the code and I do not think it will work under Windows Vista and later. And we do not support Windows XP/Vista anyway. Even Windows 7 support is not tested now that it is no longer supported by Microsoft. |
Build parallel port code on supported systems Unsupported systems are: * MSVC compiler (does not support GNU style inline asm) * macos operating system (no macos implementations for preprocessor macros DO_PPI_READ, DO_PPI_WRITE, ppi_claim, ppi_release) This means the CI can test * native Linux builds (yes, even for arm systems) * native Windows builds using mingw Untested at this time are the BSDs. Removes the dysfunctional Windows (since Windows XP) parallel port code, and has the buildsystems fail Windows builds if parallel port builds are requested (HAVE_PARPORT or --enable-parport). avrdudes#1874 (comment)
3e38c9b
to
ba561ea
Compare
I think I could live with that.
I don't think there was any actual parallel-port support for Windows available anyway since the days are gone when you could gain access to all IO ports through |
Great. Thanks for your confirmation. This is what I believe as well. |
Actually this PR is kind of good already. Just wondering any further changes you want to have. Thanks. |
The commit comment is incorrect at least regarding Windows. Doc changes have been done in other PRs, expecting conflicts. But you are right, this PR could be made merge able with probably low effort. Will try later today. |
Adopted the document change of PR #1874.
Please help to rebase this PR and fix the commit messages, then I think it will be good to go. |
mingw builds for Windows require a function prototype fix.
Build parallel port code on supported systems Unsupported systems are: * Windows operating system * MacOS operating system This means the CI can test * native Linux builds (yes, even for arm systems) Untested at this time are the BSDs. Removes the dysfunctional Windows (since Windows XP) parallel port code, and has the buildsystems fail Windows builds if parallel port builds are requested (HAVE_PARPORT or --enable-parport). avrdudes#1874 (comment)
ba561ea
to
16d7d0b
Compare
Good to go, as far as I can tell. |
Great, will merge soon |
This came up during build tests: The parallel port code was not built during CI, and it failed compiling for Windows using the mingw64 or ucrt64 cross compile toolchains on Fedora Linux.
So this PR
fixes the function prototypes for port_get() in ppiwin.c to allow compilation
has all platforms on GitHub's CI infrastructure on which avrdude supports the parallel port test build with the parallel port code
It does not fix the fact that libavrdude uses a
avrdude_message2()
function which is defined inavrdude
, which causes problems building for Windows. A library using a symbol from an executable while the same executable uses a symbol from the library appears to be difficult to impossible with Windows DLLs.