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.
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.