[Qt5-feedback] Build system requirements for Qt5

[BRM]

----- Original Message ----

> From: Alexander Neundorf <neundorf at kde.org>
> On Thursday 09 June 2011, BRM wrote:
> > ----- Original Message ----
> > 
> > > From: Alexander Neundorf <neundorf at kde.org>
> > 
> >  [snip]
> > 
> > > > - it needs to feed an IDE with a useful  understanding of the  project
> > > > 
> > > >     structure (not some random foo.o targets whose  existence the  IDE
> > > >    must divine out of thin air)
> > > 
> > > CMake  can easily put all existing targets into the project  file for the
> > > IDE, the  IDE doesn't have to guess them.
> > 
> > Last I used CMake, that really depended on what you wanted to  do.
> > For instance, Header Files only made it into the output generated  project
> > (e.g. VC++ project) _if_ you also wanted to do pre-compiled  headers (which
> > I personally detest and don't use).
> > It was also  very difficult to organize the files in the display of the IDE
> > output  generated projects - e.g. grouping them together for logical
> > purposes.  (There was a way to do it, I forget how off hand, but it wasn't
> > very  intuitive.)
> 
> Probably using the source_group() command.

Ok.
 
> > So,  I'd very strong advocate that whatever tool it has maintain QMake's
> >  ability to differentiate between source and headers and put headers into
> >  the project files, 
> 
> This can be done by the generator. At least the  KDevelop3 generator and I 
> think also the CodeBlocks generator automatically  check whether there's a 
> <name>.h file in the same directory for each  <name>.cpp file and add that 
> header to the project if  found.

So what happens when you have the following:

project
project\include
project\include\myobject.h
project\src
project\src\myobject.cpp

While I understand some people like to have headers and implementation files 
right next to each other, however, at least when building APIs I find it easier 
and more condusive to typically separate the headers out; even in some cases 
having a second include directory for public headers to differentiate between 
public and private headers when installing the headers on the system is not an 
option. And I'm sure I'm not the only one. ;-)

VC++ also doesn't do that - which is a pretty big IDE target.

> > and even go one step further of being able to do IDE
> >  Display Folders so that both could be logically organized - e.g.  headers,
> > headers\protocol, etc.
> 
> This could be done by the IDE  completely independent from cmake, or cmake can 

> prepare such groups. E.g.  the KDevelop3 generator generates some groups, I 
> think it was Header,  Sources, UI-files.
> 

Which are then useless once Cmake regenerates the project files as you would 
have to go back and re-add them all - or at least use version control to 
selectively undo removals from the project file if you had such an option.
It needs to be integrated into the build tool.

Any how, that's just my 2 cents and probably far off-topic for this list.

Ben