[Qt-creator] Qt Creator and CMake

[Konstantin Tokarev]

16.02.2012, 16:39, "Campbell Barton" <ideasman42 at gmail.com>:
> 2012/2/16 Konstantin Tokarev <annulen at yandex.ru>:
>
>>  16.02.2012, 04:06, "Pau Garcia i Quiles" <pgquiles at elpauer.org>:
>>>   On Wed, Feb 15, 2012 at 10:05 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>>>>   Im not sure what there is to be gained here.
>>>>   Adding/removing files directly from Qt Creator (yes, that is important for many developers), creating modules ("finders") directly in Qt Creator, integration with the simulators, cross-compilation chains, etc I'd say there is a lot to be gained.
>>>>   CMake is a language - it executes, and poops out a project file.
>>>>   As a qtcreator/cmake user Im happy for qtcreator not to be *smart*
>>>>>    about cmake, infact I'd prefer it be kept that way.
>>>>   All qtcreator needs to do is load that project file correctly, which,
>>>>   I should add - it currently does not do (it misses includes and
>>>>   defines from CMake), IMHO this should be first priority to get
>>>>   working.
>>>   Avoiding the project generation altogether would be even better.
>>  Irrelevance of any intermediate product is beyond question for me; one may argue that hand-crafted parser (like in KDevelop) is better, but use of CMakeLib seems to be more reliable (Qt Creator will see actual project model of CMake instead of "guessed" one), and will provide additional capabilities like changing of project configuration from GUI without use of external tools.
>>
>>  --
>>  Regards,
>>  Konstantin
>
> regarding adding/removing cmake files from QtCreator (basically
> managing a cmake project via the GUI),
> - this would depend on making some assumptions about the CMakeLists.txt files,
> for example, in our project some source files are auto generated and
> the file lists created by regex.
> other files are compiled twice for different targets and different
> defines. Having QtCreator (or any IDE) parse this and edit it in a
> useful way is just not going to happen.

Currently I just read file lists from discovered CMake targets, so Qt Creators
sees the same files as CMake does, with real full paths. If some file is generated
twice in different directories, it will be displayed twice in tree inside different folder
nodes. It may be not-so-trivial to distinguish generated and non-generated files
(to hide generated files from tree by default), but I think it's safe to assume that
all source files located in build directory are generated.

>
> On the other hand maybe you can accept reduced functionality - but in
> doing this you _are_ defining some new kinds of cmake-standard which
> currently doesn't exist. It means people not using QtCreator may make
> changes by hand that QtCreator users complain about because the
> project manager cant properly manipulate it.
>
> Is this whats being proposed or am I missing something?

Nobody proposed that.

> As for parsing the config and editing it from QtCreator - great!,
> but thats a totally different kettle of fish, comparing CMake's cache
> file (a simple key-value store) to a programming language.

You can edit the same key-value pairs from Qt Creator's GUI project
configuration rather than launcing separate tool to do the same job.

-- 
Regards,
Konstantin