On Wed, Jul 27, 2011 at 6:29 AM, Alexander Neundorf <[email protected]> wrote: > On Tuesday 26 July 2011, Coda Highland wrote: >> On Tue, Jul 26, 2011 at 2:27 PM, Oswald Buddenhagen >> >> <[email protected]> wrote: >> > On Tue, Jul 26, 2011 at 08:26:47PM +0200, ext Alexander Neundorf wrote: >> >> On Tuesday 26 July 2011, Campbell Barton wrote: >> >> > The main advantages over qtcreators cmake support is that it gets >> >> > includes and defines from the project, every so often I see complaints >> >> > about this in IRC so thought others might find this useful. >> >> >> >> That's a hack. >> >> It would be better to spend the time on improving the CodeBlocks >> >> generator in CMake so it provides all the required information. >> > >> > the *right* solution would be actually a proper parser inside creator >> > itself, like we have for qmake files. less meta, more function. >> >> That's what I was thinking too; I mean, we don't ACTUALLY support >> cmake projects > > Yes, that's how it is supposed to be, at least from the cmake POV. CMake > generates projects for the IDEs. The IDEs should not have to care whether the > project file has been written by cmake or by themselves or in any other way. > >> -- we support Code::Blocks projects and cmake just >> happens to export them. > > No, it's not that cmake "just happens to export them". > When support for cmake was added, I was a bit involved in the discussion how > to do it. The options were basically reusing an existing generator from cmake > or adding a qtcreator-generator to cmake. > The C::B one was considered good enough, also taking into account the time > necessary to write a qtcreator-specific generator for cmake. > > Having said that, adding the system include dirs and builtin macros to the > C::B project file generated by cmake is a good idea (this is already done for > Eclipse). > Now, KDE-related stuff is at the top of my TODO list for cmake 2.8.6, > improving support for C::B/Qtcreator comes later (at least in this cmake > release cycle). > But applying a nice patch wouldn't be too much work :-) > > Alex
Hi Alexander, good to see this is on you're radar and agree adding more info into C::B is the way to go. Yep, this is a stop-gap hack, but in some ways it manages to be better then built-in cmake support in QTC which is why I posted it. Since there are patches to get C::B to write defines and a patch for QtCreator to read them, the problem has been solved - we are just waiting for them to be applied, but its been a while and both projects have made releases since the patches were releases so I'm not sure on what the status is with this since both projects need to be updated. See: http://cmake.3232098.n2.nabble.com/QtCreator-project-generator-td6076919.html When someone on IRC asks "Why does QtCreator gray out my #ifdef code" - Saying: - Put up with it! or... - Manually add in the defines into the file while editing and remove after (Which I used to do!) or... - Build patched versions of cmake & qtc. ... is not a practical answer for most people. -- - Campbell _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-creator
