Rust nightly / serde_macros support

[jgillich]

serde_macros on nightly breaks when you include a dependency that uses serde_codegen (serde-rs/serde#202). Supporting both via feature flags would be great.

[Byron]

Thanks for the hint. Unfortunately I am quite behind the eight ball regarding this problem, all I know is that right now serde is the reason people seem to be unable to use/compile most of the APIs presented here.

Am I correctly assuming that this issue is not related to #148 ?

[jgillich]

That's a different issue, on nightly you wouldn't use syntex. The serde readme has a section about how to do this, if nobody beats me to it I'll submit a PR soon(tm).

[Byron]

And I am looking forward to it.
It might be helpful to look into the cargo.toml.mako file for changes to how the dependencies work.
Then you should be able to test changes with something like make drive2-cli-cargo ARGS=check.

[jgillich]

jakob@debian-512mb-fra1-01:~/google-apis-rs$ make drive2-cli-cargo ARGS="build"
cd gen/drive2-cli && cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading clap v2.2.3
 Downloading yup-oauth2 v0.5.5
 Downloading strsim v0.4.0
 Downloading yup-hyper-mock v1.3.2
 Downloading ansi_term v0.7.2
 Downloading unicode-width v0.1.3
 Downloading vec_map v0.6.0
 Downloading itertools v0.4.11
 Downloading chrono v0.2.21
   Compiling winapi v0.2.6
   Compiling vec_map v0.6.0
   Compiling unicode-normalization v0.1.2
   Compiling serde v0.7.0
   Compiling rustc-serialize v0.3.18
   Compiling gcc v0.3.26
   Compiling openssl v0.7.8
   Compiling openssl-sys-extras v0.7.8
   Compiling winapi-build v0.1.1
   Compiling httparse v1.1.1
   Compiling itertools v0.4.11
   Compiling pkg-config v0.3.8
   Compiling openssl-sys v0.7.8
   Compiling typeable v0.1.2
   Compiling lazy_static v0.1.15
   Compiling language-tags v0.2.2
   Compiling semver v0.1.20
   Compiling rustc_version v0.1.7
   Compiling unicase v1.4.0
error: failed to run custom build command for `unicase v1.4.0`
Could not execute process `target/debug/build/unicase-151f58eccc4185f0/build-script-build` (never executed)

To learn more, run the command again with --verbose.
.cli.deps:2967: recipe for target 'drive2-cli-cargo' failed
make: *** [drive2-cli-cargo] Error 101

Any idea what's wrong here?

[jgillich]

FWIW I'm also getting that without my changes, and on two different machines. @Byron

[dermesser]

@jgillich I get that build error too; however, the API crates build fine when used as dependency of another crate (e.g., an application crate).

It seems that it's a bug either in cargo or the build script. This is what strace says:

30468 <... clone resumed> child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f0bb03ea9d0) = 30472
30472 set_robust_list(0x7f0bb03ea9e0, 24) = 0
30472 close(5 <unfinished ...>
30472 <... close resumed> )             = 0
30472 dup2(9, 0 <unfinished ...>
30472 <... dup2 resumed> )              = 0
30472 dup2(12, 1 <unfinished ...>
30472 <... dup2 resumed> )              = 1
30472 dup2(14, 2 <unfinished ...>
30472 <... dup2 resumed> )              = 2
* 30472 chdir("/home/lbo/.cargo/registry/src/github.com-88ac128001ac3a9a/openssl-sys-0.7.10" <unfinished ...>
30472 <... chdir resumed> )             = 0
30472 rt_sigprocmask(SIG_SETMASK, [],  <unfinished ...>
30472 <... rt_sigprocmask resumed> NULL, 8) = 0
30472 rt_sigaction(SIGPIPE, {SIG_DFL, [PIPE], SA_RESTORER|SA_RESTART, 0x7f0bbc4ca500},  <unfinished ...>
30472 <... rt_sigaction resumed> {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f0bbc4ca500}, 8) = 0
* 30472 execve("target/debug/build/openssl-sys-6d01d5414ba1a937/build-script-build", ["target/debug/build/openssl-sys-6"...], [/* 70 vars */] <unfinished ...>
30472 <... execve resumed> )            = -1 ENOENT (No such file or directory)
30472 write(7, "\0\0\0\2NOEX", 8 <unfinished ...>
30472 <... write resumed> )             = 8
30472 exit_group(1)                     = ?
30468 wait4(30472,  <unfinished ...>
30472 +++ exited with 1 +++
30468 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 30472
30468 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=30472, si_uid=1000, si_status=1, si_utime=0, si_stime=0} ---

as you can see, some cargo child process chdir()s into the crate directory inside the cargo registry, and tries to execve() the build script binary from there (marked with *). However, the script is not there; it's in the current working directory:

.../gen/gmail1$ ls -lh /home/lbo/.cargo/registry/src/github.com-88ac128001ac3a9a/openssl-sys-0.7.10
total 16K
-rw-r--r-- 1 lbo lbo 2.6K Apr 17 06:01 build.rs
-rw-r--r-- 1 lbo lbo 1.3K Apr 17 06:01 Cargo.toml
-rw-r--r-- 1 lbo lbo 1.1K Apr 17 06:01 LICENSE-MIT
drwxr-xr-x 2 lbo lbo 4.0K Apr 25 20:44 src

.../gen/gmail1$ ls -lh ./target/debug/build/openssl-sys-6d01d5414ba1a937/
total 1.4M
-rwxr-xr-x 1 lbo lbo 1.4M Apr 25 21:00 build-script-build
drwxr-xr-x 2 lbo lbo 4.0K Apr 25 21:00 out

I have no idea why cargo exhibits this behavior, though. Other crates with similar dependencies compile fine.

[Byron]

I now ran into the same issue with a rather recent cargo (cargo 0.11.0-nightly (42bce5c 2016-05-17)), and boiled it down to the .cargo/config coming as part of this repository.

The fix has just been pushed, even though I was too lazy to make it reproducible and file an issue (there are more important things to do right now).

However, I am totally considering to do that if nobody beats me to it.
@jgillich Thanks for posting your findings ! Those might be helpful when filing a cargo issue.