pdftopng
pdftopng copied to clipboard
vinayak-mehta
#3 wheel_repair.py widened support for other projects
this should preserve the .bat's file parameter passing prevents anyone doing import wheel_repair to get python code executed intermediate tiny change towards an independent wheel_repair PyPA module who knows
assumption is made that the .dll or .pyd and its dependent dll files must live in the <package_name> directory of the wheel, this should be injectable or adaptive
I might add a different Github Action workflow file to ensure that the changes I want to do wheel_repair.py do not break your own project as well
I now manage to build a repaired .dll-based instead of .pyd-based repaired windows wheel on my side using more changes to your script. I will propose those changes here soon.
Here is a successful wheel build with repaired and non-repaired wheel downloadable artifacts: https://github.com/myselfhimself/gmic-py/actions/runs/356497315 I need to fix my setup.py file, so that .dll files are listed I think.. unsure
A RECORD file updating pass will be needed after .dll/.pyd repairing is done in order to relist the wheel's file entries (file paths + hashes) and the whole wheel's signature or hash, as exists in the auditwheel tool, see https://github.com/pypa/auditwheel/blob/67ba9ff9c43fc6d871ee3e7e300125fe6bf282f3/auditwheel/wheeltools.py#L45
A specification of the RECORD file is introduced here: https://www.python.org/dev/peps/pep-0491/#the-dist-info-directory
I am giving up on msys2 and restarting work on your vcpkg-based MSVC github workflow pipeline to see if my project is compilable..
Sorry for missing all the comments. I just started work at a new company and have been spending all my time there. I'll get back to all the comments over the weekend.
I am giving up on msys2 and restarting work on your vcpkg-based MSVC github workflow pipeline to see if my project is compilable..
I was reluctant to ask if this is possible, but saw it as a potentially constructive path. Let me know if I can test or play with any of the attempts to help refine it. Good luck.
Hello @vinayak-mehta this branch is now somewhat a mess of mine, I have started to fix your wheel_repair.py script for .dll files, then to understand how a setup.py file should be configured to trigger a proper msvc build. I think that I will avoid the mangling step and move .dlls into the wheel followed by a wheel filename and WHEEL manifest tags-rewriting step if needed and RECORD rewriting step... Or, I could drop Windows support for now. I have also omitted that my library can be compiled fully statically on Windows, yielding a single standalone .dll file.
@paulhart2 You are very kind, I will sure let you know when something can be tested.
@vinayak-mehta @myselfhimself Good to hear another 'voice' in this discussion. I am limited in my ability to code a build myself, only able to build correctly already established Github sources. I am sad to hear that Jonathan-David, may not have the time commitment from his grant to complete the Windows64 build process since the MSYS2 cycle has collapsed with 'wheel' challenges. I use Visual Studio/CMake to build the LineArt branch of Blender and post it to GraphicAll.org. I would gladly do the same for a G'MIC build of Blender were it available. I will test any development, within the scope of my limitations ( ;-> ) Hopefully there are others with CMake knowledge to make this happen.
@paulhart2 it will happen when it will happen! people on this thread do manage to build G'MIC.. I am just quite occupied with personal things this week :)
I ended up using the last weekend to move cities :( I'm also occupied with day job + personal things this week but I plan to get to this as soon as I can! Thanks again @myselfhimself for raising a PR :)