Otherwise all test builds and imported libs will link to those too.
This causes e.g. Boost.Thread to be build and installed as a shared
library due to e.g. `<library>icuuc/<link>shared`
ICU doesn't support uint64_t directly but provides access to formatting
and parsing of decimal number strings.
Use Boost.Charconv to interface with that.
Fixes#235
A lot of checks and a major workaround are for ICU 4.8 or earlier which
can be removed.
An annoying bug (Parsing of timezones like "GMT" in "full" format followed by unrelated text)
fixed in 4.8.1 is worth avoiding by requiring this version over 4.8.0.
StringPiece is only available in 4.2+ and is required for proper parsing
and formatting.
As this version is now "old enough", just assume 4.2+ removing many
conditionals.
Speed up the configuration step:
- defaulted moves implies defaulted functions and rvalues
-> Clang 3.0, MSVC 19.0/2015
-> decltype, noexcept, auto & variadic templates also available in all compilers that support those
- override requires GCC 4.7+
- hdr type_traits implies hdr functional for all known stdlibs
Iconv is also available on Windows so not specific to the POSIX backend.
Instead of a shared_ptr to a vector we can simply use a `std::array`.
Finally the `iconv_t` can be put into an RAII class.
This deduplicates e.g. `convert_encoding_name`/`normalize_encoding`
and makes the structure more logical by not mixing those util functions
with the char converter code.
Define `_SCL_SECURE_NO_WARNINGS` for building the library to avoid "Call to 'std::copy' with parameters that may be unsafe" in `src\boost\locale\std\converter.cpp`
This also allows to remove the multiple suppressions of C4996
When copying properties from one stream to another the old stream only
gets a `erase_event` but may or may not have the value reset/zeroed.
So do that in all cases even though it is redundant on stream destruction.
Partial revert of 72a8e9eb75
The `exe` rule implicitly creates an `obj` rule for the given cpp file if it doesn't exist yet. This causes trouble when the cpp file is meant to be built with different options by multiple `exe` rules as the 2nd rule will reuse the `obj` rule from the first and hence ignores the different options such as the include path.
Here it affects the `has_external_iconv` target due to the conflict with the `has_iconv` target.
Hence add back an `obj` rule for the former. Fixes#63
The same problem exists with the `has_icu*` targets. Fix it similarly.
To support e.g. recent Cygwins where relative paths to the current file are not automatically resolved
move the sources into a `boost/locale` subfolder and add `src` to the private include paths.
This then allows to include those files as `"boost/locale/foo/bar.hpp"`.
