proposal for new tool: `ninja -t compdb-targets`

64 views
Skip to first unread message

James Widman

unread,
Oct 1, 2024, 9:16:34 PM10/1/24
to ninja-build
 Hi all,

Eleven days ago, I adopted a PR from @csmoe (who adopted it from @lk-chen) that enhances the ninja tool `-t compdb` to accept a list of targets and produce a compilation database that contains commands required to build those targets (and *only* those commands), resulting in some nice improvements when using clangd, both in terms of LSP search results and performance.

Since then, there was some debate in the PR discussion about the syntactic form that this enhancement ought to take, and it just occurred to me that, if I follow the instructions in CONTRIBUTING.md, that conversation should probably happen here on the mailing list rather than in the PR.

The tl;dr is that i recommend that the PR should proceed with the implementation of a new tool that implements this feature, and that its syntax should look something like this:

ninja -t compdb-targets [-hx] t1 [t2...]

...where the -h and -x options work just as they do with the existing `compdb` tool, and where t1 (and the optional t2..tN) is the name of some target in the loaded `build.ninja` file.

The version of this feature currently implemented in the PR instead modifies the existing `compdb [rules]` tool to allow the use of a new pseudo-option, `--targets`, which allows you to specify a list of targets after the optional list of rules. (In this version, if you give `ninja -t compdb` a list of rules followed by a list of targets, the output will contain a list of commands for both those rules and targets, with duplicate commands removed.)

I recommend introducing `compdb-targets` as a new tool (and i recommend *against* adopting `--targets` as a new option for `-t compdb`) for the following reasons:

1. at this time, i do not see a use case for generating a compilation database that combines commands for both a set of targets and a set of rules. (The tool `compdb-targets` would accept only targets, not rules.)

2. the interface of `-t compdb-targets` is simpler & easier to teach than `-t compdb --targets [rules] [--targets targets]`

3. the design & implementation of `-t compdb-targets` is simpler than `-t compdb --targets [rules] [--targets targets]`.

4. in the case where someone actually needs a compile_commands.json with a merged set of commands for both rules & targets, they can use the `jq` utility to merge-and-deduplicate the outputs of two separate runs of ninja: one with `-t compdb rule [rules]`, and one with `-t compdb-targets target [targets]`; i wrote about this in the discussion for the PR:


At the end of the day, i'll be happy to implement either form and to have this PR merged, but i would definitely prefer the new tool rather than the new option (though i'm open to changing my mind if there's reason to think that the merge-commands-for-targets-and-rules case will be much more common than i thought).

Thoughts? Questions? Concerns? 

All feedback is welcome!

--James

David Turner

unread,
Oct 4, 2024, 3:18:10 PM10/4/24
to James Widman, ninja-build
Thanks James for the proposal.

I like simplicity. A new tool just for targets is fine. Another option is to use --targets as a switch to only support targets instead of rules in the current tool.
In both cases we avoid ambiguity, and keep both interface and implementation simple. In this case, I would say whatever is simpler to implement would be the way to go :-)



--
You received this message because you are subscribed to the Google Groups "ninja-build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ninja-build/6b6b9a84-7cfe-45e6-80c0-3cd69741127bn%40googlegroups.com.

James Widman

unread,
Oct 4, 2024, 7:59:16 PM10/4/24
to ninja-build
cool beans; thanks David!

I have updated the PR; it now implements `-t compdb-targets`.
Reply all
Reply to author
Forward
0 new messages