Build system (was Re: Future of KDE Development)

[Alexander Dymo]

On Tuesday 15 February 2005 00:53, Guillaume Laurent wrote:
> Why would an IDE need to parse it ? It only needs to generate it. 
Not really. If you take a look at all builtool support plugins in KDevelop
you will found that at least two of them (autotools and qmake)
_do_ 1) parse 2) modify and 3) write changes back to the project files.
Makefile.am parser and modifier is actually implemented simpler than the
one for qmake's .pro files ;)

> If you're 
> thinking of importing a project, then it's even easier : just write some
> python code that will print the scons targets and stuff into a format that
> the IDE can grok rather than build them.
That doesn't solve the problem of writing changes back to the project file.
If you changed a list of files in a target withing the IDE, you should write
it back. Here the troubles with build file syntax, user formatting, etc.
arise.
I can see the other side of the problem. As far as I can see, any
extra features of scons-based build system can be implemented as 
extra python modules. That's good. That's much better than
autotools approach. But that doesn't solve the problem with IDE
which won't know about your extensions.
Consider, how can IDE know of, for example:
myenv.Dcop( ['test2iface.h'] )
or another methods you write:
myenv.DoMyWay( [myfile.cpp] )
How complicated should be the GUI in this case?

> > God, how I miss the buildsystem that would use
> > xml files or smth similar that is easy to parse and modify ;)
> It's called ant or maven and while it's easy to parse, believe me it is NOT
> easy to modify.
Not easy by hand ;) but _very_ easy by an IDE.
Btw those tools are java-only afaik. Do you know any such tool which do
not depend on a programming language.
Freshmeat search showed one such project named xmake but it aims to
be "simple" which is not what we want.

-- 
Alexander Dymo
ICST Department, National University of Shipbuilding, Mykolayiv, Ukraine