Build system (was Re: Future of KDE Development)

[Kevin Puetz]

Harri Porten wrote:

> On Sat, 19 Feb 2005, Alexander Dymo wrote:
> 
>> qmake support in KDevelop theoretically leaves alone everything it does
>> not understand (ok, ok, only theoretically because there are some bugs).
>> But again, it is theoretically possible to understand the whole content
>> of .pro file and reflect it in the GUI. I'm working now on a qmake parser
>> and so far I'm getting promising results.
> 
> So you aim at dealing with definitions like:
> 
>   unix: SOURCES += foo_unix.cpp
>   win32: SOURCE += foo_win.cpp
>   QMAKE_CXXFLAGS += $$(EXTRA_DEFINES)
> 
> Sounds very challenging. Trying the same with a fully fledged language
> like Python sounds almost impossible to me.
> 
> Harri.

One thing that might help is that SCons is declarative, not imperitive (or
so the examples and documentation claim). So it's likely possible to hook
into it at a lower level - actually *run* the script, as it does at
initialization, then inspect the resulting data structures to learn which
source files SCons intends to process (and what tools it wants to process
them with), what the's include paths are, etc. This would probably work
quite well for the IDE's need to load in the project file. 

It wouldn't help with editing the makefile from within the IDE; that would
just have to be treated as the source-code file that it is. You *might* be
able to handle the really simple cases of editing the project; things like
adding files, by being a bit naïve - find unconditional Program([file1.C,
file2.C]) blocks (which in python corresponds to 'not-indented') and hope
that's the right place. But a build system that has a real programming
language is going to be nigh impossible to automatically edit, so the fact
that it becomes essentially read-only to IDEs is a tradeoff to be
considered...