-
Notifications
You must be signed in to change notification settings - Fork 87
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: add hasLibraries and hasIncludes #119
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good on principle. It looks a lot like the language.c module so maybe it's better to import that instead. @Mic92 also said that LD_LIBRARY_PATH means that the binary won't work outside of the devshell if I am not mistaken.
libraries = mkOption { | ||
type = types.listOf strOrPackage; | ||
default = [ ]; | ||
description = "Use this when another language dependens on a dynamic library"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo, but I still don't understand what this means.
description = "Use this when another language dependens on a dynamic library"; | |
description = "Use this when another language depends on a dynamic library"; |
What would be another language? Can you make an example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "another language" isn't really necessary (and a holdover from the equivalent C option), this should really be for any non-crate library dependencies (i.e. anything that would need pkg-config).
includes = mkOption { | ||
type = types.listOf strOrPackage; | ||
default = [ ]; | ||
description = "Rust dependencies from nixpkgs"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
description = "Rust dependencies from nixpkgs"; | |
description = "Dependencies on C headers to provided by nixpkgs"; |
}]; | ||
}] | ||
++ | ||
(lib.optionals hasLibraries [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually want to make the separation into libraries/includes? Would it not be easier to have just one package options that adds both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since includes were for C and specifically C_INCLUDE_PATH, I don't see how it's necessary to port that to the rust options.
prefix = "$DEVSHELL_DIR/include"; | ||
} | ||
{ | ||
name = "PKG_CONFIG_PATH"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't libraries also depend on PKG_CONFIG_PATH some time?
@Mic92 it's a copy/paste from https://github.com/numtide/devshell/blob/84f1493776f44960e329f21843ffad1686b6c7a3/extra/language/c.nix btw. |
Ok. Opened issue here: #120 |
Does it differ from using a "normal" nix-shell with With a "normal" nix-shell it can happen that a crate is linked against a lib that gets cleared by the gc. I have no idea if there's a solution for this. |
Oops, I just realized that PRs have stacked up. Is this PR still relevant? |
This PR is still relevant. Compilation on a rust project actually fails at the moment. |
alright, I tested on x86_darwin and couldn't reproduce the problem on a public repo. it took me quite a while to figure those out. I don't know exactly in which hook those are getting set. Inside the rustflags variable are stuff for the linker. So those could have been set into a wrapper for ld. The cflags could have been set in another wrapper. Not sure exactly which wrapper those are. If anyone has an idea, I'm happy to test things. |
Thanks for taking the time and test things. Are there any lessons to integrate back into the module? |
I did some testing on linux and had to add glibc to the rustflags (just mentioning). I quite like the api of this module, however I don't think I would implement it in this way. Let me try to work on this next week and make a PR. We can compare both approaches and discuss what to include and what not to include in the final solution. basically I would use RUSTFLAGS, CFLAGS, and PKG_CONFIG_PATH which are all the environment variables I needed. |
I just hit some linkers error on ubuntu, I see why those LD variables are important.
I tried adding (this is just for ubuntu, for darwin, the previous fixes where enough). |
so here is how I understand the situation. |
I'm not sure what to do next to tackle the linker problem. |
I have some small updates on this. On ubuntu I still run into a glibc compilation error no matter what I do. |
alright, I've got more news. what is needed here is the following
if that would work, I'm happy to make a PR. PS: the reason why it was working before is that it was using the clang already installed on my computer. As soon as I had clang_13 in my shell everything started breaking down without the above fixes). The other problem I had was that I had to bring some weird libs that I've never heard of before like |
Thanks for taking the time to untangle this mess. Yeah, a PR where eval is used on RUSTFLAGS and CFLAGS sounds good. |
See #56 (comment) maybe