boost-1.78 fix cmake auto configuration for windows

[pgeler]

closes: #8550
Specify library name and version: boost-1.78

cmake auto configuration failing with boost-1.78:

1> [CMake] 	"toolset": "-{}".format(self._toolset_tag),
1> [CMake] while calling '_toolset_tag', line 1294
1> [CMake] 	if self.settings.compiler in ("msvc", "Visual Studio"):
1> [CMake] 	ConanException: Invalid setting 'msvc' is not a valid 'settings.compiler' value.
1> [CMake] Possible values are ['Visual Studio', 'apple-clang', 'clang', 'gcc', 'intel', 'qcc', 'sun-cc']

---

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[CLAassistant]

All committers have signed the CLA.

[ghost]

I detected other pull requests that are modifying boost/all recipe:

• don't use distutils if Python version >= 3.10 #8759
• boost: Configure the proper namespace for CMake targets #8446
• [boost] Apply patch to fix https://github.com/boostorg/graph/issues/268 #6132
• boost: use clang-win toolset when compiler=Visual Studio and compiler.toolset=ClangCL #4749

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[SpaceIm]

Specify library name and version: boost-1.78

cmake auto configuration failing with boost-1.78:

1> [CMake] 	"toolset": "-{}".format(self._toolset_tag),
1> [CMake] while calling '_toolset_tag', line 1294
1> [CMake] 	if self.settings.compiler in ("msvc", "Visual Studio"):
1> [CMake] 	ConanException: Invalid setting 'msvc' is not a valid 'settings.compiler' value.
1> [CMake] Possible values are ['Visual Studio', 'apple-clang', 'clang', 'gcc', 'intel', 'qcc', 'sun-cc']

* [ ]  I've read the [guidelines](https://github.com/conan-io/conan-center-index/blob/master/docs/how_to_add_packages.md) for contributing.

* [ ]  I've followed the [PEP8](https://www.python.org/dev/peps/pep-0008/) style guides for Python code in the recipes.

* [ ]  I've used the [latest](https://github.com/conan-io/conan/releases/latest) Conan client version.

* [ ]  I've tried at least one configuration locally with the
  [conan-center hook](https://github.com/conan-io/hooks.git) activated.

Your settings.yml is outdated.

[DDoSolitary]

I encountered the same problem, but I think swapping the strings isn't a real fix. It only works if your compiler is Visual Studio.

Your settings.yml is outdated.

@SpaceIm I don't think it's a good idea to require an up-to-date settings.yml file. The recipe is breaking existing projects running on a somewhat old version of Conan. Such breaking change without any warning is really annoying.

I would suggest using a similar approach as conan-io/conan#9954, i.e. reading the compiler value with self.settings.get_safe('compiler') before comparision.

[ericLemanissier]

It's not going to happen, cf https://github.com/conan-io/conan-center-index/blob/master/docs/consuming_recipes.md

[SpaceIm]

The last revision of boost recipe already requires conan 1.33.0:

conan-center-index/recipes/boost/all/conanfile.py

Line 19 in 19dc4ac

required_conan_version = ">=1.33.0"

And msvc has been added to settings.yml in conan 1.33.0 https://github.com/conan-io/conan/releases/tag/1.33.0

[pgeler]

The last revision of boost recipe already requires conan 1.33.0:

conan-center-index/recipes/boost/all/conanfile.py

Line 19 in 19dc4ac

required_conan_version = ">=1.33.0"

And msvc has been added to settings.yml in conan 1.33.0 https://github.com/conan-io/conan/releases/tag/1.33.0

the problem in the way conan upgrade the configurations, changes in seettings.yml especially when it was all the way "default" is a painful to push through entire organization especially when people using it time to time...

[SpaceIm]

self.settings.compiler in ("msvc", "Visual Studio") raises ConanException when msvc is not in settings.yml, it's a conan client issue I believe, not a recipe issue.
We should be able to compare self.settings.compiler with any string, it should never raise (return False instead). Indeed, recipes have no control on consumers settings.yml.

Does it work with str(self.settings.compiler) in ("msvc", "Visual Studio")?

(also related to #6155)

[pgeler]

self.settings.compiler in ("msvc", "Visual Studio") raises ConanException when msvc is not in settings.yml, it's a conan client issue I believe, not a recipe issue. We should be able to compare self.settings.compiler with any string, it should never raise (return False instead). Indeed, recipes have no control on consumers settings.yml.

Does it work with str(self.settings.compiler) in ("msvc", "Visual Studio")?

(also related to #6155)

yes, it does work, in fact that was original solution. but then found this ("order") hack in other receipts

[pgeler]

I think it will be more straight forward to change to condition to self.settings.get_safe("compiler"): @SpaceIm, @SSE4 thoughts?

[ericLemanissier]

get_safe does not help here. Compiler always exists

[pgeler]

self.settings.get_safe("compiler")

it does help

well, another way I may think of is to use local variable in condition compiler == 'vc'

[SpaceIm]

str(self.settings.compiler) seems to be the most robust approach.

[pgeler]

str(self.settings.compiler) seems to be the most robust approach.

✔️ sold

[ericLemanissier]

I don't like this change because it introduces a weakness to typos. It's necessary to update settings.yml for other reasons anyway. If user really want to use an outdated settings.yml, they can use older revisions of recipes.

[pgeler]

I don't like this change because it introduces a weakness to typos. It's necessary to update settings.yml for other reasons anyway. If user really want to use an outdated settings.yml, they can use older revisions of recipes.

outdated settings.yml was not intentional, the very first time I actually noticed it even exists was @SpaceIm comment above. The main problem I view is in strategy conan uses for upgrading it. But I'm confident that the strategy was thoughtful and don't want to dealt with changing it... I'm just trying to simplify upgrade for my organization and other people who is not to investigate each issue with every update. Otherwise the package manager does not remove, but add complexity to their day by day work...

[prince-chrismc]

simplify upgrade for my organization and other people who is not to investigate each issue with every update.

Former Conan enterprise user, what worked best for us was using the https://docs.conan.io/en/latest/reference/commands/consumer/config.html install option with a repo with our settings (but we needed custom settings and had to semi-automatic upgrade)

There's a super awesome feature

The conan config install can be periodically executed, before any command, when config_install_interval is configured in conan.conf. Conan runs it based on config_install.json, including the timestamp of the last change.

Hopefully this helps

[prince-chrismc]

You'll need to retrigger CI, close the pr wait 10s and then re-open it 🔁

[conan-center-bot]

All green in build 7 (acf372e3191696d8fe38780936caf8a3bfe1306e):

• boost/1.69.0@:
  All packages built successfully! (All logs)

• boost/1.70.0@:
  All packages built successfully! (All logs)

• boost/1.71.0@:
  All packages built successfully! (All logs)

• boost/1.72.0@:
  All packages built successfully! (All logs)

• boost/1.76.0@:
  All packages built successfully! (All logs)

• boost/1.73.0@:
  All packages built successfully! (All logs)

• boost/1.78.0@:
  All packages built successfully! (All logs)

• boost/1.74.0@:
  All packages built successfully! (All logs)

• boost/1.77.0@:
  All packages built successfully! (All logs)

• boost/1.75.0@:
  All packages built successfully! (All logs)