https://bugs.kde.org/show_bug.cgi?id=373156
Bug ID: 373156
Summary: Allow build targets to be specified per project item.
Product: kdevelop
Version: 5.0.1
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: all build tools
Assignee: kdevelop-bugs-n...@kde.org
Reporter: bunge...@gmail.com
Target Milestone: ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
