guppy for diem/diem is ran differently, should we allow peeps to customize how guppy is run for their repo?

[mimoo]

The repo diem/diem is really particular in the way we have to analyze its dependencies. It only supports x86_64-unknown-linux-gnu so we need to check dependencies that are pulled when building with this triplet, it also does two other things when we build: it ignores the diem-workspace-hack package and it uses the v2 cargo resolver instead of the default one.

So the question is: should we allow peeps to customize how guppy is run on a repo when adding one?

[mimoo]

the V2 resolver is used for all the builds in docker files (via -Z flag, not via cargo x build)

https://github.com/diem/diem/blob/18b6a51aff5f44fca19f0743672e708ace423a7c/docker/build-common.sh#L14 + https://github.com/diem/diem/blob/18b6a51aff/cargo-flags

the cargo x build is only used in dev I believe?

the workspace-hack is disabled here: https://github.com/diem/diem/blob/18b6a51aff5f44fca19f0743672e708ace423a7c/docker/build-common.sh#L21

[mimoo]

that's what cargo x generate-workspace-hack --mode disable does:

[mimoo]

OK, the quickest way to resolve this issue is to continue to call the command line cargo x generate-summaries when we deal with diem/diem, and use the normal way when we deal with another repo.

In the future it'd be good to allow people to customize how guppy is called (for example if in release they use specific features, or a specific target)

[mimoo]

this would actually still be useful for custody (cc @jnaulty ) as they probably build for powerpc as target

[mimoo]

(from Rain's presentation)

[mimoo]

OK so I will re-integrate cargo guppy so that we can run it on diem/diem for now, and at some point we'll have to implement a customizable guppy CargoSet run:

create a CargoSet for a given host/target triplet, a given set of initial features, a set of crates I want to ignore (for example testsuite, or workspace-hack), and obtain all the relevant dependencies from that