KDevelop4 BuildManager/BuildTools

[Alexander Neundorf]

On Sunday 21 January 2007 14:19, Andreas Pakulat wrote:
> On 21.01.07 11:46:36, Alexander Neundorf wrote:

... snipped everything to which I agree

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

Ok.

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

Sure :-)

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

What do you mean exactly with "define the library including path" ?

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

Macro as in CMake macro ?

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

Ok, I think I have something similar in mind.

I see the following ways for this:

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

b) Visible Buildsystem

For anything better than the above some kind of qmake/cmake/autotools 
macros/functions/variables have to be used.
E.g. for CMake this could be:
Link libs:    ${XML2_LIBRARY}
Include dirs: ${XML2_INCLUDE_DIRS}

As soon as it looks this way, the user must be aware of the used buildsystem 
and do different things depending on it.
What I want to say, the user has to know some things about the syntax of the 
used buildsystem.
In the simple case this could lead to:

set(_fooExtraLibs)
set(_fooSrcs main.cpp)
find_package(XML2)

if (XML2_FOUND)
   set(_fooExtraLibs ${XML2_LIBRARY})
   include_directories(${XML2_INCLUDE_DIR})
endif (XML2_FOUND)

add_executable(foo ${_fooSrcs})
target_link_libraries(foo ${_fooExtraLibs})

Doing this one way is no major problem I think.

I see potential problems if the user needs to do advanced stuff or if kdevelop 
loads a project using more advanced cmake files.
Trying to put complex logic expressions in a GUI doesn't make much sense IMO, 
then the user should IMO just be presented with the buildsystem script files 
as they are.
In CMake the script can execute commands, parse their output, do regexps, 
depending on this add files or libs or whole directories or ...
The same is true for autotools, not sure about qmake.

So, doing complex things requires thought and knowledge of the language, no 
matter whether it's in the C++ source code or in the buildsystem script 
files. IMO we shouldn't try to hide this from the user, this will only lead 
to broken/unportable build setups.

So I would suggest a multi-way approach:
-simple stupid mode a) where the user doesn't even know that there's cmake 
working behind the scenes

-for everything which can be considered "advanced" let the user edit the 
script files directly (cmake, qmake, autotools) and try to provide "wizards" 
which help with common tasks, i.e. click "add include directory" -> cmake 
mode: let the user chose between the currently known variables, a file 
selector and a custom string, and then insert the 
entry "include_direcories(<the_dir>)" in a probably appropriate place

-and maybe something between the two
But honestly, if the project is intended to be compiled on more machines than 
only the box of the developer, than the developer really should care about 
portability issues, and for this he really should know the buildsystem. 

Just some thoughts...

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