CYaml has been a private dependency of libYams.so and linked statically
against it since 2a93d740ef.
Therefore, CYaml should be built as PIC, but it wasn't.
Since gas 2.31 (Ubuntu 20.04), which includes implicit promotion of
non-PIC reloc (R_X86_64_PC32) to PIC reloc (R_X86_64_PLT32)[^1], this
issue is not revealed. However gas older than 2.31 (Ubuntu 18.04), this
PIC-ness mismatch causes linking failure with the following output:
```
/usr/bin/ld.gold: error: lib/libCYaml.a(api.c.o): requires dynamic R_X86_64_PC32 reloc against 'yaml_realloc' which may overflow at runtime; recompile with -fPIC
/usr/bin/ld.gold: error: lib/libCYaml.a(scanner.c.o): requires dynamic R_X86_64_PC32 reloc against 'yaml_parser_fetch_more_tokens' which may overflow at runtime; recompile with -fPIC
```
This patch fixes the PIC-ness mismatch by enabling
`POSITION_INDEPENDENT_CODE` explicitly, and adds CI job to check cmake
build system works on Ubuntu 18.04.
[^1]: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bd7ab16b4537788ad53521c45469a1bdae84ad4a
* [CI] Add macOS 12 / Xcode 13.3 / Swift 5.6 jobs
* Fix Apple TV on Xcode 13.3
* Update jazzy to 0.14.2
* set sdk
* Revert Analyze CI job to Xcode 13.2.1
This changes how `CYaml` is built and used within Yams. As there are no
interfaces from `CYaml` being directly exposed, we can statically link
the library. However, this still would cause a problem as the `CYaml`
import would be serialized into the module requiring that the module is
available when building anything which consumes `Yams`. To avoid that,
change the `import CYaml` instances to `@_implementationOnly`. This
allows for `CYaml` to not be required at the consumer site.
While in the area of the CMake build system, clean up some of the build
system to use language specific options. This is required to avoid the
de-duplication of the options across languages and enables linking
`CYaml` statically into the library. Note that on Windows static
linking of *Swift* libraries is not yet properly supported and this does
not enable that nor use that - it is statically linking *C* content.
This now allows building Yams dynamically as a single library target.
On Windows, this is a negligible space savings of ~16KiB.
## Summary:
This adds `sequenceStyle` and `mappingStyle` options to `Emitter.Options`, which allows those using `YAMLEncoder` to specify whether "sequences" and "mappings" use `block` style (the default style) or `flow` style.
Also, CHANGELOG.md was updated and Podspec version was bumped to 4.0.7.
No unit test coverage was added, as there isn't direct unit test coverage for `Emitter.Options`, however there are already tests around mapping and sequence styles in the `EmitterTests` class, so this should be sufficient.
_**Note:** "sequences" are arrays / lists, "mappings" are dictionaries_
## Strategy:
`sequenceStyle` and `mappingStyle` were added to `Emitter.Options`, and changes were cascaded down into `Emitter`, `Encoder`, and `Node` where necessary. The existing field `sortKeys` in `Emitter.Options` was used as a guide to see where both `sequenceStyle` and `mappingStyle` should be added in other places in the code. Otherwise, minimal code changes were made to gain the desired feature.
## Examples:
Given an example YAML file here:
```
structure:
edges:
e1:
- n1
- n2
e2:
- n1
- n3
e3:
- n2
- n3
nodes:
- n1
- n2
- n3
```
### `sequenceStyle`
Setting `sequenceStyle` to `.flow` now generates:
```
structure:
edges:
e1: [n1, n2]
e2: [n1, n3]
e3: [n2, n3]
nodes: [n1, n2, n3]
```
Which can be more visually pleasing, readable, and compact in certain scenarios such as this one.
### `mappingStyle`
Setting `mappingStyle` to `.flow` now generates:
```
{structure: {edges: {e1: [n1, n2], e2: [n1, n3], e3: [n2, n3]}, nodes: [n1, n2, n3]}}
```
Which may not be as visually pleasing with larger YAML files, but still could be useful in certain scenarios, and having the option to configure `mappingStyle` does "match parity" with being able to configure `sequenceStyle`.
Also you might notice, setting `mappingStyle` to `.flow` also forces `sequenceStyle` to be `.flow`, but this is not an error as for "flow" style to be used correctly with mappings at the top level, it must be enforced recursively through each child. (Implying, child mappings and child sequences must also be "flow" style.)
The underlying compiler issue that was prenventing the test suite from complete
execution on Windows has been resolved. Restrict the full test suite to newer
versions of Swift. While technically the 11/10 snapshot should contain the fix,
another issue prevents its usage. The 11/20 snapshot and newer should support
the full test suite on windows as well.
The Windows support should now be at complete parity with the other platforms.
With the use of compnerd/gha-setup-swift, it is relatively easy to enable a
matrix build on Windows, enabling building and testing against different Swift
verisons. Use this to enable builds for 5.5 and 5.6-dev.
Update CI to run with Swift 5.4 on Linux. Swift 5.4 ships with Xcode 12.5, which requires macOS 11, which GitHub Actions don't support yet.
Also add Swift 5.4 to the podspec's swift versions.
This has 2 important fixes from Lyft's internal config:
1. The `cc_library` is now tagged with `swift_module` which is a special
tag that tells rules_swift to generate a module map for the library.
This is likely why sandboxing had to be disabled.
2. This adds `-fPIC` to the `cc_library` compilation. This is required
for C libraries that Swift depends on, but there's an outstanding bug
in bazel where this isn't handled correctly when you use the target
through the host transition.
This also formats this file using buildifier
The libyaml setup is currently configured improperly, not selecting
either shared nor static builds, resulting in libyaml being built
assuming that it is a user of libyaml, which is incorrect. Adjust the
build to build libyaml as a shared library.
This change is not exactly precise, over generalizing the application of
the `YAML_DECLARE_EXPORT` to avoid bumping the minimum version of SPM to
5.4, which is the first version to include support for
`.platform(.windows)`. This should not impact the other targets, as the
macro is not consulted for other targets.
This should allow us to enable testing on Windows again which was
disabled with #304.
JP Simard