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.
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.
matthiasbeyer
force-pushed
the
rust-workspace-support
branch
from
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 |
|
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 buildcommand may be called somewhere in the workingtree.
Because of this we need to make sure that we find the
Cargo.lockfileby 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.