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.
mdavidsaver
force-pushed
the
update-7.0.10
branch
from
3a640a4 to
30a8e7b
Compare
AlexanderWells-diamond
left a comment
AlexanderWells-diamond
left a comment
There was a problem hiding this comment.
This all looks good to me. Only a couple of minor comments. I'm happy with the support provided by this CI.
mdavidsaver
force-pushed
the
update-7.0.10
branch
from
30a8e7b to
b2491ec
Compare
mdavidsaver
force-pushed
the
update-7.0.10
branch
from
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. |
I suspect this all has something to do with softioc 4.6.1 having binaries for py3.12, but not 3.13. https://pypi.org/project/softioc/#files And it the GHA log I do see: This sort of loading error should be avoided by the build-time dependency injection to ensure that the wheel file dependency list reflects dependencies of the extension libraries it contains. setup(
cmdclass=dict(develop=Develop, **get_cmdclass()),
version=__version__,
ext_modules = [ext],
install_requires = [
# Dependency version declared in pyproject.toml
epicscorelibs.version.abi_requires(),I am not familiar with |
|
Thank you Michael, you are indeed spot on about it being the lack of softioc 3.12 binaries. What is happening is that the build-time dependency (specified here) picks up epicscorelibs 7.0.10.* , and so the shared objects are linked to those versions of the binaries. However at runtime, for reasons unknown, we drop back down to epicscorelibs 7.0.7.* . We use that exact install_requires line in our config file here but I must admit I don't understand how we can get an epicscorelibs version number to install, before we've actually installed a version of epicscorelibs. I'm sure I'm misunderstanding something about how the build process works. |
|
I'll save further discussion in this issue and move further messages into the linked pythonsoftioc issue. |
Fair enough, although I doubt that pythonsoftioc is to blame. I suspicion either that |
20 participants
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