Build for ogre 1.10 and 1.12

conda-forge / libignition-rendering4-feedstock

A conda-smithy repository for libignition-rendering4.

BSD 3-Clause "New" or "Revised" License

2 stars 5 forks source link

Build for ogre 1.10 and 1.12 #8

Closed Tobias-Fischer closed 3 years ago

Tobias-Fischer commented 3 years ago

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

conda-forge-linter commented 3 years ago

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 (recipe) and found it was in an excellent condition.

Tobias-Fischer commented 3 years ago

@conda-forge-admin, please rerender

github-actions[bot] commented 3 years ago

Hi! This is the friendly automated conda-forge-webservice. I tried to rerender for you but ran into some issues, please ping conda-forge/core for further assistance. You can also try re-rendering locally.

Tobias-Fischer commented 3 years ago

I think this is good to go as soon as quay is back up. @wolfv do you want to have a look whether the pinnings look fine?

Tobias-Fischer commented 3 years ago

@traversaro what's the idea to deal with downstream packages (libignition-gui4 and libignition-sensors4)? Do a similar treatment and build them with two variants?

For context, this PR caused the PR here.

traversaro commented 3 years ago

@traversaro what's the idea to deal with downstream packages (libignition-gui4 and libignition-sensors4)? Do a similar treatment and build them with two variants?

I need to check ignition-rendering, but if the OGRE headers are not included as part of the public headers of ignition-rendering, probably there is no reason to have two builds of downstream libraries?

traversaro commented 3 years ago

@traversaro what's the idea to deal with downstream packages (libignition-gui4 and libignition-sensors4)? Do a similar treatment and build them with two variants?

I need to check ignition-rendering, but if the OGRE headers are not included as part of the public headers of ignition-rendering, probably there is no reason to have two builds of downstream libraries?

I checked, and while ignition-rendering installs some headers with ogre neither ignition-gui nor ignition-sensors use them, so in theory the build should work fine with both ogre 1.10 and 1.12 . For downstream libraries such as ignition-sensors that seems to have runtime problems with ogre 1.12, what I was thinking to do is to have a run_constrained requirement ( https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#run-constrained ) on ogre.

traversaro commented 3 years ago

I checked, and while ignition-rendering installs some headers with ogre neither ignition-gui nor ignition-sensors use them, so in theory the build should work fine with both ogre 1.10 and 1.12 .

However, this is just a theory, and we could have subtle problems related to this, so a safer alternative could be to just depend explicitly on ogre and build the two variants for all downstream libraries (this would have the advantage that we explicitly run the test suite against both ogre 1.12 and 1.10 and we easily detect problems).

traversaro commented 3 years ago

In any case, I think this PR is good to go.

Tobias-Fischer commented 3 years ago

Agreed - shall we merge @wolfv?