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

unconditionally generate lockfile #53

Closed
japaric opened this issue Jan 11, 2017 · 9 comments
Closed

unconditionally generate lockfile #53

japaric opened this issue Jan 11, 2017 · 9 comments

Comments

@japaric
Copy link
Contributor

japaric commented Jan 11, 2017

Right now, something like this produces an error:

$ cargo add foo
$ cross build
error: failed to write /project/Cargo.lock

Caused by:
  failed to open: /project/Cargo.lock
@Emilgardis
Copy link
Member

There doesn't seem to be a way to replicate cargo build when it adds new deps. Closest match is cargo update, but that can also update deps.

@japaric
Copy link
Contributor Author

japaric commented Jan 12, 2017

cargo generate-lockfile does the trick, I think, if you call it before cross build. I don't think it updates dependencies; it just adds new dependencies and changes their paths/git urls if necessary.

@tbu-
Copy link
Contributor

tbu- commented Feb 4, 2017

Looks like this was fixed in 0.1.5.

@japaric japaric closed this as completed Feb 4, 2017
@Arzte
Copy link

Arzte commented Feb 23, 2017

I'm still seeing this issue, using the latest version. Here's a log https://travis-ci.org/mgattozzi/alchemist/jobs/204565275#L524

@Emilgardis
Copy link
Member

Emilgardis commented Feb 23, 2017

You should let cross do it with cross build/run, with cross generate-lockfile you are telling cargo to generate a lockfile inside the read-only docker image.

@Arzte
Copy link

Arzte commented Feb 23, 2017

The error still shows up with that not there, I added it to test if it would help, I'll remove it and try again though...
https://travis-ci.org/mgattozzi/alchemist/jobs/204644806#L524

@Emilgardis
Copy link
Member

Emilgardis commented Feb 23, 2017

I think #67 is the cause, cargo fetch is run, but somehow cargo still complains. I think we need to run cargo fetch --target <target-triple> [...] to make this work. Not sure.

This issue should be reopened.

@japaric
Copy link
Contributor Author

japaric commented Feb 23, 2017

OK. I think I found the problem. This is a workspace so cargo fetch is producing a Cargo.lock in the root of the workspace but when you call cd alchemist && cross build --target $T, Cargo tries to create a new Cargo.lock in that directory.

Using cross build --target $T -p alchemist from the root of the repository seems to at least produce / use the right Cargo.lock and starts the build process (then it fails to link with /usr/bin/ld: cannot find -lsqlite3 but that's a totally different problem)

@Arzte
Copy link

Arzte commented Feb 23, 2017

Its looking for sqlite3 since that (for the moment) is the database we are using for alchemist.
So this should be fine if we just use -p whicheverproject is getting built then?

oconnor663 added a commit to oconnor663/blake2_simd that referenced this issue May 21, 2019
`cross` runs tests on a read-only version of the project, so it makes sure to
generate the Cargo.lock file on the host before it does that. However, the
--manifest-path flag confuses it, and it puts the lockfile in the wrong place,
and the subsequent container build crashes with a permissions error.

Similar issue: cross-rs/cross#53
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

No branches or pull requests

4 participants