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
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.)
We must disambiguate `Double.pow(_: Double, _: Double) -> Double` and
`__C.pow(_: Double, _: Double) -> Double` as the Swift for TensorFlow
branch adds the former into the standard library. The explicit module
dispatch ensures that we make the overload resolution unambiguous
allowing building Yams.
Fixes https://github.com/jpsim/Yams/issues/263 by only constructing integer and floating point values from scalars if those scalars are in the `plain` "flow" style. It additionally allows through scalars with no styling information (`any`).
Due to https://bugs.swift.org/browse/TF-1203, there's a build failure
without this patch:
```
error: static member 'pow' cannot be used on instance of type 'Double'
```
```
error: static member 'pow' cannot be used on instance of type 'Double'
```
When building Yams with the TensorFlow toolchain, this crops us. Simply
add the explicit type annotation.
We would previously fail to install Yams from CMake due to searching for
the swiftmodule in the wrong location. This uses the new improved
generic installation rules that I've been using in a number of other
projects to install the swift content across all the platforms.
* Add TopLevelDecoder conformance
* fixup! Add TopLevelDecoder conformance
* Support decoding `Data`
- Set `TopLevelDecoder.Input` to `Data`
- Provide `YAMLDecoder.deecode(...)` function taking `Data` as input
- Add tests for `TopLevelDecoder` and `Data` decoding
- Add `Parser.Encoding.swiftStringEncoding` member to convert between the Swift String encoding and the Yams encoding
- Fix warnings with Swift 5.3
* Add TopLevelDecoderTests to CMakeLists.txt
* Only add TopLevelDecoderTests.swift to LinuxMain.swift if Combine is available
* Completely remove TopLevelDecoderTests from LinuxMain
* Use @available attribute
* Store cancellable
* 5.3
* Force unwrap
* merge compiler conditionals
* Fixes
* Try to run TopLevelDecoderTests with Swift 5.2+
* Only report code coverage for latest Xcode version
* Update README
* Remove stored cancellable
* Add changelog entries
* Install latest SwiftLint available to Homebrew
Expand the CMake based build to support running the test suite. This
allows testing on Windows as well. Although the test suite does not
fully pass on Windows yet, this brings us closer.
With this on Windows, the following is the result:
```
Test Suite 'All tests' failed at 2020-05-14 12:11:08.871
Executed 120 tests, with 9 failures (0 unexpected) in 0.505 (0.505) seconds
```
The failures in the test suite correspond to the conversion of floating
point values in the infinity and NaN cases (either converting to
`-infe+0`, `infe+0`, or `nane+0` instead of `-inf`, `inf`, `nan`, or
converting to `NaN` instead of `nan`).
Enable building against an uninstalled copy of Foundation but do not
require it. This allows for a simpler build system. If the user wishes
to build against an out-of-tree Foundation, they can simply specify
`Foundation_DIR` and `dispatch_DIR` when configuring and CMake will
handle the rest.
Rather than have a swift module directory that you need to find for each
library, use a single global swift module directory similar to the
runtime output directory. This will be useful for a follow up change to
enable tests.
The CMake instructions in the readme didn't quite work when I tried them on macOS today.
This patch includes a few changes to `CMakeLists.txt` and the `README.md` instructions to reflect the latest steps to build.
Also add a CI job to validate that this keeps working moving forward.
Currently `YAMLDecoder` uses `Resolver.basic` instead of `Resolver.default`, since it doesn't need to resolve types. This has the side effect of not including `.merge` as an option, making `decode` fail to see anchored properties.
This adds a CMake (3.15.1) based build to enable building Yams on
platforms where s-p-m does not yet function. It also enables
cross-compilation of Yams. This is sufficient to be able to build for
Windows with the following command line:
```
cmake -H build\debug -G Ninja -DFoundation_DIR=... -DCMAKE_Swift_COMPILER=...
cmake --build build\debug
```
Yams uses CYaml which requires a module. s-p-m will implicitly
construct the modulemap for the module, but provide an explicit one for
better control and to enable building without s-p-m.
JP Simard