-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Buildability on CentOS-7 and Windows using PCRE2 sources #30
Comments
Hmm... https://pythonspeed.com/articles/centos-8-is-dead/ Let me dig around for a Docker image to test compilation that I don't have to perform CPR on to get it working. |
I think I fixed the issue. @jerinphilip Can you try if it works now? |
Hold that: regression test failed, but I think I'm onto the right thing ... |
@ugermann I have jerinphilip/bergamot-translator#60 ready to provide feedback. |
@jerinphilip I'm not able to run the workflows in jerinphilip/bergamot-translator#60.
|
I'm not sure where the error logs are coming from in your message, but looks like manylinux build passed after I point to current main: |
The error log comes from running
locally. That's |
Experimentation in several repositories lead me to believe we have to take a look at the ExternalProject build of PCRE2 (from sources).
I'm trying to tinker with a GitHub action that allows me to release py3.6, py3.7 manylinux wheels eventually to get batteries included bergamot package into pypa. Here's a teaser.
However, the CentOS-7 based image which generates manylinux wheels seems to be not working well with ssplit-cpp. Please find the build full log at:
https://github.com/jerinphilip/lemonade/runs/4912697746?check_suite_focus=true
PCRE2 from source build log: relevant bits (click to expand)
Weirdly in the last the build is failing with the following error message.
Note that the existing build using ExternalProject compiles with Ubuntu and MacOS and fails with CentOS. We are also aware of issues with Windows when attempting to switch to compile PCRE2 from sources (we're working around this by using a vcpkg provision of pcre2 and using the not from source ExternalProject right now).
Since there are other issues affecting Windows compilation as well, I was wondering if it's worthwhile to pool the efforts and fix the problem here so as to provide a neat means to get the targets (when loaded from ExternalProject built from source) all the way up via CMake.
Thanks in advance,
The text was updated successfully, but these errors were encountered: