boost: Improve option for i18n backend

[lieser]

• Deprecate i18n_backend option and add separate ones for iconv/icu
  • Note that boost also a posix, std and winapi backend.
• For the iconv backend, add the possibility to use the one included in libc instead of libiconv
  • also make that the default
  • Macos still uses libiconv as default
• On Windows, allow building without both iconv/icu backends and make it the default ([question] Boost: default i18n_backend on Windows #5528)
  • Something similar was added in boost: fix i18n_backend=icu support for version 1.7{1,2,3}.0 #1704, but nether merged
  • Unsure if WindowsStore/WindowsCE OS are handled correctly (boost: fix i18n_backend=icu support for version 1.7{1,2,3}.0 #1704 did still need on of the backends there)
• Fail build if Boost's test for the backend fails

---

Below are some original notes for this PR, which are partly outdated.

As far as I can tell boost sadly:

• has no option to distinguish between iconv from libc or libiconv
  • It does automatic detection, and always preferes the one from libc
• even if the iconv/icu backend is set to on, and boost fails not find it, compilation will still work

The above means that:

• iconv can be set True (i.e. as external lib), but boost will still use the one from libc
• iconv can be set to use the one from glibc, but silently use an external one, or (i.e. on windows) without it at all
• iconv/icu can be set to True, but boost may still be build without them if it fails to find them

Note that the first one was already an issue in the current recipe. I think it would be good to get an error, or at least a warning.
Unfortunately I can't think of an nice and easy solution.

• One could try to search in the build output for e.g. iconv (libc) : yes. Don't know if Conan already support that, and if that is something that recipes should do.
• Patch boost builds files to not only changes how the options normally behave, but also add a new one to be able set iconv from libc and external lib separately

Maybe this could also be address in a separate PR later on.

See also the boost documentation and build file for reference:
https://www.boost.org/doc/libs/1_76_0/libs/locale/doc/html/building_boost_locale.html
https://github.com/boostorg/locale/blob/develop/build/Jamfile.v2

---

• 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:

• Boost.python requires numpy. Fix function _run_python_script(). #5643
• [boost] For Visual Studio, pass some values of settings.compiler.toolset to B2 #5119
• boost: header only boost::system #5051
• boost: use clang-win toolset when compiler=Visual Studio and compiler.toolset=ClangCL #4749
• Boost/1.72.0/mpi #3959

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

[madebr]

Does the subsystem matter?
Isn't checking for settings.os enough?

Suggested change

	return ((self.settings.os == "Windows") and
	(self.settings.os.subsystem in [None, "cygwin"]) or
	self.settings.os in ["WindowsStore", "WindowsCE"])
	return self.settings.os in ("Windows", "WindowsStore", "WindowsCE")

If something is built for Windows, isn't that enough?

[lieser]

For the wsl subsystem I would say it matters. As this is really a Linux (WM), I would expect boost to not treat it as a windows system.

As for the other subsystems, I'm not that familiar with them. But the check in #1704 did treat cygwin as being non posix (_is_posix_platform check there). And it is also handled special by the boost build system:
https://github.com/boostorg/locale/blob/ccb8fbb9a1a0dbdffb1054ffa34e4aba1e425642/build/Jamfile.v2#L271-L275

[madebr]

I don't know much about wsl, but aren't applications built with wsl actually Linux applications (os=Linux)?

[lieser]

Yes, applications build with in the wsl should be just Linux applications. Was also surprised that the wsl did show up in that list.

I just did install conan under the wsl, and for me the default config of conan was os=Linux. Maybe someone else can explain for what os=Windows; os.subsystem=wsl is actually used, and how it should be treated.

[SSE4]

WSL is capable of running:

• most of regular Linux executables (ELF files) which use Linux syscalls
• regular Windows executable (PE files)

the first case is definitely for os=Linux (as these compiled ELF files will be run on regular Linux, as well on WSL/WSL2)
the second is probably os=Windows; os.subsystem=wsl if you want to use build or use Windows applications via WSL layer (e.g. launching bash and other tools from WSL instead of MSYS)

[lieser]

Thanks for the explanation. I just did a test with -s os.subsystem=wsl and both iconv/icu disabled, and boost did not complaint.
But I also did not really see a difference in the output (e.g. paths there still C:\Users\.., and not something like /mnt/c/...). So unsure if I really tested it correctly.

So adding wsl to the subsystems here seems form my current understanding to be the correct thing (but I'm still not 100% sure).

[SSE4]

subsystem affects a couple of functions, such as:

• unix_path
• run_in_windows_bash

if recipe doesn't use any of them, there will be no difference in output
as I remember, boost build system doesn't rely on bash, so subsystem might be completely irrelevant for the package
(except the fact you are using the correct compiler targeting the correct subsystem, but that's out of our control right now)

[prince-chrismc]

We had done some experiments with some of our testers, my notes match SSE4's comment https://github.com/conan-io/conan-center-index/pull/5553/files#r634440165. It makes the executable compatible with both environments.

I suspect this mode of working is not supported by Boost, https://www.boost.org/doc/libs/1_76_0/more/getting_started/windows.html notes mingw is not support which (to my knowledge) is similar.

I have no objections but I share the sentiment that perhaps if best to leave out the subsystem. Since it introduces more complexity (and Boost is already huge).

[lieser]

removed the check for the subsystem

[SSE4]

I am not sure if I like True/False, especially for non-binary values, and two options, IMO it's hard to understand.
I would prefer something like:

"i18_backend" : ["libiconv", "iconv_libc", "icu", "winapi", "posix", "std"]

another things I don't understand from the docs if backends are completely orthogonal (mutually exclusive), or is it possible to activate multiple backends at once (e.g. both ICU and iconv)?

last thing, I don't like, is "soft" fallbacks, then I request one configuration with some backend, but boost silently switches to another configuration I didn't request instead of failure. that introduces binaries incorrectly labeled (e.g. package id indicates there is a dependency on libiconv, but there isn't any, as boost suddenly felt back to libc or winapi).

/cc @madebr @grafikrobot for their input

[lieser]

or is it possible to activate multiple backends at once (e.g. both ICU and iconv)?

Yes, you can enable both ICU and iconv backend at the same time. Which is the reason I added separate options for it, instead of having on i18_backend.

As for the iconv value, maybe something like ["libiconv", "libc" (or "iconv_libc"), "off"] would be better?

And I would not add extra options for disabling winapi, posix, std, unless there is someone who actually needs to do that.

last thing, I don't like, is "soft" fallbacks, then I request one configuration with some backend, but boost silently switches to another configuration I didn't request instead of failure

I'm totally with you on that. But like I wrote, I did not really find a good solution for that.
But I do hope that we will be collectively be able to come up with one.

[lieser]

or is it possible to activate multiple backends at once (e.g. both ICU and iconv)?

Just to make sure, I tried it with both enabled on windows. In the call to b2 I see boost.locale.icu=on boost.locale.iconv=on, -sICU_PATH=... and -sICONV_PATH=....

But the build seems to fail to detect ICU:

    - iconv (libc)             : no
    - iconv (separate)         : yes
    - icu                      : no
    - icu (lib64)              : no

I will look into it next week to see what is going wrong.

[prince-chrismc]

I am in favor of changing the defaults since it removes the LGPL from the boost recipes 😄

[SSE4]

I am in favor of changing the defaults since it removes the LGPL from the boost recipes 😄

but boost is not LGPL, it's BSL

[prince-chrismc]

I am in favor of changing the defaults since it removes the LGPL from the boost recipes 😄

but boost is not LGPL, it's BSL

libiconv requirement changes that from the enterprise consumer POV

[lieser]

I now included a patch for Boostl:local to fail if the test for the requested backend fails.
Also fixed the other review comments.

I also investigated the local failed build with ICU backend on windows.
The problem is that the ICU libraries start with an s (e.g. sicudt instead of icudt). Boost.Locale seems to have an option to solve this (ICU_LINK), but the recipe has a comment that this causes problems with Boost.Regex (see also https://github.com/boostorg/regex/blob/7da62c1edb2f2c8256b3d676a637d6bbc02b6e0a/build/Jamfile.v2#L36-L39).

As this is not directly related to the issue I'm trying to solve here, and should have not worked before either, I would like to leave a fix for that out of this PR.

[lieser]

Seem like on Macos the c library does not include iconv. Switched there to libiconv as default

[conan-center-bot]

All green in build 8 (9e28bacde5af8aada7cee351315d980f80becfa9):

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

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

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

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

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

• boost/1.74.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)