Add MSYS2 based builder for libiconv #24
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This uses MSYS2 to run the autoconf based build chain of libiconv, but still uses MSVC tools and libraries for the actual compilation and linking.
cmb69
commented
Oct 31, 2024
Comment on lines
+46
to
+48
| set WORKSPACE=${{github.workspace}} | ||
| set WORKSPACE=%WORKSPACE:\=/% | ||
| set WORKSPACE=/%WORKSPACE::=% |
There was a problem hiding this comment.
Could use cygpath for path conversion.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This uses MSYS2 to run the autoconf based build chain of libiconv, but still uses MSVC tools and libraries for the actual compilation and linking.
This could be an option to resolve winlibs/libiconv#14. While there is no x86 builder yet, pdbs are missing, and the DLL doesn't conform to our naming standards, a PHP-8.4 build with the libiconv_a.lib from https://github.com/cmb69/winlib-builder/actions/runs/11577343626 worked flawlessly.
Of course, one might argue that all winlibs should only use "native" Windows tools for being built, I'd argue that we don't have sufficient capacities to really cater to that. For packages only offering autoconf based builds (like libiconv, gettext, etc.), we may be better off to actually use these, instead of trying to work around (and ignore possibly important updates).
PS: possibly useful: https://github.com/emilbayes/rename-dll