Please add Cargo.lock to .gitignore about gameboy

[ethanpailes]

@eduardossampaio The typical pattern with cargo files is to check in Cargo.toml for libraries and checkin in both Cargo.toml and Cargo.lock for applications. Cargo.toml expresses the constraints you believe to describe the deps that work with the project which is good when you have a unknown number of consumers using your packages with their own dep constraints, while Cargo.lock describes a list of actual deps which is good when you want stability. Applications don't have any downstream consumers, so Cargo.lock should be checked in.

If deleting Cargo.lock fixed the build for you, your compiler version might be out of date with the project or there could just be a bug in the Cargo.lock file that needs to be fixed. Perhaps you could post the diff between the Cargo.lock that gets generated after you blow away the old one and the one that is checked in. That might show the issue.

[yazgoo]

As mentioned by @ethanpailes, Cargo.lock should be kept, I think this issue can be closed (my 2 cts :) )

[mohanson]

The development spec I understand is that bin needs check-in Cargo.lock, See:

rust-lang/cargo#315 (comment)

[eduardossampaio]

That is correct, but Cargo.lock is a generated file by build at first time. I'm suggesting to ignore it because build fails after I clone the project. The error disapeared after I delete the Cargo.lock file.

[namibj]

That is correct, but Cargo.lock is a generated file by build at first time. I'm suggesting to ignore it because build fails after I clone the project. The error disapeared after I delete the Cargo.lock file.

The problem is, that there is zero guarantee that cargo will be able to generate a working Cargo.lock file in the future. This is very pronounced with pre-1.0 crates and git-branch-references, as both aren't claiming any stability via SemVer.