-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
Try to trigger new boost build #123
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe:
Documentation on acceptable licenses can be found here. |
@conda-forge-admin, please rerender |
…da-forge-pinning 2020.12.21.13.42.08
@conda-forge-admin, please rerender |
Hi! This is the friendly automated conda-forge-webservice. |
…da-forge-pinning 2020.12.21.13.42.08
@conda-forge-admin, please rerender |
Hi! This is the friendly automated conda-forge-webservice. |
@conda-forge-admin, please rerender |
@@ -164,8 +164,7 @@ outputs: | |||
- suitesparse | |||
- zlib | |||
- fenics-ffc =={{ version }} | |||
- hdf5 * {{ mpi_prefix }}_* | |||
- {{ pin_compatible("boost-cpp", exact=True) }} |
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.
{{ pin_compatible(..., exact=True) }}
means that it pins to the exact build (i.e., on the build string level).
Here you rather want a plain boost-cpp
in host
/run
so that conda-build
will replace it with the pinnings definition.
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.
The fenics
package requires the exact boost-cpp
version which is the cause of conda-forge/mshr-feedstock#18
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.
exact
boost-cpp
version
Exact version would be understandable. But the current conda-forge-pinning
already has a max_pin: x.x.x
for boost-cpp
which means if you have it in host
and run
, then you'd get a pin to >=1.72.0,<1.73.0a0
.
Exact build is what doesn't seem sensible to me.
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.
If you don't trust conda-forge-pinning
(e.g., to avoid a max_pin
change affecting this recipe), you can do {{ pin_compatible("boost-cpp", max_pin="x.x.x") }}
yourself.
…da-forge-pinning 2020.12.22.11.23.16
@@ -164,8 +164,7 @@ outputs: | |||
- suitesparse | |||
- zlib | |||
- fenics-ffc =={{ version }} | |||
- hdf5 * {{ mpi_prefix }}_* |
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.
hdf5
has a run_export
has includes the MPI variant. We can rely on that one.
@jan-janssen, I don't know why |
The reason why we need to pin boost explicitly is conda-forge/mshr-feedstock#18 and as you removed my changes we are basically back at #120 . I know that adding |
As the tests take an hour to run I opened another pull request with my previous suggestion #124 |
It seems to be an issue with combined recipes. When there is just the lib package it creates two builds for linux as well as it should. The easiest way I was able to force two builds was by adding boost-cpp to each sub package. |
That workaround is no good, because the pinning is too specific and is likely to cause downstream (build and user-site) issues.
The behavior for Linux I understand. It should be fine to build multiple variants in one jobs. |
# NOTE: Top-level environment with boost-cpp is only to separate the build for | ||
# multiple boost versions into different CI jobs. | ||
# TODO: Needs investigation why "separate the two boost builds more strictly" | ||
# would be necessary. Ref: | ||
# https://github.com/conda-forge/mshr-feedstock/pull/23#issuecomment-749520383 | ||
requirements: | ||
host: | ||
- boost-cpp |
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.
@jan-janssen, since you weren't happy with my changes, I added this.
This is still just a workaround. I don't know if it's necessary. If it is, the cause should be investigated.
Prime andidates for causes are always:
- reused CMake caches (but
build-libdolfin.sh
seems to work in a freshbuild
dir already, so maybe not this) - unexpected behavior from
conda-build
withoutputs
, e.g., PIP_NO_DEPENDENCIES & co not set for outputs/*/script conda/conda-build#3993
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.
Thanks
@conda-forge-admin, please rerender |
…da-forge-pinning 2020.12.22.11.23.16
@mbargull I am fine with the changes - I was not aware of the |
Yeah,
Sure, go ahead if it looks fine to you! Just trying to help with avoiding subsequent issues here ;). |
If we want to be super-correct, it looks like @jan-janssen, you seemed to be time-constrained here, so I'll leave this up to you if you want to fix this now or rather later. |
I open another pull request for this and merge this one so we can continue with conda-forge/mshr-feedstock#23 |
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)