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

[Alexander Drozdov]

2016-03-08 20:01 GMT+10:00 Hunger Tobias <Tobias.Hunger at theqtcompany.com>:

> Hi Alexander,
>

Hi again!

[skip]

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

I think, that compilers for the langs, supported by the QtC should be
detected too. Otherwise: we can create C project via wizard but can't point
C compiler. Not a good (is it problem solved for Qbs, qmake and how?). But
this question must be discussed ouside of the CMake-only context. It more
deeply.


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

Heh, two compilers (gcc 4.8, gcc 5.3) and two Qt versions (4.8, 5.5)
requires to create four Kit configurations. Adding clang increases possible
Kit configurations up to six. Increasing Kit settings increases possible
Kit configurations dramatically. CMake toolchain can use same compiler but
provide some other presets. In general Toolchain file can be used not only
for cross-building. In common: it can be interpreted as a per-build project
configuration. Complex and power configuration, not only VARIABLE=value
pairs.

[skip]

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

I too :-) Simply tried. But KDevelop and CLion guys more-less solve this
problem.


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

Hmm. On file adding cmake reparsing forces. We can checks that added files
not goes to the any target and output notice to the top of the editor (like
in past notice to re-run cmake outputs). Like: "File added but not assigned
to any target, please edit CMakeLists.txt manually". Yes only source-code
files should be filtered :-)

[skip]

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

Ok, thanks.


>
> > Look:
> > *
> >
> https://github.com/h4tr3d/cmakeprojectmanager2/commit/61df428d14c7bb785b50f26a
> > 90517aecb701a9eb
> > - reading source tree
>
> Could you consider to push the scanning logic upstream?
>

No problem. Simple give me some amount of time :-)

Also, could you please provide Best Qt-friedly way to scan directory tree?
If recursion can be omited - it will be good. My current solution uses
QDir::entryInfoList() + recursion.

[skip]

> > > 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 not ready to answer.


>
> I am still unsure about the unsetting of values though.
>

I will fill feature request for next thing:
outputs description for option if present (new table colum is needed).

What do you think about it?


> > What kind of the help you needs?
> Bugreports, feature requests, code, documentation updates, everything:-)
>

Ooookay!


>
> > > 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 work with master version of the QtC (yes I am crazy. a little), some
features can be incomplete yet or contains known bugs that will be fixed by
the next commit.
What do you think about next steps:
1. found issue
2. search on bug tracker
3. wait for a week
4. try agait
5. still present? search on bug tracker
6. not found? report it.

Or I can mail it and fill report after feedback? (currently only two most
interesting places of the QtC for me: Baremetal and CMake)


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

As I understand Code model simple uses Kit compiler, am I right? So, if
user select Kit but overrides Toolchain and (possible) Compiler it is
expected behaviour that QtC Model continue to work with current
Kit-Specific compiler, now with Toolchain-specific. It also helps to avoid
cmake loops.


>
> > 3) User needs an ability to force cache clean before next cmake run. It
> > requires in some cases. Look my solution:
>
[skip]

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

As for scanning: give me time :-)


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

Ok. I will submit "dir scanning" as a complete request and
"adding/renaming/removing" after some time as a separate patch: to discuss
via review board. I think that adding files via context menu very
comfortable and bug reports can be prevented by the good user iteraction.


> Best Regards and thanks for taking the time to report your feedback!
>
You are welcome!


-- 
WBR, Alexander Drozdov
http://htrd.su
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20160309/33b590d3/attachment.html>