----- Original Message ---- > From: Alexander Neundorf <[email protected]> > On Thursday 09 June 2011, BRM wrote: > > ----- Original Message ---- > > > > > From: Alexander Neundorf <[email protected]> > > > > [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 _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
