KDevelop4 BuildManager/BuildTools

[Alexander Neundorf]

On Sunday 21 January 2007 15:26, Alexander Neundorf wrote:
> a) Simple
> This would be easy for the newbie and for quick "let's try something"
> hacks, but not good enough for anything significantly above this level.
>
> Just have lineedits:
> Link libs   : /usr/lib/libxml2.so;/usr/lib/libjpeg.so;-lkdecore
> Include dirs: /usr/include;/opt/kde/include
>
> This is easy to use for the user and can be supported by the file dialog.
> The user doesn't have to care for cmake/qmake/autotools/whatever. It should
> work on his development system without major issues.
> Strings like "-lkdecore" will be recognized that they are no directory and
> passed directly to the linker.
>
> Problem: it is very unportable, unportable between different Linux
> installations, and even more unportable between different compilers or OSs

About using cmake as "built-in"-buildsystem:
if the cmake variable ${CMAKE_SUPPRESS_REGENERATION} is set to true, the rules 
for rerunning cmake are not included in the makefiles.
While this usually doesn't make much sense, it would help for our case.
After the user has edited some build options via the GUI, kdevelop regenerates 
the cmake files and then runs cmake. If the user has edited the cmake files 
manually in the meantime, his changes are lost and they don't have any 
effect.
We could even ship kdevelop with some fixed release (e.g. 2.4.6) of cmake, so 
that we don't have any compatibility issues regarding which version of cmake 
is installed in the system. AFAIK cmake can be installed anywhere, also e.g. 
in apps/kdevelop/cmake/.

What do you think about this ?

We could make this the simple-stupid mode, which "just works" for quick 
projects.

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