The intention of the `WITH_CXX11ABI` option is to allow the user to control toggle whether to compile against the CXX11ABI in libstdc++ (and whether to download a few specific CXX11ABI compatible mason packages as well).
This option is important if you are building binaries (like the node binaries) and you want to support a platform that is older and does not have a recent enough libstdc++ to support the CXX11ABI (like ubuntu:precise, centos6, etc).
But this was broken for clang++ builds due to the use of `MAKE_COMPILER_IS_GNUCXX`. That was preventing the correct flags from being set when using clang++ effectively making the option useless and resulting in the build defaulting to whatever the libstdc++-dev headers default is on the system (which varies per linux distribution based on how libstdc++-dev is packaged).
This fixes the problem by ensuring that clang++ builds still support toggling control over this option.
Note: clang++ > 3.9 supports targeting both the new CXX11ABI in libstdc++ (with `-D_GLIBCXX_USE_CXX11_ABI=1`) and targeting the old one (with `-D_GLIBCXX_USE_CXX11_ABI=0`).
I've seen several issues where users followed platform-specific install docs, but were unaware of additional prerequisites spelled out in the top-level INSTALL.md. So let's try making each platform's installation documentation self contained.
Previously we relied on tile buffers for querying features who's
rendered representations cross tile boundaries. Now we query multiple
tiles making it unnecessary to index features that are completely
outside a tile's boundaries.
Previously all QMapboxGL objects were sharing the same cache created
by the first instantiated object. Now it will share the cache only
if it points to the same path.
Fixes#11766
- assert symbol layer tiles must be geometry tiles, instead of dynamically checking
- re-use retainedBucketQuery iterator instead of calling find twice.
- Pulls over an update to line.vertex.glsl (looks like a no-op?)
- Add test ignores for collator, is-supported-script, line-gradient
- Exclude collator, is-supported-script, line-gradient from code generation.
- Symbol querying is now global instead of per-tile
- Symbols that bleed over tile boundaries no longer missed in queries
- Symbol results now sorted based on rendering order (ie overlapping symbols change their sort order when a bearing change causes their render order to change)
- Placement::retainedQueryData now responsible for maintaining symbol querying data for buckets that may no longer be in the TilePyramid.
* [ios, macos] Fact-checked expression guide
Corrected various factual inaccuracies in the “Predicates and Expressions” guide. Moved some explanation from the predicates section to the expressions section. Added sections for all the other expression types we support.
* [ios, macos] Reorganized custom function documentation
Reorganized the custom function documentation as a series of sections with headers and definition lists instead of a monolithic table. Copyedited various sections for accuracy. Linked references to custom functions. Added format string examples for all custom functions.
* [ios, macos] Made h3 more visible
* [ios, macos] Added Objective-C example of placeholders
* [ios, macos] Documented trig functions
* [ios, macos] Also increase h3 code size
* [ios, macos] Replaced Markdown with HTML in definition
* [ios, macos] Replaced Markdown with HTML in custom function documentation
* [ios, macos] Clarified stops
* [ios, macos] Cross-referenced functions
Each custom function definition cross-references the corresponding aftermarket function (or vice versa), the corresponding style specification expression operator, and any related NSExpression syntax.
* [ios, macos] Fixed links in predicate guide
* [ios, macos] Consolidated and documented NSExpression categories
Consolidated the NSExpression categories into a single category, with marks to separate different tasks. Documented the MGLAdditions category so that it shows up in the jazzy documentation.
* [ios, macos] Fixed NSExpression private category mixup
Fixes issue #11729. Close relative of issue #10956.
It is possible for us to receive Glyphs from the server that are valid, but have an invalid bitmap. In that case, the glyphs will be present in the `GlyphMap` used for shaping, but not present in the `GlyphPositions` used in `getGlyphQuads`. `SymbolInstance::hasText` looked at the shaping instead of the actual quads.
`symbol_projection.cpp` should never try to project a label without any quads, but we'll also try to make it so that it doesn't crash if it does.
