KDevelop4 BuildManager/BuildTools

[Andreas Pakulat]

On 21.01.07 11:46:36, Alexander Neundorf wrote:
> On Sunday 21 January 2007 05:20, Andreas Pakulat wrote:
> > 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 ?

Because the BuildManager has no "build"-API (i.e. no build() method and
no signals to indicate failed/success), and it shouldn't have. This is
part of the ProjectBuilder API. I don't know what mattr has planned for
how to run the ProjectBuilder's, but given the fact that the builder can
be queried from the buildmanager I suspect the build is started by some
"other" component (like the projectmanager).

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

So somebody with a medium sized project who suddenly needs to run an XML
validator or parser generator should start all over with the
buildsystem? I don't see this happen, kdevelop should provide some
convenience here.

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

But then he might have to switch buildsystem in the middle of
development. Some things you can't foresee and I think kdevelop can help
out in these cases...

> If we would introduce this in kdevelop, how would the project be built 
> manually ?
>
> $ qmake
> ... run some scripts
> $ make
> ... run some more scripts 

The user has to run his scripts on his own, right.

> This feels a bit like implementing part of the buildsystem in KDevelop,

No, I don't want that, for sure. All I want is a way to execute
commands around the actual buildsystem building to help people who chose
the "wrong" buildsystem (or were forced to do so). 


> 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 don't think that will be completely possible.

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

We need to provide some things in a GUI. New users don't want to learn
CMake, especially if all they want to do is build a simple app to learn.

> For instance what should the user do if he wants to link to some library, 
> e.g. libxml2.so ?

Well, the simple approach to this is to let the user define the library
including path and put the proper cmake commands for that. I don't think
this is a very good idea.

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

Matt has some ideas, but unfortunately didn't write them down or tell
us.

Thinking out loud: Let the user provide a macro call for finding a
specific library (which he needs to implement outside the GUI) and then
the library name he wants to add. That way we are sure that the user
knows he needs some macro to find the lib, but still be able to let him
add libraries via the GUI. And of course this dialog should give a list
of existing macros so common stuff which is available from CMake already
doesn't need to be looked up.

Andreas

-- 
A visit to a fresh place will bring strange work.