[Qt-creator] CMake in QtC 4.0 [ex Qt Creator 4.0 soft-branched]

Mon Mar 7 14:44:26 CET 2016

2016-02-29 19:31 GMT+10:00 Hunger Tobias <Tobias.Hunger at theqtcompany.com>:

> Hi Alexander,
>

Hi Tobias, sorry for delay

> On Mo, 2016-02-29 at 18:44 +1000, Alexander Drozdov wrote:
> > Improved CMake support? What about scope of this improvements?
>
> 4.0 will mostly have workflow improvements for CMake.
>
> There have been no improvements to the parser, etc. that extracts data from
> CMake for our code model. Some bugs got fixed along the way. E.g. syntax
> highlighting should work a bit better, but nothing major.
>

Thanks for info!

>
> >  Currently I
> > see, that two of the four features that I support at the
> > CMakeProjectManager2 (fork on github) already implemented:
> > 1) Handling Kit compiler. But only C++, not C or other. But it simple
> > configurable at the Kit configuration page now.
>
> QtCreator does only know one toolchain for each Kit and assumes that to be
> a C++
> one. So there simply is not enough information to set up the C compiler
> with the
> information available. We will need to manage toolchains and programming
> languages they support for that and I currently have no plans to go that
> far,
> even though that information is also useful for other build systems.
>
> You can add any cmake settings you need to the Kit's cmake configuration
> though
> and those settings will then be applied automatically everywhere that kit
> is
> used.
>

I know and understand. In my solution I simple predict C compiler based on
some info: g++ -> gcc, clang++ -> clang, cl.exe -> cl.exe :-) with same
prefixes and suffixes
Look (core removed after dialog reworks):
https://github.com/h4tr3d/cmakeprojectmanager2/commit/268b1cb93ea3fb40c7bdcaead51452c764dc95bb#diff-8809e7f792412acf4605265b6ad2c20fR790

>
> > 2) Pointing Build Type to the CMake
>
> That was in 3.6 already if I remember correctly:-)
>

Yes! And it good thing!

>
> > Next features I need, but it will be nevenr implement:
> > 1) Good management for the CMake toolchain files. Upstream changes so
> > fundamental, but I already port this changes to the new codebase. But
> > pointing compiler via CMAKE_CXX_COMPILER, not via CXX/CC evn variables
> > breaks toolchain files. I solve it via forgoting Kit configuration in
> case,
> > when user select Toolchain file.
>
> I have never used those myself: What exactly do those do? As I understood
> it,
> they are just a bunch of settings that are fed to cmake to pre-fill its
> cash. Is
> that correct?
>

No. Toolchain file in simple way look like settings. But in some complex
cases it can call CMake functions, search complilers via find_program() and
so so.

To somplify: Toolchain file is a file that preloaded by the cmake before
CMakeLists.txt.

>
> If that is the case: Can the CMake Configuration in the Kits cover that?

Not in all cases. Also, in some cases you can want simple builds current
project with current Kit but with suggested Toolchain. Toolchain can be
specific for single project. Create Kits for every toolchains not a good
idea. IMHO.

Maybe we could add an "import from toolchain file" to the CMake
> Configuration dialog?
>

Not a good idea. See above.

>
> > 2) Adding files via context menu and show all files in source Tree: it
> > allows to add new file to the target directory, see it and after simple
> add
> > to the needed target at the CMakeLists.txt
>
> The only chance I ever see that happening is for cmake-daemon (
> https://steveire
> .wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ ) to get accepted
> upstream.
>

I understand. I try to parse cmake (adopt tokenizer to build with plugin)
but it to complex to process CMakeLists.txt and in sub-CMakeLists.txt.

So currently I use next scenario:
1. For code module I use files provided by the CbpParser
2. For source tree I display all files. Yes, it displayes files like
README, LICENSE and some sources that skipped from the compilation (and
from the Model). But it simplify navigation and adding/removing/renaming
3. Enable items Add/Rename/Remove file
4. In handlers of the given signals I ask BuildDirManager to do
forceReparse()

This scenarion works very well for FILE GLOBBING and AUX SOURCE DIR. And
yes, this scenarion requires addition CMake execution when files described
in CMakeLists.txt without globbing.

And yes, this algorithm requires additional work:
1. Scan sources tree
2. Sorts tree and cmake tree
3. Search for added files (ProjectExplorer::compareSortedLists)
4. Substract and clear source dir tree (qDeleteAll +
ProjectExplorer::subtractSortedList)
5. Add it to the cmake tree
6. Pass new cmake tree list to the buildTree()

