Bug 373156

I'm currently creating a IBuildSystemManager for GN project.json files. See https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/reference.md#Generic-JSON-Output for some details (this is the build system being used by Chromium). Because GN supports multiple toolchains in a single build it is not possible to always create phony rules with the expected names, so the only way to ensure that one is building the correct thing is to use the full non-phony ninja target name when building.

One of the issues I'm running into because of this is that the current ninja builder (like the other builders) really wants to use the 'text()' or 'path()' of project items directly as ninja targets to use. This can be exceedingly awkward since full non-phony target names must be used as the user visible names in the project view and makes it basically impossible to build source files (the UI doesn't directly allow it, but adding them to the 'Build Sequence' works, but then the file path isn't what ninja expects because it's been made absolute).

It would be much more flexible if the IBuildSystemManager had two additional methods like

bool IBuildSystemManager::isBuildable(KDevelop::ProjectBaseItem* item)

which would return 'true' if the UI should allow building this item (and it could return true for ProjectFileItems in particular). Then

QSet<QString> IBuildSystemManager::buildTargets(KDevelop::ProjectBaseItem* item)

which would actually calculate and return which targets should be built for the given item. This approach isn't very different from how IBuildSystemManager::includeDirectories and IBuildSystemManager::defines currently work except for actual building instead of parsing.

The alternative of putting the target names on the items themselves seems a bit iffy, since the items themselves shouldn't necessarily know which builder they're building with. Presumably the IBuildSystemManager should be the only one who knows which build system is being used. This also would somewhat preclude lower level items from actually building parent items if that's the only realistic way to do so. (Also like includes and defines not being on the items themselves.)

My current work arounds are to create a rather ugly project model (with rather strange trade offs) or copy-paste the ninja builder into a new builder plugin just to replace kdevninjabuilderplugin.cpp#argumentsForItem to provide the answers I already have from the project.json file gn created.

I'm willing to work on this issue, but before starting it would be nice to know if this would be a generally acceptable approach or if some other approach would be better.