Closed Uranite closed 1 month ago
I noticed that we're using an outdated llvm-mingw and mingw-w64, what if we update them? 🤔 Possible free performance? Edit: and maybe we can use clang instead of gcc for the x64 build?
I based my repo on the handbrake nightly builds one and, in order to avoid any kind of breakage or bugs, I did not update the toolchains (evidently they are tested and bug-free to build HandBrake). For me there is no problem to update, if you feel like doing some commits and a pull request I am happy to accept it :) Thank you very much
@Uranite Thank you for the pull request. I tested the windows binaries and everything works as expected. I noticed that the last commit on your fork enabled link-time optimization. Would it be worth activating them (by merging the commit)? I also wanted to ask if you would be willing to do the same work for the workflows for the other operating systems. Thank you again!
@Uranite Thank you for the pull request. I tested the windows binaries and everything works as expected. I noticed that the last commit on your fork enabled link-time optimization. Would it be worth activating them (by merging the commit)? I also wanted to ask if you would be willing to do the same work for the workflows for the other operating systems. Thank you again!
Huh, I didn't actually expect that the workflow run would've succeeded with LTO, it seems that full LTO fails, but thin LTO doesn't. Anyway, you're free to merge the commit if you want, or would you like me to make a pr? I'll also look into the workflows for other operating systems
Edit: forget what i said about LTO, just --lto doesn't seem to be doing something edit 2: to clarify, the args are --lto=on or --lto=thin
It's mainly a lack of manpower, a clang mingw toolchain would be quite nice to have (it should allow debugging libhb in Visual Studio for example).
@Uranite Thank you for the pull request. I tested the windows binaries and everything works as expected. I noticed that the last commit on your fork enabled link-time optimization. Would it be worth activating them (by merging the commit)? I also wanted to ask if you would be willing to do the same work for the workflows for the other operating systems. Thank you again!
Huh, I didn't actually expect that the workflow run would've succeeded with LTO, it seems that full LTO fails, but thin LTO doesn't. Anyway, you're free to merge the commit if you want, or would you like me to make a pr? I'll also look into the workflows for other operating systems
Edit: forget what i said about LTO, just --lto doesn't seem to be doing something edit 2: to clarify, the args are --lto=on or --lto=thin
Since you mentioned that the build with full LTO fails, I would do some additional testing to ensure no new bugs are introduced with LTO=thin. In the meantime, we can focus on updating the other workflows and, when all tests are done, we could add LTO. Thanks!
It's mainly a lack of manpower, a clang mingw toolchain would be quite nice to have (it should allow debugging libhb in Visual Studio for example).
Nice! Then there is no reason not to update the builds. I just hope that, since we don't have a team to properly test the builds, sneaky bugs won't be introduced... Same as before
I noticed that we're using an outdated llvm-mingw and mingw-w64, what if we update them? 🤔 Possible free performance? Edit: and maybe we can use clang instead of gcc for the x64 build?