-
Notifications
You must be signed in to change notification settings - Fork 16
Update 7.0.10 and GHA refresh #46
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
Conversation
This enables referring to e.g. {option}`msi -o` in the documentation,
and it will link to the correct location
This allows optionally printing out the value of one or more fields for each record found.
Certain windows build environments (see https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=1234387&view=results for an example) fail unless the echo command is properly quoted. This seems to be due to how Make handles various commands on non-posix systems; without the quotes it directly tries to run ``` echo foo bar ``` inside cmd.exe, which fails as echo is not a valid command in that context. Co-authored-by: Anders Harrisson <anders.harrisson@ess.eu>
This allows other modules like pvxs to find files there, too. Also, the install locations of homebrew and MacPorts are now detected rather than assumed. If a package is installed in both, the homebrew version is preferred.
Includes some unification of error text, narrower wrap margin. 'var' output now lists the variable types.
The bldEnvData.pl script now syntax-checks the envParam default values, allowing ANSI color macros to be used in the IOCSH_PS1 parameter.
But it also does not know warning -Wformat-security.
../fdManagerTest.cpp:76:29: warning: suggest braces around initialization of subobject [-Wmissing-braces]
76 | osiSockAddr addr = {0};
| ^
| {}
* github/7.0: (490 commits) fix clang warning missing-braces gcc < 5 does not know #pragma GCC diagnostic push use c++ style output to avoid porability problems with printf format fix format warning on mingw Updates to the Release Checklist Update core version numbers after tagging Generate RELEASE-7.0.10.md notes file Set core version numbers for release Another PR release note Replace UNRELEASED => 7.0.10 Add submodule release note entries Update git submodules for release Docs: Mention that pva is supported for JSON links Convert Release Checklist to Markdown Various fixes to the new-notes files Split PR-624 release notes iocsh.h: import documentation from AppDevGuide, minor tweaks doc clarify callbackRequestDelayed() timer allocation process doc comments in callback.h doc and callbackSetQueueSize sanity check ...
3a640a4 to
30a8e7b
Compare
AlexanderWells-diamond
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all looks good to me. Only a couple of minor comments. I'm happy with the support provided by this CI.
30a8e7b to
b2491ec
Compare
b2491ec to
2f23bcf
Compare
|
I think that the problems I am seeing with epics-base/p4p#193 are due to some ABI issue with mixing manylinux1 and manylinux2010, which will stop as these PRs get merged. So I plan to move forward with merging, and pushing pre-releases to pypi.org. So dependent GHA jobs with |
I see such a set: @coretl @AlexanderWells-diamond Please test when you have a chance. Let's see what breaks... |
|
I have yanked Because of a public ABI change, the next PVXS release will be 1.5.0. |
I can confirm that the set of modules |
|
Released as |
|
Not sure if this is the best place to mention, but I have noticed a bug in EDIT: I just noticed that the library it is trying to access is for 7.0.10, when only 7.0.7 is installed. |
|
We've also had this bug report for what looks like the same thing opened in PythonSoftIOC: I'm currently investigating. I'm confused how the EPICS 7.0.7 verson of epicscorelibs can be trying to load a 7.0.10 EPICS. |
This PR contains two large changes. Merging in epics-base 7.0.10. And a refresh of the github actions. I'm combining them because it would be more work to isolate them (aka. laziness). Many of the current GHA jobs are broken. Also, the 7.0.7 source fails to build with recent gcc/clang.
Changes to the GHA recipe would have the effect of only uploading wheels for cpython 3.8+ on Linux amd64, windows amd64, and OSX universal (I think). So no more i686 uploads. There is still a linux 2.7 job to check function, but the result is not uploaded. My idea being to drop py2.7 support after this set of releases. I picked 3.8 because it is currently the oldest available with actions/setup-python, the oldest cpython available in the oldest supported manylinux2014 image, and the oldest supported by cython >= 3.1 .
I prototyped this recipe for the set of packages down to p4p with https://github.com/mdavidsaver/p4p-integration
TODOs