New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 670338 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

GN project.json should provide VisualStudioWriter::GetNinjaTarget equivalent.

Project Member Reported by bunge...@chromium.org, Dec 1 2016

Issue description

For most target types, the 'outputs' array in the project.json states which ninja targets (as gn labels, root relative) should be built for the given gn target label. However, this is noticeably empty for 'source_set', 'group', and 'bundle_data' target types. In addition, it is somewhat annoying (from the perspective of project.json) that these are given as (root relative) gn labels instead of directly as (build relative) ninja targets (as 'source_outputs' array entries are). These 'outputs' values appear to be useful for extracting build artifacts, but less helpful when deciding what ninja target to run given a gn label.

Essentially, the information desired is the same as the msvs ide generator uses from VisualStudioWriter::GetNinjaTarget. For each gn target, simply list the (build relative) ninja target(s) to build. This information answers the question 'if I want to build this label, which ninja target do I build?', which is not always completely obvious.

It appears there are at least two ways to do this.

The first way is to just lift the restriction on 'outputs' and just write out the target_->dependency_output_file().AsASourceFile as the 'outputs' of 'source_set', 'group', and 'bundle_data' target types. This has the downside that these 'outputs' are not really user defined outputs, changing the meaning of 'outputs'. It also has the downside of needing to list the 'stamp' files as sources, when they really shouldn't ever be considered as such. On the other hand, this is very simple to implement.

The second is to add a new 'ninja_target' (name subject to bike shedding) output by TargetDescBuilder which directly has this information and can be requested separately. This is quite similar to 'source_outputs' which could equivalently be named 'source_ninja_targets' from what I can tell. Then 'copy' and 'action_foreach' targets could just list their stamp file in 'ninja_target' and provide 'source_outputs' for their sources (since they are, in effect, their own specialized mini toolchains).
 
Note that I'm willing to work on this myself, mostly because I'm writing a project manager for KDevelop which reads the project.json file directly. I have a patch for the 'first way' and it works ok, but after writing it I was filled with doubt about how much sense it actually made. Then I discovered what VisualStudioWriter::GetNinjaTarget was doing and realized that was the information I really wanted.

As stated in the report, it would also be nice to extend 'source_outputs' to 'copy' and 'action_foreach' targets so the code to do the expansion wouldn't need to be duplicated (though I suppose I could just write it). Not sure about that yet though, and it's much lower priority than knowing which ninja target to build.
I think this sounds reasonable. Please feel free to work on it if you like.
Status: Assigned (was: Untriaged)

Sign in to add a comment