KDevelop4 BuildManager/BuildTools

Andreas Pakulat apaku at gmx.de
Sun Jan 21 04:20:28 UTC 2007


Hi,

after some discussion with Alex about the Extension-Interfaces in
kdevelop4 and the recent thread about buildtool-chaining I thought about
pros/cons of different approaches.

Lets first look at what we have:

ProjectManager
    our User interface which works on a
    model of project items (files, folders, targets at the
    moment)

BuildManager
    this is the interface that is to be implemented to
    support build systems like QMake, CMake, Automake, ...

FileManager
    this is a more basic interface, which could probably be
    used for project types that don't have a build-system,
    like script projects

ProjectBuilder
    this one does the "dirty" work, currently there's only
    the Make implementation which runs only make

So, one thing that stands for discussion is how to handle our
cmake/qmake/automake buildmanagers. One way as mattr said would be that
those know how to execute their specific tools and would do that
whenever needed. The real build process would thus not include this
pre-process step and I'm not sure this would integrate very well with a
job-driven approach.

Another way would be that the buildmanager has a list of projectbuilders
that need to be run, so we'd have a QMake builder and a make builder as
default list for the QMake buildmanager. This would also allow the user
to add other builders to the list (if we provide Ui for this) and thus
allows for running stuff like XML validation or parser generation tools
(a QMake project has not real hooks to do such things before
compilation). The problem here is that users might come to think they
can use a QMake project and add their favourite CMake based subproject
to it. This would be a bad thing IMHO.

So the third approach, which came to my mind right before I fell asleep
(and thats why this mail is written so late): We stay with the
projectbuilders but let the user add simple custom commands that should
be run before or after the actual build. Then a QMake builder would
first run the custom commands and afterwards start the real build (which
includes running a Make builder).

With either way of doing the extensions I think the last approach is the
best one, it allows some customization of the build process for easier
project types (like QMake or script projects) but still allows us to
have control over the general project buildsystem.

Any ideas,comments,notes welcome.

Andreas

-- 
You will be Told about it Tomorrow.  Go Home and Prepare Thyself.




More information about the KDevelop-devel mailing list