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

[Hunger Tobias]

Hi Alexander,

On Mo, 2016-03-07 at 23:44 +1000, Alexander Drozdov wrote:
> 2016-02-29 19:31 GMT+10:00 Hunger Tobias <Tobias.Hunger at theqtcompany.com>:
> Hi Tobias, sorry for delay

No worry:-)

> >  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/268b1cb93ea3fb40c7bdcaea
> d51452c764dc95bb#diff-8809e7f792412acf4605265b6ad2c20fR790

I would prefer to keep this as is: It is pretty straight forward for the users
(or an admin/packager) to provide custom cmake config flags to be set by a kit.
So this problem can be addressed at that level (till Qt Creator starts to manage
several toolchains per kit at some point -- if we ever go there).

<snip: Toolchain files>

> 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.

I would argue that they still are just a bunch of settings... at least after
they are executed. Since kits are host specific, I still think we can get away
with the current approach: Just put whatever concrete information you need into
the Kit's settings and you are done. Yes, that fails to detect compilers and
stuff for you, but you know where those are anyway.

> 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.

IMHO it is:-) How else would you switch between different configurations easily?

> Maybe we could add an "import from toolchain file" to the CMake
> > 
> > Configuration dialog?
> > 
> Not a good idea. See above.

OK.

> 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.

I am not brave enough to go there:-)

> 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

I have been thinking on doing that, too. I hate the idea of just scanning the
file system, but I think it is the best that cmake will let us do.

> 3. Enable items Add/Rename/Remove file

I don't plan on that yet.

> 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.

Yes, I see that it will work there. But that is not good enough for me, simply
because I will get tons of bug reports about "Add file" not working from lots of
people that do not use such a setup. There are just too many cmake users out
there for me to risk that:-)

> 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".

Not in a straight forward way... The tree is pretty static as is the
transformation from the full tree to the simplified tree.

> Look:
> *
> https://github.com/h4tr3d/cmakeprojectmanager2/commit/61df428d14c7bb785b50f26a
> 90517aecb701a9eb
> - reading source tree

Could you consider to push the scanning logic upstream?

> > 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?

I wanted to implement adding and unsetting values, but then I thought that this
will probably not be necessary: CMake puts all values it cares for into the
cache, doesn't it? If that is true, then anything you add will be ignored anyway
-- so why offer that in the first place?

I am still unsure about the unsetting of values though.

<snip>
> > 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 :-(

If it stays separate, then I won't use it. I do not have the time to maintain a
cmake branch!

I am very willing to help getting the code upstream and to get it into a state
where it is useful to a real-live project (currently it is suitable for some
demos, but not production ready), but I do not want to commit to more than that.

> > 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

Yes, same here:-) I want to hack on an IDE, not some random build system!

> > any help with the cmake plugin is greatly appreciated by me:-)
> > 
> What kind of the help you needs?

Bugreports, feature requests, code, documentation updates, everything:-)

> > Finally, please test the 4.0 branch and report bugs, especially if you use
> > CMake
> > a lot.
> > 
> > Oh yest. A lot. Currently some observation:

Could you please file such issues in the bugtracker at https://bugreports.qt.io/
 ? They are much simpler to track there!

I will try to fix the stuff you reported by mail asap. No need to put those into
the tracker:-)

> 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.
> ~~~

I still prefer to just use -DCMAKE_CXX_COMPILER: We want to force it, as the
code model needs to have the correct compiler to be fully useful.

> 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/bb5f74b01c63e092f90a3e4c
> 49c4aaec2f8abea4
> b)
> https://github.com/h4tr3d/cmakeprojectmanager2/commit/a8d6431b2649c36d02c05332
> c5cafe8faa4539b5
> c)
> https://github.com/h4tr3d/cmakeprojectmanager2/commit/5308efab9d9359c671e35ea6
> 5e82369b4040b3f9
> d)
> https://github.com/h4tr3d/cmakeprojectmanager2/commit/38139d6ed97f1fd6adecf92a
> aa4a55d6c620f513
> (adopts changes above to the current master)

Could you push that into codereview.qt-project.org? That makes it way safer for
me to reuse some/all the code.

> 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.

I would very much like the file scanning stuff, but the adding/removing itself
will probably cause way to many bug reports for me to feel comfortable to
implement that at this time.

Best Regards and thanks for taking the time to report your feedback!

Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B