@Anthony Tuininga The reason for this is that includeFiles is used to copy some libraries, namely Qt plugins. It should be safe to look for dependencies of files that are not libraries (I remember this getting fixed recently on Windows)
According to this documentation, the first place searched for DLLs is "The directory where the executable module for the current process is located.", which should be where it's put. Am I misunderstanding? Do Qt plugins use some special means to find DLLs?
Right. My assumption: Qt loads "platforms/qwindows.dll" at run time (I'm not an expert, they're referred to as platform plugins so I'm assuming runtime). qwindows.dll depends on libEGL.dll but that one needs to be in the library path. This pull request puts qwindows.dll dependencies in the platforms/ directory instead of the binary directory..
Here's what I know: if libEGL.dll ends up in platforms/ after setup.py build, it doesn't work. If it ends up in the build directory with the executable it does work, with qwindows.dll under platforms/
Not sure where to go with that. Should the destination path for dependent libraries be modified to always be the same path as the executable?