michaelforney / samurai

ninja-compatible build tool written in C

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support for samu -t compdb

ddevault opened this issue · comments

This is required for GNOME Builder to work. Alpine Linux has run into this problem during our migration from ninja to samurai, and we'll have to roll back the migration if it's not available.

compdb specification

ninja implementation

Are there any other tools that samurai is missing that ninja has?

Yes. Not all of them are relevant, but some are:

[3:53:02] homura ~ $ ninja -t list
ninja subtools:
    browse  browse dependency graph in a web browser
     clean  clean built files
  commands  list all commands required to rebuild given targets
      deps  show dependencies stored in the deps log
     graph  output graphviz dot file for targets
     query  show inputs/outputs for a path
   targets  list targets by their rule or depth in the DAG
    compdb  dump JSON compilation database to stdout
 recompact  recompacts ninja-internal data structures

I would argue that commands, deps, graph, query, targets, and compdb are necessary to consider samurai a complete ninja replacement.

We reckon that compdb and query would be sufficient for Alpine's purposes.

I suspect that compdb is all we need immediately, but query is likely needed as well. This change is breaking certain IDEs (GNOME Builder for example), and we will have to revert soon if there is not a fix.

Implemented now. Please test with GNOME Builder and let me know if it works as expected.

Based on some quick testing, it appears to be generating a valid compdb. Thanks!

This is awesome! Thanks for the quick fix!

Doesn't seem to work:

compile_commands.json is not a flatpak manifest, skipping: :6:67: Parse error: unexpected character ,', expected character ]'

Here's the file: https://gist.github.com/bcee62e546cbc6a9f1c912b48517e608

Produced with the latest gnome-software ( e668f6be33b23dfe311a23a93bbaebcfadfb8310 )

As @Cogitri commented on the commit, the issue is the trailing comma. This is now fixed in fe1b3ce.

The rest of the diff is not concerning. It just has a different ordering than ninja's output.

I was trying to figure out at first why I got a compilation database printed out when running ninja -t compdb, but the new release of samurai just printed out

[
]

Turns out if you use it via e.g. meson it will run samu -t compdb c_COMPILER_FOR_BUILD c_PCH_FOR_BUILD c_COMPILER c_PCH which works, but just samu -t compdb doesn't emulate the ninja behavior of printing everything (including e.g. CUSTOM_COMMAND rules).

Docs are inconsistent.

$ ninja -t compdb -h
usage: ninja -t compdb [options] [rules]

rules are optional here

$ samu -t compdb -h
usage: samu ... -t compdb [-x] rules...

rules are not optional, fair enough if this is a deliberate decision, but...

$ man samu
[...]
     samu [-C dir] [-f buildfile] -t compdb [-x] [rule...]
[...]

rules are optional again??? The manpage incorrectly states that samu will behave the way ninja does.

Looks like this behavior changed in ninja 1.10. samurai currently matches ninja 1.9 behavior.

The rules are optional; you get an empty compilation database, not an error. The usage message is fixed now.

rules are optional again??? The manpage incorrectly states that samu will behave the way ninja does.

The manual states that a compilation database is printed, not that specifying no rules means that all rules should be printed, so I'm not sure what you mean here.

Well, that's not optional, that is mandatory and passing the empty set as the set of rules to print. :p

Thanks for pointing out the ninja behavior, I was just looking at whatever archlinux currently provides.

I guess it is up to you to decide whether to implement this ninja 1.10 behavior. Since most users will probably be using it via a build system specifying the rules they want, it is probably okay as-is, albeit slightly surprising.
EDIT: to be clear, it is ninja 1.9 that is surprising here.

(And now, I will go release my 1.1 update to archlinux [community].)

I guess it is up to you to decide whether to implement this ninja 1.10 behavior. Since most users will probably be using it via a build system specifying the rules they want, it is probably okay as-is, albeit slightly surprising.

ninja worked this way for 7 years, so I don't think it is too surprising, especially since samurai only claims to implement ninja 1.9 behavior.

The ninja 1.10 behavior will be implemented with the rest of the features required (mainly dyndep), probably for the next release. If you want the behavior changed now, feel free to send a patch.