Also, this behaviour same to the KDevelop, CLion. But it can be done
optional in simple way.

One question: what about addition items in the Project tree nodes context
menus: is it possible to add sone custom item? Like "Display all files".

Look:
*
https://github.com/h4tr3d/cmakeprojectmanager2/commit/61df428d14c7bb785b50f26a90517aecb701a9eb
- reading source tree

>
> > New changes, that likes me:
> > 1) Integrated CMake dialog to the Project page and transparency CMake
> > running.
> > 2) Table editor for the CMake options. Small qestion according this
> > improvement: will be added some set of known options and ability to
> select
> > it via integrated combo box? will be editor delegates according to the
> > option type added, like: if option type is a PATH use File Open dialog?
>
> The editor already uses the type hints to some extend: The bool ones are
> tickboxes that tackles between "ON" and "OFF".
>
> A combobox to select between a set of different options is not going to
> happen,
> simply because cmake has no way (that I found) to tell Qt Creator about the
> allowed values.

Ok. Not a problem. But, I found that it is impossible to add some custom
value: there is Edit button but there is no Add button. It works as planed?

> Using path-chooser to pick a path/directory is definitely an
> option though.
>
> > So, roadmap for the CMake Project Manager plugin is interesting.
>
> My roadmap is simple: Make what is there stable for 4.0.
>

Good :-)

>
> Next step is to help to polish cmake-daemon up to a state where it can be
> pushed
> for review to the cmake project and use that when/if it makes it upstream.
> That
> changeset is a game-changer (not just for Qt Creator!), but unfortunately
> my
> impression is that the interest from the cmake side is low to non-existent.
>

Heh. We wants good libcmake for a long time. Seems that cmake daemon
possible only as a separate project :-(

>
> Any help with cmake-daemon would be greatly appreciated by Steven,

My work needs a lot of work time. My family requires a lot of personal
time. My personal projects and other open source activity requires a lot
time too but has so low priority :-)
So, I want to do wold better, but I need more than 24 hours per day or too
much my clones :-D

> any help with the cmake plugin is greatly appreciated by me:-)
>

What kind of the help you needs?

>
> Finally, please test the 4.0 branch and report bugs, especially if you use
> CMake
> a lot.
>
> Oh yest. A lot. Currently some observation:
1) Kit settings after Apply pressing or after Ok and dialog reopening drops
CMake generation selection to the Codeblocks - Ninja and marks Kit as
modified. If you select Codeblocks - Makefiles Kit modification markers
clears. If there is no reported issue and it is not known issue, I can fill
report.

2) With passing CMAKE_CXX_COMPILER via cmake paramters we can loops cmake
and QtC project opening in some cases. Simple project that demostrate it is
attched. Note, there is 3 (known for me) ways to setup compiler to the QtC:
a) via Env variable CXX (CC for C, other variables uses for other langs)
b) via Toolchain file
c) via -DCMAKE_CXX_COMPILER
items declared in the increasing priority order. Current implementation
(4.0/master - I use master, it simple for me to maintain Ubuntu PPA with
master QtC) uses c) that overrides all other settings. IMO, case a) must be
used instead: Kit should simple notify cmake about compiler, not strongly
set it. It also can breaks some CMake project-specific magic.

But I am not sure: is setting compiler via Env variable is a portable way?
But CMake suggests it itself  in error outputs:
~~~
  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full
path
  to the compiler, or to the compiler name if it is in the PATH.
~~~

3) User needs an ability to force cache clean before next cmake run. It
requires in some cases. Look my solution:
a)
https://github.com/h4tr3d/cmakeprojectmanager2/commit/bb5f74b01c63e092f90a3e4c49c4aaec2f8abea4
b)
https://github.com/h4tr3d/cmakeprojectmanager2/commit/a8d6431b2649c36d02c05332c5cafe8faa4539b5
c)
https://github.com/h4tr3d/cmakeprojectmanager2/commit/5308efab9d9359c671e35ea65e82369b4040b3f9
d)
https://github.com/h4tr3d/cmakeprojectmanager2/commit/38139d6ed97f1fd6adecf92aaa4a55d6c620f513
(adopts changes above to the current master)

4) If you agree with showing all files in project tree and
adding/removing/renaming files as I describe above, I can submit merge
request tot the gerrit (and checks it work after last accounts merging :-))
Some yesrs ago this changes was discarded.

-- 
WBR, Alexander Drozdov
http://htrd.su
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20160307/d684ab80/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake-loop.tar.xz
Type: application/x-xz
Size: 808 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20160307/d684ab80/attachment.xz>