-
-
Notifications
You must be signed in to change notification settings - Fork 14k
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 build support: Find Cargo.lock file upwards in tree #30412
Conversation
Sadly I do not know how to test this properly... maybe someone can suggest something? |
if [ -f "$1/$2" ]; then | ||
echo "$1/$2" | ||
else | ||
func "../$1" "$2" |
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.
this should be find_upwards
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.
whops,... copy pasted in my test script and forgot to rename :-/
Cargo, the build tool for the rust ecosystem, provides a feature named "workspaces". In workspaces, multiple library- and binary-crates can be bundled together in one repository/project. The workspace functionality also provides functionality where dependencies are built once for several crates in the workspace. Thus the "Cargo.lock" file (as well as the ./target folder where the final binary lives) are placed in the top-level directory of the repository, while the `cargo build` command may be called somewhere in the working tree. Because of this we need to make sure that we find the `Cargo.lock` file by not only searching the current directory but also the directories above the `${sourceRoot}`. This change introduces a little helper to walk up the file tree and check for a file, starting with the current directory.
2cb6add
to
06279b4
Compare
Still don't know how I could test this... doing
does not work as intended... or I'm doing something wrong. |
So there is still an explicit check for Cargo.lock in the current directory. But I suspect if it was removed things would still work. If possible I would like to leave the directory-finding to the tools of choice as opposed to writing out own. I would appreciate if you could try out the current head, and try removing the checks. Just make sure that we still required locked packages somewhere. |
Thanks for the fast reply. I'd love to test this out, though I have to admit I don't know how. Testing the rust infrastructure has been a pain before. Could you point me into the right direction, please? |
It should be as simple as selecting a package that is built using the rust infrastructure and trying to build it. You can then make a change and build again. Something like the following from nixpkgs root (I don't have a computer to test) nix-build -A alacritty |
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.
Fixes to merge conflict
Invalidated by 5f8cf00 |
@matthiasbeyer: Why does 5f8cf00 invalidate this very pull request? |
In fetchcargo.nix we still check whether |
I reapplied this patch in matthiasbeyer@dd5381a but I cannot test it. As far as I remember, the changes to the rust build infrastructure from 5f8cf00 solved this issue... but I'm not sure. |
Cargo, the build tool for the rust ecosystem, provides a feature named
"workspaces". In workspaces, multiple library- and binary-crates can be
bundled together in one repository/project.
The workspace functionality also provides functionality where
dependencies are built once for several crates in the workspace. Thus
the "Cargo.lock" file (as well as the ./target folder where the final
binary lives) are placed in the top-level directory of the repository,
while the
cargo build
command may be called somewhere in the workingtree.
Because of this we need to make sure that we find the
Cargo.lock
fileby not only searching the current directory but also the directories
above the
${sourceRoot}
.This change introduces a little helper to walk up the file tree and
check for a file, starting with the current directory.
This is not tested at all and only a proposal. @Mic92 and I discussed what needs to be done for this to work in #29981 and this is my first proposal.
The helper function does not yet stop at
/nix/store/<dir>
, though.