KDevelop4 BuildManager/BuildTools

[Alexander Neundorf]

On Sunday 21 January 2007 05:20, Andreas Pakulat wrote:
> 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.

Can you please explain where you see the problem ?

> 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). 

I think if QMake doesn't support this but the user needs it, he shouldn't use 
QMake.

> 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.

Yes, this would probably only lead to problems.

> 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).

I think MSVC6 and other Windows IDEs have a similar functions, there you can 
also setup pre- and post build tasks.
I wouldn't do this, as pointed out above. 
If the buildtool (qmake) isn't able to do something, the user should use 
another buildtool, which is able to do it (autotools or cmake or ...)
If we would introduce this in kdevelop, how would the project be built 
manually ?

$ qmake
... run some scripts
$ make
... run some more scripts 

?

This feels a bit like implementing part of the buildsystem in KDevelop, which 
I think we shouldn't do, because then it might happen that the software can 
only be built with kdevelop.

Another note:
we discussed at akademy how to integrate CMake support in KDevelop.
The idea was to make it as easy as possible for the user and if possible 
provide a GUI that the user doesn't have to enter cmake commands.

I thought about this for a long time now.
I don't think it is possible and I'm not sure we should even try to do this. 
For instance what should the user do if he wants to link to some library, 
e.g. libxml2.so ?
Before I make up ideas how not to do it, I better ask: what's the plan how 
this should be done for QMake, CMake, autotools ?

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net