Fix up cmake builds and workflow for windows including required sourc… #9
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
…e changes. Maybe(?) fixed wheel to deploy window dynamic libraries that are required for windows.
Merged
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.
Feel free to take this to get a boost in a working windows build. These changes will get everything building and package the dynamic library along side the espeak and onnx in prep to deploy the dlls with the python package. I cleaned up setup.py some as well to prep for getting the wheel to work. There were also some minor source changes required to get this to compile with cmake and msvc and to get the exported symbols in the dll working. The workflow will provide a readyforwheel.zip that has everything build you can use to see if you can build the python package or what additional changes are needed.
The issue that was blocking your current changes was the use of package-config; this was using a version of the perl's strawberry gnu stack on the Windows GitHub workers and it has issues. I wrote out its usage and provided explicit install prefixes espeak in the cmake file only for window builds. I tried my best to not break anything linux related, but you'll need to test that theory.
Note that for the arch in Windows for cmake and python it will read as amd64, so I changed the expected lib path for deployment to follow the name. I'm sure there is a way to clean up all the use of those paths in the workflow change I made I'm just not very proficient at the workflow file syntax and it's really tedious to test, so it might be a little messy but it works.
There are likely additional flags you want to add to piper-phonemize's build and other changes to polish this off. I am probably at my limits, but I do hope you can take at least some of this in support of getting a windows piper build.