We'll need to think about UI here. The reason I originally did it like this is that I was concerned that people wanting to look at the deps of a target might get confused looking at only one section, or that "gn desc //foo deps" doesn't actually tell you all the deps of foo.

We'll have to make sure the messaging and defaults here are clear.

With the caveat that my understanding of how GN works may be too simplistic, there are functionally two things here: the set of tagets that the current target depends on (this is deps + public_deps, IOW what gn desc currently reports as "deps"), and the set of tagets whose public files the current target makes available to its clients in addition to its own public files (this is public_deps, which gn desc currently doesn't report on).

Would it make sense for gn desc to report the public_deps simply as "public_deps", and keep its reporting on "deps" unchanged (which I guess is highly desirable for compatibility reasons?)?

Here's what I think:

1.

Add public_deps and data_deps to the "what to print" possible args for "desc" so you can ask explicitly: "gn desc out/Debug //base public_deps". We will need to work out what "--all" and "--tree" do for these cases and I think the answer is different for both:

public_deps: --tree and --all should recursively walk only public dependencies. This will allow you to reconstruct everything a target is exposing to ones that depend on it.

data_deps: --tree and --all should follow data deps at the first layer, and then follow all public/private/data deps for the recursive steps. This will give the set of things that will built for data deps.

2.

- For the summary (no "what to print" specified), we should split out data_deps into a separate section no matter what.

- For --format=json we should probably always split out public_deps, deps, and data_deps. People use this for exporting data and scripts will need to know.

- For human format, I'm thinking we should display one deps section like we do today, but annotate each one with a dark gray "[public]" or "[private]" just like "gn path" does. I'm hoping this will minimize confusion for people tracking down dependencies on a target.

sounds reasonable.

We had a similar discussion on https://groups.google.com/a/chromium.org/forum/#!topic/gn-dev/sOxIIfDOMNo back in May and I created https://codereview.chromium.org/2880093002 to implement Brett's advice but I ended up being stuck in other tasks with an higher priority but I would like to finish this.

Let me port the CL to Gerrit so we can see what it is missing and we can hopefully land it.

Ok, I moved the CL to Gerrit: https://chromium-review.googlesource.com/c/chromium/src/+/708740.

I don't have time to look into this right away but it is back on my radar. I will get back to this during the week or at the beginning of the next one.

Brett: don't lose time reading the CL since it is the same CL you have already reviewed. I will see what is missing and I will ping you when I will be ready. Thanks.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot