[Qt5-feedback] Build system requirements for Qt5

[Alexander Neundorf]

Hi,

On Tuesday 07 June 2011, André Pönitz wrote:
> On Tuesday 07 June 2011 01:40:36 ext Alexander Neundorf wrote:
> > On Tuesday, June 07, 2011 01:12:48 AM Thiago Macieira wrote:
> > > Em Tuesday, 7 de June de 2011, às 00:52:16, Alexander Neundorf escreveu:
...
> Sure. Not "nice". But a possible way to draw a line between "really
> supported" and "you're on your own" land. People are typically not
> directly opposed to do minor changes to their sources if it makes
> their life easier.
> 
> The bigger problem is that creating the code model is only one aspect
> of the interest of an IDE in a build system. There are other use cases
> related to actual building, like "compiling _one_ compilation unit",

CMake has a target for each object file, you can do "make foo.o"

> "preprocessing one compilation unit", 

CMake has that too, you can do "make foo.i"
and you can also do "make foo.s" to see what the compiler finally makes out of 
it.

> "quickly building the project after
> changing only one source file", 

What do you mean with "quickly" building ?
This file has to be compiled and the target(s) where it is used has to be 
linked again. What do you want to do quicker than that ?
If you do not want to check the dependency to other targets this can be done 
via "make mytarget/fast".
What else could you do quicker ?

> "full speed parallel build of the project
> on the 50 nodes of the local build farm" 

make -j50 is not good enough ?

Beside that, all these issues are related to the actual building step. CMake 
itself does not do the build.
If you are not satisfied with make, use something else or write something else 
your own. Maybe ninja has what you want.
If not, it is perfectly fine if you write a replacement for make, which might 
also offer a library interface, and add a generator for the input files of 
this build-tool to cmake.
Then you get all what you wrote above (although it looks like cmake does all 
that already with Makefiles), and you would not yet have to get in the 
business of also (re)implementing all the configure logic.

> etc, and also some related
> to _writing_ build files, e.g. as a result of a "wizard" style dialog that,
> say, "adds a library" by changing  to a suitable place in the "build"

CMake can easily provide the information in which directory (i.e. in the 
CMakeLists.txt of which directory) a target has been added.

> files.
> 
> Also, the language of the system matters. It cannot reasonably be
> expected that a GUI can automatically manage the whole project
> description, so editing the build files with a "text editor" will be rather
> the normal than the exceptional case. We know that qmake is pretty
> much of a mess when to comes to the syntax. Editor support to the
> degree we got used to from C++ editing like context sensitive
> completion is basically impossible.

"cmake --help-command <commandName>" would be already a good start, and I 
think this is what e.g. KDevelop4 is doing.
For variables you might execute "cmake --help-variable <variableName>" 
instead, e.g.

hammer:~$ cmake --help-variable CMAKE_PREFIX_PATH
cmake version 2.8.4
  CMAKE_PREFIX_PATH
       Path used for searching by FIND_XXX(), with appropriate suffixes
       added.

       Specifies a path which will be used by the FIND_XXX() commands.  It
       contains the "base" directories, the FIND_XXX() commands append
       appropriate subdirectories to the base directories.  So FIND_PROGRAM()
       adds /bin to each of the directories in the path, FIND_LIBRARY()
       appends /lib to each of the directories, and FIND_PATH() and
       FIND_FILE() append /include .  By default it is empty, it is intended
       to be set by the project.  See also CMAKE_SYSTEM_PREFIX_PATH,
       CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, CMAKE_PROGRAM_PATH.

hammer:~$ 


Alex