Subninja for build & rule commands

[Richard Geary]

Why are targets starting with "build" or "rule" global, not file scoped? When I use subninja, I was expecting these to be scoped to the file in which they're defined. Could I change this behaviour?

[Evan Martin]

On Mon, Aug 20, 2012 at 8:10 AM, Richard Geary <richar...@gmail.com> wrote:
> Why are targets starting with "build" or "rule" global, not file scoped?

The global-ity of rules is an an oversight -- it was quicker to
implement one map of names to rules than it would've been to implement
a tree of maps. It wouldn't be too hard to fix.

I'm not sure what you mean about "build", though. I think it's
necessary that all build edges contribute to one global view...?

> When I use subninja, I was expecting these to be scoped to the file in which
> they're defined. Could I change this behaviour?

Yes, please go ahead, or file a bug and I'll take care of it
eventually. There's even a TODO for it somewhere (maybe in gyp). The
pattern used in eval_env.h, with a map and a pointer to an enclosing
scope, would probably do the trick.

One subtlety is there are ninja commands like "-t rules" that claim to
list all the rules, which means we'll need to figure out how to print
rules with the same name in a non-confusing way. On the other hand
the code for that tool itself already has a comment about how its
output is bogus...

I think there's never been too much pressure for it because most
projects have one set of "global" rules (like the compiler) that get
well-known names and then the occasional subproject-specific rule
which can just have its name qualified with the project name (I think
that's what we did in gyp).

[Richard Geary]

I agree that build edges should be global, though I think ninja should suppress the duplicate warning if you specify exactly the same build edge twice? Or have an option to suppress it.

I'll look at fixing it for build rules, should have something in the next week or two.

[Evan Martin]

On Tue, Aug 21, 2012 at 6:38 AM, Richard Geary <richar...@gmail.com> wrote:
> I agree that build edges should be global, though I think ninja should
> suppress the duplicate warning if you specify exactly the same build edge
> twice? Or have an option to suppress it.

Can you give an example of where this comes up? I haven't run into it
before and I'd like to understand.

[Richard Geary]

Sure! Our build has 100's of projects in separate git repos, a subset is selected & fetched with git submodule. Ideally I would like to build either the full super-repo or the local submodule repo (depending on the current working directory that you invoke ninja from).  The submodules have dependencies on each other, so I was intending to use submodule to include the required build.ninja files. I'm generating the ninja files using Premake (w.i.p.)

The current problem is ninja expects me to define my toolset rules just once, so I can't do it at the top of each ninja file. The obvious answer would be to move the build edges to a different file and subninja that instead, however it's possible each project may have slightly different toolsets (& thus different rules), so I would still need to include the rule set for that dependant project. I can't do this and prevent name conflicts. Having subninja forget the file's rules after the file ends would fix it. The alternative solution is a lookup check when you invoke include/subninja so each .ninja file is only included once, but that might incur an unwanted performance hit.

[Nicolas Desprès]

On Mon, Aug 20, 2012 at 7:38 PM, Evan Martin <mar...@danga.com> wrote:

On Mon, Aug 20, 2012 at 8:10 AM, Richard Geary <richar...@gmail.com> wrote:
> Why are targets starting with "build" or "rule" global, not file scoped?

The global-ity of rules is an an oversight -- it was quicker to
implement one map of names to rules than it would've been to implement
a tree of maps.  It wouldn't be too hard to fix.

I'm not sure what you mean about "build", though.  I think it's
necessary that all build edges contribute to one global view...?

> When I use subninja, I was expecting these to be scoped to the file in which
> they're defined. Could I change this behaviour?

Yes, please go ahead, or file a bug and I'll take care of it
eventually.  There's even a TODO for it somewhere (maybe in gyp).  The
pattern used in eval_env.h, with a map and a pointer to an enclosing
scope, would probably do the trick.

One subtlety is there are ninja commands like "-t rules" that claim to
list all the rules, which means we'll need to figure out how to print
rules with the same name in a non-confusing way.  On the other hand
the code for that tool itself already has a comment about how its
output is bogus...

To anser to the comment. This command is useful for shell completion purpose when a command expect a rule name in as argument like "-t clean -r cxx".

 

I think there's never been too much pressure for it because most
projects have one set of "global" rules (like the compiler) that get
well-known names and then the occasional subproject-specific rule
which can just have its name qualified with the project name (I think
that's what we did in gyp).

--
Nicolas Desprès