Introducing interface_deps to GN

[Matt Stark]

GN currently has two types of dependencies.

• Deps is the equivalent of bazel's implementation_deps
• It can be thought of as "the dependencies required to compile the implementation"
• public_deps serves multiple purposes
• It should contain any dependencies required to compile the interface
• This has mostly been a non-issue in the past, for two reasons:
• You don't compile the interface (since it's header files). However, with modules, this is no longer true and thus many of the deps must become public_deps.
• Scandeps is additive. However, I'm working on adding header tracking to scandeps, which will allow us to do the more correct thing of subtraction. This will solve a class of bugs where we have missing inputs during remote execution due to scheduling issues.
• But it also re-exports those dependencies, so you are suddenly allowed to #include files from those dependencies without checking

I propose adding a new field interface_deps. It simply says "this is the dependencies of the interface". It does not re-export said dependencies.

--

Thanks, Matt.

[Roland McGrath]

Can you be more precise on the semantics you have in mind?

public_deps has multiple effects compared to deps:

• public_configs are propagated
• other public_deps are propagated
• the outputs considered proper to use as inputs are propagated
• gn check I guess behaves differently

 AFAICT you only mentioned the change in gn check behavior.  Do you mean that all other aspects of public_deps semantics remain the same in implementation_deps?

Also, GN has data_deps and validations that should IMHO be understood as among the four kinds of dependencies, not just two.  (I think it's reasonable to say that gen_deps do not count as a kind of dependency.  It's perhaps arguable that validations don't count either because they don't engender circularity.)

[Matt Stark]

Can you be more precise on the semantics you have in mind?

The semantics are the same as public_deps, with the only difference being that `gn check` will allow you to #include everything in the transitive closure over public_deps.

Thus, attempting to #include something from an interface_dep will result in gn check failing

Similarly, attempting to #include something from an interface dep's public_deps will also result in GN check failing.

 AFAICT you only mentioned the change in gn check behavior.  Do you mean that all other aspects of public_deps semantics remain the same in implementation_deps?

That's correct, yes.

Also, GN has data_deps and validations that should IMHO be understood as among the four kinds of dependencies, not just two.  (I think it's reasonable to say that gen_deps do not count as a kind of dependency.  It's perhaps arguable that validations don't count either because they don't engender circularity.)

Sure, though that fact isn't particularly relevant to this proposal. 

--

Thanks, Matt.

[Roland McGrath]

Off hand I think this might be what I'd want for all of my uses of public_deps.  I'm not actually sure what a case might look like where you didn't want that gn check behavior.  So perhaps we can just change the check behavior, and add a .gn (dotfile) setting for backward-compatible roll-out of the new behavior.

Hmm, I guess I do know a case.  That is the generic "redirector group" case.  But it still seems like implementation_deps is actually the "usual" case for public_deps.  So I wonder if we might want to change the names around so the stricter checking is what public_deps means and there's a new spelling for the actually-weirder case where you really do want gn check to treat it as the same.  Probably not worth the churn, though certainly there will be many (I'm guessing a majority) of existing public_deps uses in the world that really ought to be implementation_deps.

Anyway, I'm certainly in favor of having a way to get this gn check behavior if it's not further complicating the rest of the (already arcane) propagation semantics.

[Matt Stark]

Off hand I think this might be what I'd want for all of my uses of public_deps.  I'm not actually sure what a case might look like where you didn't want that gn check behavior.  So perhaps we can just change the check behavior, and add a .gn (dotfile) setting for backward-compatible roll-out of the new behavior.

I agree, backwards compatibility was my main concern here, and the reason I didn't propose just changing public_deps.

 

Hmm, I guess I do know a case.  That is the generic "redirector group" case.  But it still seems like implementation_deps is actually the "usual" case for public_deps.  So I wonder if we might want to change the names around so the stricter checking is what public_deps means and there's a new spelling for the actually-weirder case where you really do want gn check to treat it as the same.  Probably not worth the churn, though certainly there will be many (I'm guessing a majority) of existing public_deps uses in the world that really ought to be implementation_deps.

How would you feel about an `exports_deps = false` field that you could set on all targets (name open to suggestions)? That would allow us to:

• Support those niche use cases where we do want that
• Support incremental migration to the new format
• Via a template in BUILDCONFIG.gn, set the default at a global level

It'd be much easier to implement than implementation_deps.

--

Thanks, Matt.

[Roland McGrath]

Precedent for variables affecting check are `check_includes` and `allow_circular_includes_from`.  I think having `check` and/or `includes` in the name would be best.

One possibility would be `allow_includes_to = [subset of public_deps]` where the default (current) behavior is not something you can spell generically (it's just `= public_deps` if you know what they are), and `= []` is the full-on "newly strict" behavior.  But it also allow the middle ground that putting some things in public_deps and others in implementation_deps would.  I don't know if that is as hard to implement as implementation_deps.  You could also invert the sense and call it `check_includes_from` or something like that.

But I think I'd also be fine with a Boolean.

[Sylvain Defresne]

I'm in favor of a change to improve `gn check` so that it does not automatically allow #include from public_deps.

I think the `export_deps` boolean could work and would probably be simpler than replicating all the special rules for public_deps (e.g. I think you've forgot to include the fact that public_deps are also considered hard deps, which is important for action generating headers).

-- Sylvain

[Matt Stark]

Thanks for all the feedback, everyone. The feature should probably be available within the next week or so (if you care, here's the CL).

I've named it check_includes_strict for consistency with the existing check_includes flag, because I realized when writing the CL that it should also prevent you from including your own private deps from your public headers, which none of the existing names we'd discussed covered.

--

Thanks, Matt.

[Roland McGrath]

That sounds great.  We might also consider a dotfile setting to change the default for `check_includes_strict` in targets that don't explicitly set it to either true or false.