[rxcpp/4.1.1] Add patches required for building on gcc 14

[keef-cognitiv]

Summary

Changes to recipe: rxcpp/4.1.1

Motivation

rxcpp cannot compile on gcc 14 due to a definition of an assignment operator. It appears that the project may have been abandoned. There hasn't been any releases in 3 years and there hasn't been any pushes or PR commentary for 2 years.

Details

PR ReactiveX/RxCpp#606 was opened upstream several months ago to address the issue. These patches just apply the exact same change to the 4.1.1 release.

---

• Read the contributing guidelines
• Checked that this PR is not a duplicate: list of PRs by recipe
• Tested locally with at least one configuration using a recent version of Conan

[jcar87]

Hi @keef-cognitiv - thanks for opening this PR.

Will check with the team on this one. Our policy is that in line with our terms of use - libraries are provided "as-is". If this library is no longer maintained and does not work with gcc14 - then that's the case, and the best course of action would be to reflect that in the recipe, rather than attempt to fix it. We make some exceptions for trivial fixes (a common case is missing includes from the standard library that were previously transitive).

-        on_error_notification& operator=(on_error_notification o) { ep = std::move(o.ep); return *this; }
+        on_error_notification& operator=(on_error_notification o) RXCPP_DELETE;

This may get the library to build with gcc 14, but it also looks like a functionality change - is it marking an operator with delete where it previously had an implementation? Would it change the behaviour for users in other compilers or previous versions of gcc? This is not something we would want to do.

On top of that, the ongoing risk is that it may be one small fix today - but if the library really is abandoned - in the future more fixes will be needed, and we don't want to end up maintaining a proxy fork via patches in Conan Center.

As I said, will check with the team - as these are dealt in a case-by-case basis, thanks!

[AbrilRBS]

Hi @keef-cognitiv thanks a lot for taking the time to create this PR.

For cases like this, we have been moving away for a while now from accepting these kinds of patches, as this more often than not tends to end up with us being the unoficial maintainers of forks of the recipe.

Thus, I'm proposing a different solution here and will commit them shortly

• Add a validate_build for versions of gcc >= 14

With this you'd be able to specify -s="rxcpp/*:compiler.version= and have it use an older one that is capable of building the package

Some other things worth noting:

• If you need this locally, you can check the local-recipes-index feature, docs here, to allow for local clones of CCI to work as remotes, where changes can be made to your liking
• For cases like this in the future, we're thinking about ways to apply patches [feature] consider ability to apply/inject arbitrary patches to recipe without forking repository conan#17360 without the need to create them in the recipe