[osqp] add options to disable ctrlc interrupt

[proyan]

Summary

Changes to recipe: osqp/0.6.3

Motivation

Adds option to disable ctrlc

Details

OSQP provides CMakeList variable CTRLC to disable the capture of SIGINT. This change exposes the update to be changed via options at the downstream package

---

• [ ✓] Read the contributing guidelines
• [ ✓] Checked that this PR is not a duplicate: list of PRs by recipe
• [ ✓] If this is a bug fix, please link related issue or provide bug details
• [✓ ] Tested locally with at least one configuration using a recent version of Conan

---

Add a 👍 reaction to pull requests you find important to help the team prioritize, thanks!

[uilianries]

@proyan Hello! Thank you for your suggestion of that new option. Please, be aware Conan offers a way to set CMake definitions without touching any Conan recipe, the Conan Config tools.cmake.cmaketoolchain:extra_variables (https://docs.conan.io/2/reference/commands/config.html#conan-config-list). Using this feature, you can accommodate your package to use whatever custom build you need, without adding new options in the recipe and changing its recipe revision.

You will need to add it to your Conan profile, like:

[conf]
osqp/*:tools.cmake.cmaketoolchain:extra_variables={"CTRLC": "OFF"}
osqp/*:tools.info.package_id:confs=["tools.cmake.cmaketoolchain:extra_variables"]

This section tells Conan to pass -DCTRLC=OFF to CMake when building any version of osqp. As this configuration will affect the produced library, it's important to make sure its Package ID will be different as well, which is why tools.info.package_id:confs is listed.

The same configuration can be applied via command line, but it's a bit messy IMO:

conan create recipes/osqp/all --version=0.6.3 -c tools.cmake.cmaketoolchain:extra_variables='{"CTRLC": "OFF"}' -c tools.info.package_id:confs='["tools.cmake.cmaketoolchain:extra_variables"]'

---

We avoid adding custom new options to recipes as the CI does not cover all combinations, and in case of a bug, we hardly spot at the review, as it needs to be built locally to check each result, and believe we have several cases where options do not work when using a non-default value. Still, it does not mean we do not support new options, those that are seen as important or have a chorus, are always welcome when well tested first.

Regards.