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

rust-bindgen: 0.22.1 -> 0.23.0 #24939

Merged
merged 1 commit into from May 1, 2017

Conversation

dtzWill
Copy link
Member

@dtzWill dtzWill commented Apr 15, 2017

Motivation for this change

Version bump, project I'm using wants bindgen 0.23.0.

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@dtzWill
Copy link
Member Author

dtzWill commented Apr 15, 2017

Build failure is on darwin, which looks to be timing out building rust. Not sure that rust works on darwin via nixpkgs anyway?

@amiloradovsky
Copy link

Maybe simply disable the MacOS port? i.e. set the platforms attribute to platforms.linux.

@dtzWill
Copy link
Member Author

dtzWill commented Apr 16, 2017

Actually maybe it's just that rust isn't built for darwin on Hydra?

Anyway, cc maintainer @Ralith .

While looking at this:

Should 'bindgen' be wrapped to set LIBCLANG_PATH if not already set? Not sure what makes the most sense here. Without this the resulting 'bindgen' binary can't be executed (even trying "bindgen --help").

Looks like the current version (0.22.1) has this problem, but not the version in 17.03 (0.19.1).

@Ralith
Copy link
Contributor

Ralith commented Apr 16, 2017

Weird, they must have switched to dlopen for some reason. A wrapper seems reasonable to me. I wouldn't bother trying to pass through an externally set LIBCLANG_PATH.

Note that, per the comment I left in default.nix, an ideal wrapper script would also inject $NIX_CFLAGS_COMPILE so includes work. It'd be great to fix that while you're at it. This is a little tricky (requires some argument parsing) because if the user passes -- ... explicitly, then the real binary needs to be invoked with -- $NIX_CFLAGS_COMPILE ... so as not to duplicate the -- and also avoid inadvertently clobbering flags.

@7c6f434c 7c6f434c merged commit 9a85799 into NixOS:master May 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants