This commit fixes a bug introduced in #276 where symlinked Cargo.tomls
wouldn't get detected due to readDir() reporting them as - well -
_symlinks_ instead of regular files.
Note that we continue to keep the `if type == "directory"` condition for
recursion which means that we'll fail to detect "nested" Cargo.tomls if
someone decides to go wild and create workspace with symlinked crates.
That I'm not 100% sure on how to approach, but fortunately cases like
those seem to be practically non-existent (and Crane apparently not
supporting them builds a bit of confidence here as well).
Closes#280.
Our current Cargo.toml discovery algorithm is based on reading the main
Cargo.toml and looking at its `workspace.members` - unfortunately, as it
turns out there's actually no requirement for all workspace crates to be
listed there, and some applications do fancy things like:
```toml
[workspace]
members = [ "crates/foo" ]
[dependencies]
foo = { path = "crates/foo" }
bar = { path = "crates/bar" } # whoopsie
```
... which doesn't play nice with Naersk's incremental builds (that is,
the compilation fails unless `singleStep = true;` is turned on).
This commit changes the logic to use a different approach: now we simply
recursively scan the root directory, noting down all the Cargo.tomls we
find; Crane seems to use the same algorithm.
I think the only case where this approach falls short are spurious
Cargo.tomls that are present somewhere in the source directory but are
actually unused - for instance, imagine I'm writing a Cargo clone where
I've got files like `src/tests/broken-manifest/Cargo.toml` - in cases
like these, the current approach will cause the build to fail, because
we will try to fixup a broken Cargo.toml, thinking it's used somewhere.
We could try to handle cases like these by using an even different
approach: instead of traversing the source tree, we could load the main
Cargo.toml and traverse its `workspace.members` + all path-based
dependencies recursively, noting down all the *explicitly present*
Cargo.tomls.
That is, given a top-level manifest of:
```
[workspace]
members = [ "crates/foo" ]
[dependencies]
foo = { path = "crates/foo" }
bar = { path = "crates/bar" }
```
... we'd note down and load `crates/foo/Cargo.toml` +
`crates/bar/Cargo.toml`, and then load _their_ path-based dependencies,
to find all transitive Cargo.tomls that belong to this workspace.
(that is, we have to scan the crates recursively, because `bar` might
depend on `crates/zar` - and that's not an imaginary edge case, that's
actually what happens inside Nushell, for instance.)
I don't have enough time to implement this more extensive approach now,
and IMO the improvement presented here is still an improvement, so I
think it's safe to go with the new-but-still-subpar approach here and
consider the better algorithm in the future :-)
# Testing
All tests pass, I've also made sure that incremental builds are still
incremental.
Closes https://github.com/nix-community/naersk/issues/274
During compilation, we build two derivations - one for the dependencies
and another for the user's crate itself. Passing `postInstall` to
`buildPackage` pass-throughs it into both derivations, which is not what
most users would probably expect.
This commit adds `postInstall` as an explicit configuration option (so
that it's neatly documented), zeroing it out for the dependencies-only
derivation.
I don't think there's any use case for something like `postInstallDeps`,
so it's not introduced here.
Closes https://github.com/nix-community/naersk/issues/237
From what I can tell the readme test is failing because the config.nix differs from the README.md source
To regenerate the README, run:
```sh
./script/gen
```
and commit the results.
This reverts commit f9e6e8dd78. We should
`export CARGO_TARGET_DIR`, otherwise subsequent `cargo` calls will
rebuild everything (because they won't find the target dir).
Using rust as library provider requires us to collect the
libraries (shared and static) to link against.
Ideally we'd also copy headers, but I didn't find those yet.
Fixes#104
