#6 Fix building on mingw-w64 i686; enable mingw-w64 x86_64; cut down on duplicate includes; etc
Mingw-w64 has slightly different paths for its scsi headers from original mingw32. Also appears to have less sophisticated (and far less documented) header files which don't attempt to account for importing <windows.h> ahead of <winsock2.h> as completely (it still compiles and appears to work but with warnings). To reflect this, and take care of the warnings, I have changed a few preprocessor macros. In some places, if I could figure out which functions of <windows.h> were actually being used, I narrowed down the include to whatever file had the functions actually needed instead of importing the entire thing (there is now just one explicit include for windows.h, and even there we may be able to cut down). Have also enabled some built-in 'excludes' (defining WIN32_LEAN_AND_MEAN among other things) for the sole time <windows.h> is actually called, and tried generally to avoid duplicate inclusion of header files (if they've been removed, I've left comments in showing the include hierarchy).
Mingw-w64 has some different-sized types from regular win64 (...incredibly) or other x86_64 platforms, so in a few places I put in some explicit casts and changed the type. This does not have a negative effect on win32 and I believe only applies to code that would only be executed on win32 or win64 anyway, so I don't anticipate problems on other platforms. But, try it. </windows.h></windows.h></winsock2.h></windows.h>
I've also made some changes to configure:
Original mingw32 project doesn't have enough headers/library files right now for Qt5 to work, which prevents it from being very useful, but in case it ever does (it's not actually a dead project, many header files I've looked through have been updated in the past couple of months), some of the preprocessor macros in gui/src reflect this. configure now has explicit checks for precise mingw environment iff user wants a gui build (currently the default). Since compilation of libraries, plugins, and console apps still works, configure still allows mingw32--though you'll have to have manually built libpng and zlib in order to have png support in f1tattoo, since headers and libraries for even those are not provided for these in the mingw repositories. (By the weay, there is still a message about this not working after compilation, cannot test this but find it odd).
On that note, I have also added an explicit check for zlib iff a png build is desired (currently the defult) since this is a dependency of libpng and is not actually installed by default in mingw-w64.
In case the user is on Windows and accidentally began an msys2 environment instead of a mingw-w64 environment, I have added a check for this, too (I made this mistake early on in this 'adventure'). I severely doubt there is any desire for an msys2 build, except perhaps for qscand.
Also fixed a bug introduced in 0.8 where if user specified plugindir, the switch would define the wrong path for a win32 build--this is now accounted for.
* confclean now deletes more from gui, specifically the release folder, moc, and some other things generated by qmake.
Other changes I made generally:
* The last 0.8 release didn't actually put version bumps anywhere. I have added them, so that version now reads 0.8.0 for the gui and for the console apps that were previously on 0.7.1 or 0.7.2. It might make less sense to bump the console apps though--use your discretion, I guess.
I can provide links to both 32 and 64 bit builds, screenshots, etc if this would help patch acceptance. Everything appears to work right now--if there are bugs, like for example the eject button not working, I'm pretty sure they predate these changes (e.g. they do not work in artkar's build from last year, either).
Other things I'd like to work on:
a complete static build solution, for real portability (I have compiled partially static builds of qpxscan using static Qt5, that includes all of the Qt-related dependencies into qpxscan.exe, but this isn't really enough, imo);
for dynamic builds, add explicit functionality to configure in order to actually fetch all the dynamically-linked libraries needed to run the program into the target folder--on Windows should not be difficult thanks to windeployqt, and is easy for the command-line apps, but I'm not sure about other platforms, so decided not to tackle that ahead of this patch/this might not be as important for other platforms;
look at integration of some of Artkar's mods related to BD TL and QL scanning
I don't think the db works, at least not on Windows, so try to get this to work
explicit inclusion of iHBS112 clones whose firmware are capable of disc scanning in the definition file (so probably just the Plextor ones);
daemonization of qscand on Windows (I guess we can just tell people to use nssm but this is inelegant);
enabling jitter scanning on iHBS112 and clones (this requires Actual Knowledge though);
linking to msvcrt12.dll or later instead of msvcrt.dll in mingw-w64 (there are performance, internationalization, and long-term consistency reasons for doing this, from what I've read);
* possibly looking into macOS since I'd be shocked if that still works with no changes to the code, but honestly I don't use it enough to put in the work probably, even in The Rona Times
Final notes:
I have separated the patches into files per folder or file patched, for readability, which is why there are six of them.
I have absolutely not tested any of these changes with an MS Visual Studio-based toolchain, which e.g. artkar appears to have used (unclear). If this is important, I can try it.
* I am presuming that project license has not changed. If there are plans to change it, would be nice to know. Otherwise ofc these changes are contributed under current license (gplv2), I am not here to force any changes. (On that note for the sake of accuracy, you may actually want to change the copyright notice itself to: Gennady Kozlov + contributors. )
I'm not sure how the formatting got screwed up and there doesn't appear to be an edit function, sorry about that
One more note--I have added many explicit
if defined (_WIN64)statements, but so far as I know, any time_WIN32is defined , so is_WIN64. I did this because making this explicit seems like a good idea in terms of how we think about our target platforms. It also seems like a good idea in case there is ever a_WIN64platform that does not define_WIN32, or in case this behavior is changed more generally than that. But it is not strictly necessary for this project, and at no point is there code that only works on WIN32, to the exclusion of WIN64. But since these checks are more or less free, it seemed like the prudent route....I seem to have found a bug. At first I thought it was something about my code but it might have something complicated to do with threading models and such, will keep posted
Issue is: when queuing up more than one test to be run via a qscand instance, qpxscan crashes at the start of the second test. You can run as many singleton tests as you want, but not any single run of tests with more than one test in it. I had theorized about changes I've made that could be too blame but undoing them doesn't seem to have helpd, and this doesn't seem to happen in the static builds I've made, so I'm a little lost. This only happens via qscand, regular tests test runs done on local drives are fine. This happens on both i686 and x86_64 builds. Very sorry, I'm not sure how I missed this earlier, feel very silly :/
Last edit: Eli Bildirici 2020-05-04
OK, I have spent the last week or so monomaniacally debugging. I have found that the older builds that I had made (with fewer changes to the headers) as well as Artkar's, actually didn't necessarily fare better. All of them randomly seem to crash sometimes when a second test is started, or sometimes when media is being checked (several times in a row), and this again is not deterministic enough that it seems related to anything I've changed. Sometimes, when debugging, I'm lucky enough to get a sigsegv message and a stacktrace but it's not consistent (race condition?). I'm a little stumped, and am curious if this happens on other platform using the current codebase. I have also found a couple of other issues in the process that looked related to these problems, but actually weren't, and will be filing a separate ticket about those. (For example, sometimes the second test done over a network wouldn't cause QPxTool to crash, but it would simply never process. This turns out to be because the socket is never actually written to--the commands are never sent in the first place, they just sit in the buffer indefinitely.) In any case, will try to provide sample builds here for your consideration.
Last edit: Eli Bildirici 2020-05-25