Follow-up Comment #9, bug#64571 (group make):
I had a thought about how this could be approached in a different way.
As has been mentioned, we already have a lot of information available about
targets (also variables and other info) via the `--print-data-base` flag. It's
just that as it currently exists this information is output in a bespoke,
human-readable format defined by `make`.
```
...
# Files
...
example: dep
# Phony target (prerequisite of .PHONY).
# Implicit rule search has not been done.
# File does not exist.
# File has not been updated.
# commands to execute (from `Makefile', line 16):
...
```
This has lead to the many "regex" based, "hacky solutions" that currently
exist as people manipulate this output as best they can.
Could we instead add an option to print the database in JSON (and/or another
structured format), so that the querying can be done using existing tools for
manipulating said format, i.e. `jq` for JSON.
More UNIX-y than trying to guess what a sensible default would be for the new
option. It can print everything that's in the current `--print-data-base`
option, just in a new format that users can query better.
E.g. assuming a `--print-data-base-json` output for the example above of
something like
```
{
...
"files": [
{
"target": "example",
"prerequisites": [
"dep"
],
"is_target": true,
"phony": true,
...
},
...
],
...
}
```
You could get phony targets with `make -pq | jq '.files[] | select(.phony ==
true) | .target'`. The `jq` query language can be a little enigmatic for
longer queries, but I would argue it's more readable than regex. Also, the
structured natured of the output would give users more confidence that they're
actually getting everything that they're querying for, and haven't missed
something just because they're not familiar with the current bespoke format of
`--print-data-base`.
For your use case @timmmm, you'd do something like `make -pq | jq '.files[] |
select(.is_target == true) | .target'` to get all the things that are actual
targets. And not just prerequisites or implicit rules, etc.
The structure of the output and the names of the properties could follow what
already exists in the `print_data_base` function:
```
print_variable_data_base ();
print_dir_data_base ();
print_rule_data_base ();
print_file_data_base ();
print_vpath_data_base ();
strcache_print_stats ("#");
```
e.g.
```
{
"variables: [...],
"directories": [...],
"rules": [...],
"files": [...],
"vpath": [...],
"stats": [...]
}
```
>From looking at the source code, it seems that "rules" are actually only
implicit rules, and other user defined targets and prerequisites always appear
in "files". Can you confirm that @psmith?
Thoughts? I'm happy to put some time into getting an example working for
further discussion if there's enough interest in the approach?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64571>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
