Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rework buildsys to be able to use newer serde #1557

Closed
cgwalters opened this issue Sep 13, 2018 · 0 comments
Closed

rework buildsys to be able to use newer serde #1557

cgwalters opened this issue Sep 13, 2018 · 0 comments

Comments

@cgwalters
Copy link
Member

I wanted to write a patch to start parsing JSON from Rust too, but to do that we can't use #[serde(deny_unknown_fields)]. I tried a few things, eventually landed at attempting:

#[derive(Serialize, Deserialize, Debug)]
#[serde(transparent)]
struct PermissiveTreeComposeConfig(TreeComposeConfig);

#[derive(Serialize, Deserialize, Debug)]
#[serde(transparent)]
#[serde(deny_unknown_fields)]
struct StrictTreeComposeConfig(TreeComposeConfig);

Except we can't actually use #[serde(transparent)] because of bindgen:

$ cargo update                                                                                                                                                                                                    
    Updating registry `https://github.com/rust-lang/crates.io-index`
error: failed to select a version for `serde_derive`.
    ... required by package `cbindgen v0.6.3`
    ... which is depended on by `rpmostree-rust v0.1.0 (file:///srv/walters/src/github/projectatomic/rpm-ostree/rust)`                                                                                            
versions that meet the requirements `= 1.0.21` are: 1.0.21

all possible versions conflict with previously selected packages.

  previously selected package `serde_derive v1.0.78`
    ... which is depended on by `rpmostree-rust v0.1.0 (file:///srv/walters/src/github/projectatomic/rpm-ostree/rust)` 

Which is the issue mentioned in this bugzilla.

So...ugh.

I guess what we need to do is split out bindgen into a separate src/bindgen build or something. The ugly bit will be teaching our vendoring bits about that.

cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Sep 21, 2018
The problem is building bindgen as part of our single run
locks serde to way old versions, and I want to use newer versions.

This also opens the door to potentially using an external `bindgen`
binary if available (as it likely will be soon in Fedora again).

Oh and I know this totally doesn't work with the vendoring
code yet...

Closes: coreos#1557
cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Sep 24, 2018
The problem is building bindgen as part of our single run
locks serde to way old versions, and I want to use newer versions.

Since Fedora will now again ship a `cbindgen` package, let's
also support using it if we find it, saving ourselves
the cost of building it.

For distros that don't ship it (e.g. CentOS) for CI purposes
we build it.  For downstream builds that are offline, rather
than vendor the cbindgen sources like we do with our main Rust,
let's just vendor the `rpmostree-rust.h` file as was suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=1608670

Closes: coreos#1557
rh-atomic-bot pushed a commit that referenced this issue Sep 25, 2018
The problem is building bindgen as part of our single run
locks serde to way old versions, and I want to use newer versions.

Since Fedora will now again ship a `cbindgen` package, let's
also support using it if we find it, saving ourselves
the cost of building it.

For distros that don't ship it (e.g. CentOS) for CI purposes
we build it.  For downstream builds that are offline, rather
than vendor the cbindgen sources like we do with our main Rust,
let's just vendor the `rpmostree-rust.h` file as was suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=1608670

Closes: #1557

Closes: #1573
Approved by: jlebon
rh-atomic-bot pushed a commit that referenced this issue Sep 25, 2018
The problem is building bindgen as part of our single run
locks serde to way old versions, and I want to use newer versions.

Since Fedora will now again ship a `cbindgen` package, let's
also support using it if we find it, saving ourselves
the cost of building it.

For distros that don't ship it (e.g. CentOS) for CI purposes
we build it.  For downstream builds that are offline, rather
than vendor the cbindgen sources like we do with our main Rust,
let's just vendor the `rpmostree-rust.h` file as was suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=1608670

Closes: #1557

Closes: #1573
Approved by: jlebon
rh-atomic-bot pushed a commit that referenced this issue Sep 25, 2018
The problem is building bindgen as part of our single run
locks serde to way old versions, and I want to use newer versions.

Since Fedora will now again ship a `cbindgen` package, let's
also support using it if we find it, saving ourselves
the cost of building it.

For distros that don't ship it (e.g. CentOS) for CI purposes
we build it.  For downstream builds that are offline, rather
than vendor the cbindgen sources like we do with our main Rust,
let's just vendor the `rpmostree-rust.h` file as was suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=1608670

Closes: #1557

Closes: #1573
Approved by: jlebon
rh-atomic-bot pushed a commit that referenced this issue Sep 25, 2018
The problem is building bindgen as part of our single run
locks serde to way old versions, and I want to use newer versions.

Since Fedora will now again ship a `cbindgen` package, let's
also support using it if we find it, saving ourselves
the cost of building it.

For distros that don't ship it (e.g. CentOS) for CI purposes
we build it.  For downstream builds that are offline, rather
than vendor the cbindgen sources like we do with our main Rust,
let's just vendor the `rpmostree-rust.h` file as was suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=1608670

Closes: #1557

Closes: #1573
Approved by: jlebon
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant