[Qt5-feedback] Build system requirements for Qt5

[André Pönitz]

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:
> > > srcs = foo.c, bar.c, blub.c
> > > 
> > > if(Windows)
> > > 
> > >    srcs += win.c
> > > 
> > > if (HAVE_MOUNT_H)
> > > 
> > >    srcs += mount.c
> > > 
> > > if(BSD || HAVE_WHATEVER)
> > > 
> > >    if (SOME_VERSION < 1.0)
> > >    
> > >       srcs += x1.c
> > >    
> > >    else
> > >    
> > >       srcs += x2.c
> > > 
> > > add_executable(hello $srcs)
> > > 
> > > I think an IDE cannot decide automatically where to add a file here.
> > > Also I cannot imagine how to present those different places in a GUI
> > > (...and  the GUI  would still be somewhat easier to understand than just
> > > looking at the cmake  script).
> > > 
> > > So, I'm curious how you plan to solve this.
> > 
> > You're trying to solve the problem of having a GUI for writing every aspect
> > of the build system. That's not what we want.
> > 
> > What we want from the above is the full listing of source files (to present
> > in the project listing).
> 
> Sorry if I misunderstand something, but cmake does exactly that for VS, Xcode, 
> Eclipse, CodeBlocks and KDevelop3.
> They all get the full list of source files, and if the IDE supports it, 
> assigned to the respective targets.

The full list of sources is one aspect, needed only to present the user a
reasonably complete project.

In fact I'd even argue that this is a lesser problem, as it can be (partially)
shifted to the C++ parser and "solved" in a mostly buildsystem-agnostic
way by doing something like

  add_executable(hello foo.c, bar.c, blub.c, win.c, mount.c, x.c)

with win.c

 #if defined(OS_WINDOWS)
 	// [...]
 #endif

etc.

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", 
"preprocessing one compilation unit", "quickly building the project after 
changing only one source file", "full speed parallel build of the project 
on the 50 nodes of the local build farm" 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" 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.

Andre'