Re: [Qt-creator] Suggestions for 'new class' dialog

[Tobias Hunger]

On Wed, Dec 16, 2020 at 9:08 AM Eike Ziller  wrote:
> Of course an option is also to check if a single sensible place where to add 
> the file to exists
> (single CMakeLists.txt file, single target, single 
> add_target_sources/other-function-that-we-recognize) and then automatically 
> add it,
> otherwise inform and require manual user action.

The challenge is to reliably detect this set of conditions.

Best Reagrds,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Suggestions for 'new class' dialog

[Tobias Hunger]

On Tue, Dec 15, 2020, 17:23 Kevin André  wrote:

> I think it could be done without understanding the structure of a
> CMake file, but with some kind of pattern matching instead. Try to
> emulate what a person would do when a new file is to be added: find
> out where the pre-existing source files are in the CMake file, and
> insert the name of the new file using the same pattern used for the
> existing files.
>

This goes up in flames when the CMakeLists.txt file is in an unusual place.
But creator can error out and warn.

It also goes up in flames when several targets are defined in one
CMakeLists.txt file. Creator might add your file to the wrong target then
and has no way to notice this.

Adding files into cmake does not work as long as the tool doing the
insertion is able to understand cmake code. There is no way around that,
cmake projects differ to much from each other and best practices to make
anything else possible.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] What to click after changes in CMake project files?

[Tobias Hunger]

On Wed, Nov 25, 2020 at 12:14 PM Tobias Hunger  wrote:
>
> > Clarifying that: it should re-run CMake automatically when you save 
> > CMakeLists.txt files.
> > You need to explicitly apply configuration changes in Projects mode (but I 
> > think you are also asked to do that at some point).
>
> Clarifying that: it should re-run CMake automatically when you save
> CMakeLists.txt files and you did not opt to only ever run CMake
> manually in the cmake configuration pa

-ge.

Sorry, accidentally hit the send button:-)
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] What to click after changes in CMake project files?

[Tobias Hunger]

> Clarifying that: it should re-run CMake automatically when you save 
> CMakeLists.txt files.
> You need to explicitly apply configuration changes in Projects mode (but I 
> think you are also asked to do that at some point).

Clarifying that: it should re-run CMake automatically when you save
CMakeLists.txt files and you did not opt to only ever run CMake
manually in the cmake configuration pa
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Problem with CMake

[Tobias Hunger]

Did you apply your changes before building? There is a "Apply changes"
button below the edit area in Project mode.

You need to press that till the variables do not change anymore
(usually twice...). It *should* apply before building,
but maybe that is buggy or maybe you need to apply several times for
things to stick.

I hope that helps,
Tobias

On Thu, Nov 12, 2020 at 11:19 AM Björn Schäpers  wrote:
>
> Hi,
>
> I want to modify clang-format, for that I've:
> * Loaded LLVMs CMakeLists.txt
> * Creator runs cmake
> * I modify the project (changing the install path, activating clang, but most
> importantly LLVM_TARGETS_TO_BUILD set to "X86")
> * Creator reruns cmake
> * I can see new variables for clang, and can choose the targets to build
> * I hit Ctrl+B
> * My Disc runs out of memory, my changes to the cmake variables have been
> dropped and I build LLVM for various targets
>
> I've repeated this several times with different profiles (debug, release) and
> always get the same result. Am I doing something wrong? Is there a bug?
>
> Now I've run cmake myself and use the generated Makefile in the Creator for my
> development.
>
> I'm using msys2, gcc 10, cmake 3.18.4, and a self compiled QtCreator from the
> tag v4.14.0-beta1.
>
> Kind regards,
> Björn.
> ___
> Qt-creator mailing list
> Qt-creator@qt-project.org
> https://lists.qt-project.org/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

[Qt-creator] Stepping down as maintainer of the CMake plugin of Qt Creator

[Tobias Hunger]

Hello everyone!

I would like to step down as the CMake plugin maintainer in Qt Creator on 1st 
of August as I will start a new job then and do not expect to have the time 
necessary to be a good maintainer in the Qt project. Thank you all for the the 
opportunity to work with so many passionate people and the trust to maintain a 
plugin!

It would be great to see somebody step up to the task of making CMake easy and 
convenient to use in Qt Creator! I will be around and am willing to help 
getting people to settle into the code base -- as I still think this is a very 
important area for Qt Creator going forward.

The last couple of weeks I spend on streamlining the code (killing two of the 
three completely different ways for creator to interact with CMake) and to 
generally simplify the interaction between Qt Creator and CMake. I think this 
was a major step forward for CMake support in Creator  -- and it removed a lot 
of code and made things conceptually simpler, so now is a good time to hand 
over the plugin.

Best Regards,
Tobias

PS: Please consider to test the upcoming Creator release and report issues you 
find so that I still have a chance to fix them myself:-)

--
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] CMake support change in master branch

[Tobias Hunger]

Hi Matthias,

On Wed, Jun 10, 2020 at 1:51 PM Mathias Hasselmann
 wrote:
>
> Sure you are not giving in to a vocal minority? I very much liked
> QtCreator's cmake support so far.

Great to hear, thank you for your feedback!

> I'll very much miss the possibility to set CMake options with proper UI
> from within QtCreator.

That is possible and the UI here is unchanged.

> Hopefully support for passing "--target=" stays?
> Turnaround cycles will become terrible without.

No change here either:-)

You will not notice a change in behaviour till you switch build
directories to something that was not used before. In that case
creator will not try to apply what the kit told it to plus some the
changes you had done via creator (but not via any other tool) to that
new directory in some sequence that may or may not break  your
configuration.

Instead Creator will start from a clean slate using a very clearly
visible set of parameters. That is the part where you will notice
something about the change: There is a new textfield in the project
mode to set these parameters.

I really think this is a way cleaner and simpler to understand approach.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

[Qt-creator] CMake support change in master branch

[Tobias Hunger]

Hello everybody,
 
I just pushed a patch to the master branch that changes how CMake projects are 
handled. I expect this patch to still have some rough spots, so please avoid to 
update for a while if you want a polished experience, but I do hope for bug 
reports and feedback about the changes!


The idea of this change is to reduce the magic that Creator does when 
configuring CMake projects.


You can now specify a set of "Initial CMake arguments", that are going to get 
applied when a build directory is unconfigured (== does not contain 
CMakeCache.txt yet).
These are populated based on the selected kit, but will not change 
automatically when you update your kit. I want to add a warning when that 
happens, but that does not exist yet. Any CMake command line argument can be 
provided, so you can now ask for warnings to be enabled/disabled or whatever 
else is supported by CMake.

When you change CMake configuration in Creators Project mode, then cmake will 
be run with exactly those changes and nothing more.

In all other cases CMake will be run without *any* configuration-related 
arguments.


Creator will no longer store any configuration changes in its .user file 
anymore (anything that exists there is moved into the initial arguments 
instead). The sole truth about CMake configuration is the CMakeCache.txt file. 
This also means that swiching build directories will result in a loss of 
configuration, something that we tried to avoid earlier. I think overall this 
is an acceptable cost, considering that Creator did not do a great job at it in 
the first place:-)

This also makes the dialog about the CMake configuration and the Creator 
configuration unnecessary and that has been removed. Considering how many 
complaints I had about it, I expect nobody will miss this one;-)


As said before: Please send feedback via the bug tracker or by email! I hope to 
sort out the remaining rough spots in the next couple of weeks.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Debugging different bare metal devices with the same kit

[Tobias Hunger]

Hi Richard,

There is a pretty ugly hack I  creator which you might find useful in your
context.

Define your two devices and your build kit as before.

Then open your build kit in the options menu (Tools>Options). Make sure the
device type is set correctly for your two devices. Right click on the
device selector and open the context menu. Check the one checkbox there to
make the device "mutable".

You should now get a (pretty ugly) device selector in the mini project
target selector (Ctrl-T) whenever your build kit is active.

This functionality has never been polished, so I made sure people do not
run into this by accident:-) The UI is pretty ugly and the UI is not ideal
either,  but it is pretty convenient in some situations.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Fwd: can't parse cmake project

[Tobias Hunger]

Hi there!

Qt Creator is correct in that there are no targets defined anywhere in
the reply CMake generated. You seem to expect that: So is that indeed
something you intended to do? What is the use-case you have here?

Creator treats this case as an error since I could not imagine that
any CMake project would do this, but I learn something new about CMake
every day, so I might have been wrong with that assumption.

Best Regards,
Tobias

On Tue, Mar 31, 2020 at 1:12 PM Gena Bug  wrote:
>
> Hi, Tobias,
>
> QtC prints "Invalid codemodel file generated by CMake: No targets.".
> Indeed, by default there is no targets defined, however I expect to see
> a list of variables on the Project pane. Running QtC cmake-command
> manually and then cmake-gui at this folder gives me the list.
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

[Qt-creator] Fwd: can't parse cmake project

[Tobias Hunger]

Sorry, I somehow lost the mailing list in my reply:

-- Forwarded message -
From: Tobias Hunger 
Date: Sun, Mar 29, 2020 at 7:19 PM
Subject: Re: [Qt-creator] can't parse cmake project
To: Gena Bug 


CMake 3.16 will ise file-api.

On Sat, Mar 28, 2020, 16:55 Gena Bug  wrote:
>
> By default (i.e. call cmake w/o args) the project doesn't add any target
> to build. Could that be the problem?


The esasiest way to test this is to just copy the commands creator
runs into a terminal amd try them that way. Then you will know for
sure whether or not that is the problem.

Are there files in .cmake in your build directory? File-api mode
should have created some files in folders below that. They are in json
and semi-readable, so you might want to check whether the information
in those files makes sense for your project. Feel free to mail them to
me if you are comfortable with sharing that information.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] can't parse cmake project

[Tobias Hunger]

Hi!

On Fri, Mar 27, 2020, 16:26 Gena Bug via Qt-creator <
qt-creator@qt-project.org> wrote:

> Hi!
>
> The latest beta (4.12b2) can't parse a cmake project. The problem may be
> with the project itself -- it's not "modern cmake". However I can
> configure the project with cmake gui/terminal. How can I find the
> concrete problem which causes qtc fail parsing it?
>

Which version of cmake are you using? Creator comes with several ways to
interact with cmake, so this is a important piece of information. For best
results I would recommend to use a current cmake with file-api.

None of these way parses your actual cmake files, so it *should* not matter
what is in there.

Best Regards,
Tobias

>
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Few random questions regarding QTC hacking

[Tobias Hunger]

Hi Alexis,

On Thu, Mar 19, 2020, 15:03 jeandet  wrote:

> Hi,
>
> I started this week to look at QTC code(master branch) to try writing a
> meson build plugin from scratch. I've alredy played with QTC code base
> in the past but long time ago and using qmake.
>
> So first question, is CMake build ready to use? Looks like no. At least
> clang detection/link looks broken:
>
> - with clang 10(packaged) all libs are merged in one so I get loads of:
>

It works for me(TM).

Creator does need Clang 8 though and has not been ported to anything newer
yet. So you will get the same issues with any supported build tool.

Best Regards,
Tobias

>
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Annoyance with 4.11

[Tobias Hunger]

On Thu, 2020-02-20 at 22:45 +1300, Christian Gagneraud wrote:


> The project explorer is a GUI component that assists the user with
> graphically exploring a project.

Actually the project view is meant to show what the build system thinks your
project is. Such a view is necessary to allow for UI operations to manipulate
the project.

Even though it is unlikely that Creator will ever support UI operations to
manipulate CMake projects, its project tree follows the same approach. Source
groups are a part that is important to some users, so they need to be in the
project tree.

> The screenshots i sent recently clearly show a regression, not a
> 'preference issue'.
> 
> Please as well take a note of my comment about cmake plugin being
> immature, my hate of this build system is orthogonal with the problem.

I do not consider the CMake plugin immature, even though it certainly has its
share of quirks. Now that we actually use CMake internally, we are slowly
starting to get rid of those.



> And IMHO the regression nature of this problem (what i refer to as an
> 'annoyance' in my original email) is backed by the fact that it was
> fixed with QtC-4.12. You wouldn't fix a non-problem, would you?

It was not "fixed" in the sense that 4.12 will have reverted to the old
behavior, but you should get much nicer results there -- at least for people
used to how visual studio represents CMake projects.



I regret that you are not happy with the commercial offering. Please inform your
sales representative about that, there is very little we can do about that from
here. Sorry.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Annoyance with 4.11

[Tobias Hunger]

On Tue, 2020-02-18 at 13:54 +1300, Christian Gagneraud wrote:
> Hi there,
> 
> Just updated to 4.11, and with a CMake project, i've noticed (what is
> for me) regressions in the project explorer.
> 1. path to subdirectories are shown using backslash, which looks
> really ugly on Linux
> 2. this sub-dir path contains nested directory that you need to expand
> one by one, so there's now one extra node to expand (the path node)
> 3. now there are 'Header files' and 'Source files' sub nodes, that's
> yet another nesting level that need to be expanded.
> 4. sometimes, there's nested duplicated sub-nodes, see attachment
> 5. All of the above seem to be random, on my project i have all of the
> above but not always

I would guess that you define source groups in your CMakeLists.txt files.

Could you please consider to try a 4.12 snapshot and check how things look
there?

A screenshot from 4.12 would help a lot since that changed the icon for source
groups so that they are actually distinguishable from folders;-)

It also does proper nesting of source groups, which will get rid of the
backslashes in the source group names.

> The above seems to be related to the introduction of 'CodeBlocks' generator?

No, that is very much unrelated. You do not need the CodeBlocks generator if you
use CMake > 3.7, but it does not hurt to have it either.

> Is this a known issue? Anyone else having these issues? Am I the only
> one to think that this is a bad UX regression?

> Thanks,
> Chris
> ___
> Qt-creator mailing list
> Qt-creator@qt-project.org
> https://lists.qt-project.org/listinfo/qt-creator

___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Status of Python Extensions in QtCreator

[Tobias Hunger]

Hello Jan,

On Tue, 2020-02-04 at 12:44 +, Miethke, Jan wrote:
> So is there any other way to set a kit without the gui and without modifying
> the ~/.config/QtProject/qtcreator/*xml files.

If you have static information, then you might get away with using the sdktool.
That's a binary used by the Qt installer to register things with Qt creator. The
sdktool is basically a very thin command line wrapper used to create the
necessary XML files in a installation wide place.

I recommend configuring a kit in Creator via the UI and then checking the .xml
file for the values you need. sdktool --help should get you started with the
command line.

For more dynamic configuration you will currently need to use C++ code.

Best Regards,
Tobias

___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Status of Python Extensions in QtCreator

[Tobias Hunger]

Hi Jan,

On Tue, 2020-02-04 at 09:24 +, Miethke, Jan wrote:
> Hi all,
> 
> i would like not know the current status of the Python Extensions in
> QtCreator.
> Do you plan to distribute the plugin in future with the QtCreator?

I am not aware of a plan to do so (or not;-).

> It would be very useful for my work to add/modify kits via script.

Even with this plugin being included: It does not offer much in the way of API
that is accessible from python. Deciding what to expose to python and in which
way to do so will take a while.

Best Regards,
Tobias

> 
> Bitte beachten / Please note!

Nope, I will not bother to read all that stuff!

___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Setup of CMake based projects

[Tobias Hunger]

Hi Cornelis,

thank you for those suggestions, I really like them.

Is this what you had in mind?
https://codereview.qt-project.org/c/qt-creator/qt-creator/+/276884

Best Regards,
Tobias

>
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Info how to add multiple RunConfigurations

[Tobias Hunger]

Hi Filippo,

On Fri, Oct 4, 2019 at 12:15 AM Filippo Cucchetto
 wrote:
> Now i'm facing another issue: i've all my run configuration with both 
> executable and working directory setup
> but the Run button is disabled and i cannot run them. The runconfigurations 
> are enabled (by breaking inside
> the setEnabled function). Any idea?

IIRC there is no need to enable/disable RCs explicitly. Try removing
that code:-)
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Setup of CMake based projects

[Tobias Hunger]

Hi Cornelis,

On Thu, Oct 3, 2019 at 11:56 PM Cornelis Bockemühl
 wrote:
> QtCreator is version 4.4.1, CMake is version 3.14, on a Linux system
> (OpenSuse Leap 15.1). Versions on my Windows 10 system are similar, but
> I don't see them here right now.

The CMake version is great, it already has fileapi! Unfortunately your
Creator is too old to make use of it.

For the CMake version you use, the 4.11 snapshots will work best. You
can find binaries over at
https://download.qt.io/snapshots/qtcreator/4.11/ , so no need to build
this yourself.

You really want fileapi, that is way more stable than server-mode,
especially when you run of and just run cmake yourself while creator
is running. CMake does not like that at all:-)

> >Where are those (relative to the source directory)?
>
> They are separate folders, like parallel to the sources folder, and
> also debug and release are separate. It's for me the most sensible
> setup - and with ParaView I think it's not possible otherwise.

Do they match the naming scheme creator has for those directories?

> >Why do you chose to use cmake-gui? Is that just due to the filedialog?
> >I am asking, because I am actually pretty happy with the configuration
> >dialog in creator nowadays:-)
>
> Well, if a project is more than just 3 lines of code I would definitely
> not say so ;-)
>
> With the cmake-gui you have a very nice "interactive setup" process!
>
> - start the cmake-gui, choose source and target directories

... already done for you in Creator ...

> - press "configure" and choose a generator (typically ninja in my case)

... generator is already defined for you in creator ...

> - if you start with a brand new target directory, the system will do
>   all the typical cmake checks and work it's way through the source
>   CMakeLists.txt
>
> - after that, you have in the lower part of the screen the log, and
>   in the upper part you see all the now defined cache variables, with
>   everything new in red (which is all during the first run). In the
>   QtCreator you see NOTHING as long as there was not at least one
>   error-free configuration run

That is a good point: The configuration run output is not visible in
project mode:-/

> - in the log you see critical things also in red, so you can directly
>   check what is going on. Like: cannot find ParaView project, with
>   some explanations that you see also in the QtCreator log output -
>   only not in red, so you have to check much more in detail.

Creator prints the changed values in italics, not in red.

> - the missing ParaView_DIR is also already in the list, with a value
>   of ParaView_DIR-NOT-DEFINED (or similar). Since that is a folder,
>   you press on a little [..] button at the end of the line and get
>   a file folder. In QtCreator you have to extract the name of that
>   required variable from the log, add explicitly a variable with that
>   name, leave the QtCreator to find out the full path of the ParaView
>   build you want to refer to, copy the line and paste it in.

Creator will offer a file selector as well -- when the type is set
correctly in CMake. Well, it needs to be able to read the settings for
that to work.

> - some projects also have variables that are actually "options", with
>   a default value, but as long as there was no successful first run,
>   you also cannot see these options in QtCreator.

As I said before: That should not happen:-) I'll check on Monday when
I am back in the office.

> - after this, you press "configure" again, and all the so far "done"
>   variables will be black in the upper window, but some new ones
>   that may come in because of some settings that you changed are now
>   red, so you can review them again, change if something is not yet
>   like you need it, and "configure" again - until everything looks
>   fine. (You see that I am talking here about large projects, not
>   about 3-liner projects with maximum 1 setting!)

Same workflow in Creator;-)

> - this is actually some kind of interactive iteration loop, until
>   the result is ok. Then you press "generate", leave the gui, and
>   create your code with "ninja". Or try to switch into the QtCreator...

Just hit build:-)

> After this you will definitely be excited how easy this thing was
> going - what used to be a tedious configuration process with other
> tools earlier! But then comes the disappointment: If you want to
> have a separate setup also for the debug version now, there is no
> way around doing the entire process once again! And if you see that
> there is now a new version of your project sources online, download
> and you want to build it "in the same way" - same thing: again you
> go through the entire process twice - once for the release, once
> for the debug.

You have the same problem in creator:-/

> If you think you can simply copy the CMakeCache file to the other
> folder, start cmake-gui again and just adapt things like changing
> "Release" into "Debug" and leave all the options - 

Re: [Qt-creator] Setup of CMake based projects

[Tobias Hunger]

Hi Cornelis,

first of all: Thank you very much for taking the time to provide your
feedback! May I ask which version of CMake and Qt Creator you use?
Creator has three very different ways to interact with CMake, based on
the features that are available there -- which mostly depends on the
version number.

I am currently on a tablet and can not check the exact names of
things! So please grant me some slack if the strings in the UI do not
match my recollection!

On Thu, Oct 3, 2019 at 10:29 AM Cornelis Bockemühl
 wrote:
>
> Currently I am mostly working on CMake based C++ projects (including Qt), and 
> the QtCreator is by far my favorite GUI for development.

Thanks!

> However, the cooperation between CMake and QtCreator feels in many ways a lot 
> like a "clash of cultures", but I also see a lot of progress during the past 
> years - which I appreciate a lot!

There is definitely a clash:-/

> But when I heard that CMake will eventually become the main build manager in 
> QtCreator, I thought I should post here my "favorite culture clash" 
> situation. I found a workaround that seems to be functional, and since I just 
> did it again, I can explain it step by step:

I would argue that it already is the most widely used project type:-)

But then I do hope it will get even more important now that Qt is
probably going to end up being built with CMake. It does help a lot
that we can now build Qt Creator with CMake, so I can actually use the
integration myself. There are still a lot of paper cuts -- and those
are hard to detect when you only ever open some test projects and
never really work with those!

[...]

> 2) Choose and generate target directories for release and debug code.

Where are those (relative to the source directory)?

>  Go to the one and to the other, and in both do a first CMake setup still 
> outside of QtCreator, with from the command line entering "cmake-gui  CMakeLists.txt of the project>".

Why do you chose to use cmake-gui? Is that just due to the filedialog?
I am asking, because I am actually pretty happy with the configuration
dialog in creator nowadays:-)

> 3) Go through the "configure" loop within that CMake GUI. In the given case 
> this means to enter a build type manually (Release or Debug), and you get a 
> complaint about ParaView not found: you need to enter a path in the 
> ParaView_DIR variable. This is easy because you can use a file dialog for 
> that purpose.
ext editor where you put in things like the ParaView_DIR entry, ie the
path where the release or debug code of your own ParaView compilate
resides - you will need that information later, and copy will be
a shortcut.
>
> 5) Now finish the CMake GUI ("generate" is not required now) and open a new 
> session in QtCreator
>
> 6) Load the CMakeLists.txt of the new project in that QtCreator session. In 
> the project setup, disable all build types except release and debug (ok, 
> that's what I am doing...) and change the target paths to where you already 
> did your initial debug and release setup with the CMake Gui.

Creator *should* detect existing builds, but it only tries directories
close to those it would create itself, so it might just be missing
yours. Could you try to adapt your default build directories in
Tools>Options>Build & Run>Somewhere to match your naming scheme before
opening the project for the first time? Do your build directories get
picked up when you change that?

If Creator does not pick up your build directories: At the very end of
the list of possible Kits there should also be a button labeled
something like "Import build"(?). Could you please try that to import
the two builds of yours? Does that work better?

> Note that here are already CMakeCache files ready that SHOULD normally be 
> used as a starting point for any further configuration efforts - like through 
> the QtCreator project setup. But at this point, QtCreator is suffering from 
> some "not-invented-here syndrome"! Because this is how the story continues:

[... Configuration UI trouble ...]

That should actually only happen with cmake >=3.7.0 and <=3.10.0 IIRC.
Early server-mode versions did not provide the necessary information
to display something, but that was fixed sometime in 3.9.x IIRC.

Could you try to upgrade your CMake if you are in that range?

[... Paraview setup...]

My assumption is that users will just create Kits for things they use often.

If you work a lot with paraview, you could clone one of your existing
kits and add the required settings there: Each has a CMake
Configuration section (among other things;-). You can also check the
other settings while in Tools>Options>Kits>Kit :-) If you do not use
CMake older than 3.7, then you definitely do not need the CodeBlocks
extra generator. If you do not use Qt 4, then you can remove the
QMAKE_PATH(?) setting from CMake's Configuration as well.

Any build configuration will automatically get all the kits' CMake
configuration plus the CMAKE_BUILD_TYPE appropriate for 

Re: [Qt-creator] Info how to add multiple RunConfigurations

[Tobias Hunger]

Hi Filippo,

On Wed, Oct 2, 2019 at 11:31 PM Filippo Cucchetto
 wrote:
> i'm working for adding support to the Nimble build system for Nim but i'm 
> struggling understanding how to add multiple RunConfigurations.
> To be honest i'm a little confused in how  Targets, Kits, BuildInfo, 
> BuildConfigurations and BuildTargetInfo work together
> Honestly i thought that the missing piece fwas calling 
> Target::setApplicationTargets() but it doesn't seems enough.

I just realized that I have no idea how that works nowadays:-) But I
think you are probably missing a RunConfigurationFactory that feels
responsible for your kind of project or something.

> So in my use case (one project with multiple executables being built (like a 
> CMake project) what should i do?
> I though: one or more kit, each kit with one target, one target with multiple 
> buildinfo e multiple, builtargetinfo.

You have a Project.

A project has a list of Targets.

Each Target has *exactly* and *always* one Kit (and each target will
have a different Kit), as well as a list of BuildConfigurations,
DeployConfigurations and RunConfigurations. Think of it as a bit of
glue that connects a Kit, the Project and the *Configurations. That's
all there is to it.

The Build-/DeployConfigurations hold a list of BuildSteps.

It's not that complicated:-)
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] QtC 4.10 gets highlighted by antivirus software

[Tobias Hunger]

On Thu, Sep 19, 2019 at 10:37 AM Richard Weickelt  wrote:
> We have observed similar issues at work multiple times and the options were 
> usually:
>
> 1. Try to find the offending pattern in the file, try to avoid it by 
> compiling with different settings, modifying the source code, or if it is a 
> text file, try to modify the content somehow.
> 2. Contact the antivirus vendor and request an exemption.
> 3. Ignore the problem and wait until users contact the antivirus vendor.
>
> Reading the comments in https://bugreports.qt.io/browse/QTCREATORBUG-18701 
> which was not even evaluated I assume, the Qt Company usually chooses option 
> 3.

There are dozens of anti virus engines out there with even more
databases driving them. You change something to avoid misdetection in
one AV and another one starts to raise an alarm.

So 1 is out, it is one huge game of whack-a-mole that only works when
you only have one or two AVs that you need to care for. Qt Creator
users use a ton of different AV solutions.

I have tried to contact AV vendors a couple of times before: Each
vendor has its own process which is hard to find and those processes
usually lead nowhere since I can not provide a serial number or
receipt or something to proof that I actually bought the product I
want to get fixed.

So 2 is out, too.

That leaves option 3 only:-/ Yes, I do not like that either.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] JSON wizard: build systems and sub-projects

[Tobias Hunger]

Hi Christian,

On Mon, 2019-05-13 at 13:03 +1200, Christian Gagneraud wrote:
> On Mon, 13 May 2019 at 10:38, Christian Gagneraud  wrote:
> > One last comments, sorry to sound negative, but currently all project
> > templates are a massive pile of copy/paste, with complex and error
> > prone macro/javascript expressions.
> > That is clearly a sign that something is "far from ideal".
> > I'm not moaning or anything, i'm really just trying to help this
> > wizard thing going. I can't wait to be able to do with qbs/cmake what
> > i can currently do only with qmake.
> 
> 
> I'm sure i'm not the first one to think that the wizard could use
> python instead of JSON.
> I guess the idea with JSON was to have something declarative (and
> decoupled from QtC internal?), but the introduction of macro and
> javascript shows that there is a need for logic too.
> Python could help here.
> 

This is how we ended up with the JSON wizards (at least as I remember how
things happened, please correct me if I misremember something!):

Creator used to only know C++-based wizards when it started.

At some point somebody had the great idea of writing a C++ wizard that read
a bit of XML data to have one custom page in an otherwise hard-coded series
of pages. That enabled some wizards to actually be implemented using a bit of
configuration instead of having to do custom C++ code. That was a huge step
forward for creator.

At some point I wanted to write another wizard. I could have used an
XML wizard for what I needed, but I needed to disable one of the default
pages it had and I also wanted two custom pages. So I decided to extend the
XML wizard.

I wanted to be able to have a selection of different pages
(written in C++) available for my new wizard. Plugins should be able to
add pages to the pool of possible pages. A user should be able to combine
these pages using a configuration file (using each page several times if
needed!) and pass extra information to each instance of these pages. One of
these pages was supposed to be a custom page where users can arrange line
edits, etc. to collect arbitrary data from the user.

When I realized that I was breaking the existing XML wizards while redoing
the XML wizard, I decided to switch over to a different format. This would
prevent me from breaking XML wizards users might have written and used for
themselves. I went for JSON instead: It looks similar to QML and readily
supported by Qt. This is a very simple configuration file without any logic,
so there is no need for something as complex as QML!



At the same time Creator got a new feature: The macro expander. It allowed
to use certain variables all over Creator. This included things like the
current time, etc. Some of the existing XML wizards used exactly that kind
of information e.g. when generation comments in the generated files. It was
a pretty obvious idea to use the macro expander in the JSON wizards instead
of redoing the same feature with custom code.

Users liked the macro expander, but wanted to be more flexible with the
output that generated. They wanted to e.g. lowercase a string and do similar
things. So that functionality was added to the macro expander. The wizards
also made us of this functionality in the macro expanders. But the
wizards soon needed quite a few different string manipulations and it became
tedious to implement all of them in the macro expander and especially to
come up with good names for them. So I got the idea to have a macroexpander
that accepts some simple JS strings instead -- replacing all the custom
string manipulation macro expanders. That was flexible enough to handle
basically all the string manipulations any user would ever need and JS is
easy to add to a Qt application. So we ended up with JSON wizards that
supported some JS...



People got surprisingly creative using JS in the JSON wizards! They just used
JS and the custom pages to implement all their logic instead of having their
plugins provide special pages written in C++ and just referencing those pages
in their wizard configuration files.

And this worked surprisingly well, too: We got rid of almost all the C++ based
wizards that were shipped with Creator, leaving only the JSON wizard and the XML
wizard (for compatibility).

Yes, in hindsight I should have opted for QML to define the wizards -- or
something equally powerful, but I completely misjudged where that train
was headed.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] JSON wizard: build systems and sub-projects

[Tobias Hunger]

Hi Christian,

reading my last mail again it was rather short and sounds harsher than intended.
Sorry for that. I did not intend to slight you or your work, it is just that I
get very lazy when composing mails on my phone.

On Mon, 2019-05-13 at 10:38 +1200, Christian Gagneraud wrote:
> On Mon, 13 May 2019 at 05:27, Tobias Hunger  wrote:
> > > 2. "Define Build System" page.
> > > Currently the boiler plate attempt to identify the "Project type" to
> > > generate, but doesn't rely/use the semantic of the
> > > "supportedProjectType" above.
> > > Instead they use the HasPlugin concept to map the build system tool
> > > (aka, "qmake", "qbs", "cmake"), which is actually equivalent to the
> > > project type (the wizard doesn't care about the tool, it cares about
> > > the project manager it targets: CMakeProjectManager.CMakeProject,
> > > Qbs.QbsProject, ...).
> > 
> > Sure. Disable qmake and qbs support in Creator and see what happens:-)
> 
> !?!

I wanted to point out that the wizard has a hard-coded list of project types it
supports. Creator also has a list of build systems it supports, which is dynamic
and depends on the plugins that are loaded.

At the "Define Build System" page that dynamic part is the important one: The
wizard should not offer build systems that are not supported by the current
Creator instance, even though it would support these build systems in other
creator instances.

So IMHO the wizard does the right thing here by relying on the loaded plugins
and not on the supportedProjectTypes.

> What i'm trying to say here, is that for each project manager, the
> wizard plays with 3 information, let's take qmake:
> PluginId => QmakeProjectManager
> ProjectTypeId => QmakeProjectManager.QmakeProject (as defined by the plugin)
> BuildSystem => "qmake" (which could be "some random alias" since this
> is internal to the wizard, and is just used to multiplex the
> generator)

That is correct.

> Currently JSON wizards for subprojects are not working, only the
> built-in qmake one work (and AFAIU they need to go).
> So something has to be done to solve this issue.

I am aware of that and appreciate you looking into this problem.

This will need more than just the wizard part to work though. E.g. CMake has no
way to add new files into existing CMakeLists.txt files, so a wizard will not be
able to do much in that case.

> What i'm proposing here, is to forget about these 3 facets, and use
> only one way to talk about projects: The ProjectTypeId.

I got that.

But you will need to check whether a plugin is currently loaded and you will
need to have a user-visible name for that build system and you need the. Where
do you get that information from?

Do you offer a registry in one of the plugins to hold that information
somewhere?

Currently we are having the information in the wizard directly has the charm
that it becomes pretty easy to copy one of ours and modify it for a new build
system.

> I do not care about the fact that 'QmakeProjectManager' plugin
> provides 'QmakeProject', and that it uses "qmake" as a build system.
> What i care, is that my JSON wizard can generate stuff for
> ProjectTypeIdX, ProjectTypeIdY and ProjectTypeIdZ, all the rest is
> implementation details.
> 
> Injected into wizard:
>  - availableProjectTypes

That becomes tricky due to the limited logic that the wizards support: They only
do string replacement. Injecting anything more complex than a single variable is
not trivial.

Note that Eike has been working on making it easier to pass complex objects to
JS, so this might be easier now than it was just a month ago.

>  - parentProjectType (in case of sub-project)

That is straight forward to do:-)

> Selected by user:
>  - ProjectType (in case of top project, aka. %{BuildSystem})
> Defined by wizard:
>  - supportedProjectType
>  - enabled = !intersection(availableProjectTypes,
> supportedProjectType).isEmpty()
> 
> This would make the writing of project wizards IMHO more consistent,
> but would require quite some changes, i agree with that.

Changing things is of course completely fine:-)

> And concerning the case "Sub project from main menu", Wouldn't it be
> better to ask for the parent project on the first page, not the last
> one?
> Actually, maybe the first page should only be about project parenting
> and build systems, since they are strongly coupled

I am not so sure: At the last page you get a summary of everything and thus have
much more complete information on what exactly will get added to the project. I
see some value in having that information when deciding where the whole thing
should go in the project.

But I also see value in doing th

Re: [Qt-creator] JSON wizard: build systems and sub-projects

[Tobias Hunger]

Hi Christian,

On Sun, May 12, 2019, 12:04 Christian Gagneraud  wrote:

> Hi there,
>
> In my attempt to add a unified "subdirs" project and make all projects
> templates "subproject" friendly, I discovered a few grey area, and
> would like to discuss what they are how we could fix them.
>
> 1. "supportedProjectType" and "enabled" properties are currently
> redundant (in the way they are used), consider:
> "supportedProjectTypes": [ "CMakeProjectManager.CMakeProject",
> "Qbs.QbsProject", "Qt4ProjectManager.Qt4Project" ],
> and
> "enabled": "%{JS: value('Plugins').indexOf('QbsProjectManager') >= 0
> || value('Plugins').indexOf('QmakeProjectManager') >= 0 ||
> value('Plugins').indexOf('CMakeProjectManager') >= 0}",
>
> They both express the same thing, but using different approaches. IMHO
> enabled should be used to express further conditions on top of the
> supported project types.
>


They express slightly different things.

supportedProjectType says which build systems a wizard can support. This is
hard-coded into the wizard.

enabled is used to present which build systems the current Qt Creator
installation currently supports. This is dynamic as users can and do
disable plugins.

The wizard needs to know both.

2. "Define Build System" page.
> Currently the boiler plate attempt to identify the "Project type" to
> generate, but doesn't rely/use the semantic of the
> "supportedProjectType" above.
> Instead they use the HasPlugin concept to map the build system tool
> (aka, "qmake", "qbs", "cmake"), which is actually equivalent to the
> project type (the wizard doesn't care about the tool, it cares about
> the project manager it targets: CMakeProjectManager.CMakeProject,
> Qbs.QbsProject, ...).
>

Sure. Disable qmake and qbs support in Creator and see what happens:-)



5. Ideas to achieve that
> I did some quick hack in the ProjectNode, there is a "buildKey()"
> there, that returns the build target key, so i added a
> "projectTypeKey()" that returns the project manager's project ID
> (CMakeProjectManager.CMakeProject, ...), and which is injected wizard
> environment.
>

That could help when starting the wizard via the context menu. That is
unfortunately not the only way to trigger this wizard.

With the above and proper macro nesting, it should be possible to
> define the following wizard options:
>  - IsSubProject, IsTopProject
>  - HasCMake, HasQmake, HasQbs

 - IsCMake, IsQmake, IsQbs
>

Please do not hardcore the list of possible build systems! There are more
plugins out there 5han those that are shipped with Creator.

  - top project:
> by comparing the "Build system" page choice
>   - sub-project
> by comparing the injected "projectType" (same values as above)
>
> The HasFoo, IsFoo and ProjectType could all rely on the project
> manager key. No need to deal with project manager key, plugin names
> and build tool names.
>

I disagree.

These low level details are exposed so  and that *any* plugin can have
wizards and so that the wizards we ship can be copied and modified easily
for non-standard plugins.

Best Regards,
Tobias

>
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] [External] Re: Missing files in CMake project. Or adding special source files.

[Tobias Hunger]

Hi Toralf,

On Thu, 2019-05-09 at 13:15 +0200, Toralf Lund wrote:
> > > I there anything I
> > > can do to make the CMake project manager recognise "special" files that
> > > are listed in the CMake config?
> > You could list them as sources. CMake tends to ignore most file types, so
> > they
> > are safe to add as sources, but cmake will still report them.
> 
> It's not clear to me what exactly you mean by that.

target_sources(FooTarget PRIVATE ${PROTO_INPUT}) or something along those lines.

This is of course provided that ${PROTO_INPUT} does not contain files that cmake
will mistake for real sources and actually try to build:-)

>  Our "protobuf" files 
> are mentioned already in that CMakeLists have statements like
> 
> set(PROTO_INPUT MonitoringHeader.proto MessageHeader.proto
> MetaHeader.proto)
> 
> protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS ${PROTO_INPUT})
> 
> Doesn't that mean they are already listed as sources? Or are you 
> referring to some other CMake mechanism?

I would expect that function to set up some custom commands. Those will take
inputs and put their results into the sources. I would not be surprised if those
showed up in the project tree (maybe filtered away since the files are probably
marked as generated, check the funnel icon).

The inputs on the other hand will probably not show up.

> 
> > >   Also, how about making manual additions
> > > to the file list? The "obvious" functionality appears to be disabled for
> > > CMake projects...
> > Like adding files into an existing CMake project?
> 
> No necessary. I'm also thinking about files that aren't being built or 
> used as sources for build, but are kept with the project for some 
> reason. One example might be documentation or config files that you want 
> to include in software packages generated independently of cmake. The 
> CMake project won't need to know about these, but it's convenient if Qt 
> Creator is ready to edit them, so as to speak.

The idea behind Projects mode is to show the view the build system has of your
project. I think having such a view is valuable and having too many unrelated
files listed in it will reduce that value. Some exceptions are fine (e.g. header
files which often were completely missing when using cmake) of course, but I do
not want to make the tree to configurable.

If you want a more filesystem based view on your sources, then just use the
filesystem view instead.

If you want to navigate your sources, then check out the locator. Just hit ctrl-
K and start typing the file name, which is way faster than using the project
tree.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Missing files in CMake project. Or adding special source files.

[Tobias Hunger]

Hi Toralf,

On Thu, 2019-05-09 at 09:58 +0200, Toralf Lund wrote:
> I'm using qt-creator with a CMake project that, among other things, 
> contain some source files of somewhat uncommon types. One example is 
> "protobuf" message definitions, which use CMake functions listed in 
> https://cmake.org/cmake/help/v3.14/module/FindProtobuf.html, but there 
> are a few others, too.

Creator asks CMake for the files that are part of the current configuration and
then proceeds to manually add header files.

So I see two ways forward to improve the situation, but both require code:

1) CMake can be improved to more accurately report which files it will work on

2) Creator will just add any file to the project tree that cmake does not
handle.

The second one will probably work better in general.



>  I there anything I 
> can do to make the CMake project manager recognise "special" files that 
> are listed in the CMake config?

You could list them as sources. CMake tends to ignore most file types, so they
are safe to add as sources, but cmake will still report them.

>  Also, how about making manual additions 
> to the file list? The "obvious" functionality appears to be disabled for 
> CMake projects...

Like adding files into an existing CMake project?

IMHO functionality like that needs to be implemented in CMake itself. That is
the only place that can keep this functionality in a good working condition.
Trying to parse CMake syntax in creator is way too error prone for me to feel
comfortable doing.

Having said so: In theory Creator should have backtrace information, which
enables it to open a CMakeLists.txt file that is probably not entirely off. But
that information got removed from CMake server-mode again, so it is not
available right now. Maybe we will get it back when we move to CMake's latest
and greatest IDE integration based on files.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] "cmake -E server" messages appear when switching to a new file; General Messages pane opens

[Tobias Hunger]

Am Mittwoch, den 03.04.2019, 12:24 +0200 schrieb Andre Hartmann:
> Sigh. Wasn't the idea of using CMake instead qmake to have *less* 
> maintenance effort?

Creator needs to support CMake projects as long as a lot of people want to open
CMake projects in Qt Creator. This work is entirely independent of what
buildsystem is used to build Qt with.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] "cmake -E server" messages appear when switching to a new file; General Messages pane opens

[Tobias Hunger]

On Wed, 2019-04-03 at 11:42 +0200, Toralf Lund wrote:
> Hi,
> 
> I just upgraded to Qt Creator 4.8.2, and after this I started getting 
> lots of messages like
> 
> Running "/usr/bin/cmake -E server --pipe=/tmp/cmake-vd0eaO/socket 
> --experimental" in my-build-directory
>
> in the General Messages pane. It seems like another one of these lines 
> appear every time I switch to a new file in the editor. It happens even 
> when the files are not part of a CMake project, and the active project 
> is not using CMake. But a CMake project has been loaded.


That is unexpected. One server should just run all the time without any need to
restart for each cmake project that is open.

Please consider to file a bug report.

Best Regards,
Tobias

PS: The newest CMake comes with a replacement mechanism for server mode, so a
major rewrite of the entire cmake support is necessary:-/

-- 
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Shared project settings for CMake project

[Tobias Hunger]

Hi Toralf,

On Fri, 2019-03-29 at 11:29 +0100, Toralf Lund wrote:
> Is there a way to share Qt Creator project settings when working on a 
> CMake project? I'm thinking about something like what's described for 
> QMake projects in 
> https://doc.qt.io/qtcreator/creator-sharing-project-settings.html. The 
> idea would be to check the "shared" config into a GIT repository.
> 
> It looks like the CMake equivalent to a .pro.user file is 
> CMakeLists.txt.user, so you might think CMakeList.txt.share would have 
> the same role as the .pro.shared file. I tried creating such a file, 
> though, and as far as I could tell, it was not read at start-up.

It *should* be read, but many settings are not easily transferable between
different Qt Creator instances and these tend to get silently dropped.

Basically anything with a UUID in the path to the setting will not work anywhere
but no your own machine. This effects everything below a Kit/Target, incl. all
Build-/Deploy- and RunConfigurations.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] cmake w/Windows

[Tobias Hunger]

On Sat, 2019-01-26 at 11:52 -0500, Andy wrote:
> I'm having problems getting cmake setup with Qt Creator under Windows.
> 
> - I have cmake installed from the official release (3.13.3)
> - cmake is in the PATH
> - in Kits->CMake I set the path manually since it is not auto-detected
> - in Kits->Kits, I select my (auto-detected) kit to MSVC2017 64bit
> - for cmake generator I select NMake Makefiles & Codeblocks
> 
> I get this error:
> 
> error: Failed to activate protocol version: "CMAKE_GENERATOR" is set but
> incompatible with configured generator value.

This looks like you are trying to use an existing build directory?

Check the CMakeCache.txt file in there: That should contain a CMAKE_GENERATOR,
which apparently is not the one you set up creator to use.

Try with a fresh build directory or try to match up the generator set up in
Creator and the one used in your build directory.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Mime performance

[Tobias Hunger]

Hi Orgad,

Everybody around here is waiting for christmas holidays, so do not
expect much to happen in the next few weeks!

On Fri, Dec 21, 2018 at 11:48 AM Orgad Shaneh  wrote:
> Building the project tree for qtcreator.pro takes about 5 seconds, on which 
> the GUI is blocked.
>
> I profiled setRootProjectNode(QmakeNodeTreeBuilder::buildTree(this)) in 
> QmakeProject, and found out that mimetype resolving is the heaviest operation 
> there.
>
> Is it possible to cache mimetype results? Or at least have a cache for common 
> extension such as cpp/cxx/c/h/hxx?

Sure, ideally somewhere inside the mimetype code itself. I am pretty
sure qmake is not the only kind of project that can benefit from
speeding up detection of common file types.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

[Qt-creator] Stepping down as maintainer of project management in Qt Creator

[Tobias Hunger]

Hello everybody,

not having lived up to the role of maintainer of the project management 
code in Qt Creator for a while now, I would like to formally step down. 
It has been an honor to work in this role in such a central area of the 
Creator codebase.

I want to propose Christian Kandeler to take over. He is a capable 
developer with a deep understanding of the code involved and I am sure 
he will do a terrific job going forward.

Best Regards,

Tobias


___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Qt Creator ignoring gcc compiler in kit

[Tobias Hunger]

Hi Davide,

On Wed, Dec 19, 2018 at 12:01 AM Davide Coppola  wrote:

> Everything is fine with Clang, but also with GCC when using CMake or Qbs
> as build system.
>

For qmake you will need to use one of the work-arounds I suggested in my
earlier mail.

The alternative is to use a different build system. Note that we will not
invest in qbs going forward.


> Anyway, I created https://bugreports.qt.io/browse/QTCREATORBUG-21751 to
> provide more details.
>

Thanks, this is not the first bug report about this issue and I consider it
out-of-scope for creator.

Creator does support switching compilers on build systems that support this
and already implements magic to enable limited support for in qmake.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Qt Creator ignoring gcc compiler in kit

[Tobias Hunger]

Hi Davide,

On Mon, Dec 17, 2018 at 4:40 PM Davide Coppola  wrote:

> I can't manage to get Qt Creator to use an older compiler on Linux using
> kits.
>

The toolchain in the kit is mostly for use in C++ code model. The actual
build system is told what was set up -- if that is possible.

Which build system are you using?

Qmake is the odd one out here: It tends to hard-code compiler executable
names into its mkspec files and there is no reliable way to override it. So
this is kind of expected for qmake...

To have qmake pick up a non-default named compiler, you can try two things:
* Change the mkspec
* Create a folder somewhere, put a symlink called gcc/g++ into it and have
those links point to whatever gcc you want. Then set PATH to include your
folder before anything else that includes a gcc/g++ binary.

I hope this helps,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Deploying to "Embedded" Linux?

[Tobias Hunger]

On Mon, Nov 26, 2018, 21:21 Jason H  I read http://doc.qt.io/qtcreator/creator-deployment-embedded-linux.html
>
> I wish to use my Mac to deploy to a RaspberryPi. However I don't think
> this is supported. The Boot2Qt stuff at least does not support OSX (Only
> Windows & Linux are supported). I used a amazon linux server to build the
> boot2qt image. But for application development I don't want to tave to use
> linux, or a VM. I want to use my mac.
>
> In the web page above, it looks like it assumes the host is compiling and
> pushing the compiled image to the device. I was hoping there was a way to
> use Qt to copy the project to the device, and build it there, so that I
> don't need to mess with cross-compilers on my system?
> scp -r project/* pi@target:project
> ssh pi@target -c "cd project && qmake && make -j 4  && ./project"
>  (how to attach debugger?)
>

It's not a dumb idea, but it will not work too well:

Builds are slowed down by the constant copying, the code model has no
access to the headers and will break, jumping to errors will break, and
more.

Remote compilation has been a much requested feature. I would like to
implement that, but I see no realistic chance to do so anytime soon:-(

To do this cleanly creator would need to abstract away file access so that
we can redirect that to a VM/host/container/etc. That will be a very
invasive change, since creator always everywhere assumes that file access
is local.

Best Regards,
Togias

PS: Remote compilation has been done before by wrappers around qmake/make
to run the same command on a remote machine and mapping file paths in the
output back to the host. You also need to have the sysroot of the device
available in the device for the code model.

>
> Or is this a dumb idea?
>
>
> ___
> Qt-creator mailing list
> Qt-creator@lists.qt-project.org
> https://lists.qt-project.org/listinfo/qt-creator
>
___
Qt-creator mailing list
Qt-creator@lists.qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] kit with sdktool that has empty cmake configuration

[Tobias Hunger]

Hello,


On 15.11.2018 16:15, Christoph Mathys wrote:
> Hi,
>
> I use sdktool to create all kit configurations that we use internally
> (debugger, cmake, toolchain, kits). Unfortunately, I still need to
> resort to sed to delete an empty value from the cmake argument list.
>
> My call to sdktool is about the following:
> sdktool addKit --id kit_gcc49_cmake \
>  --name "Gcc 4.9 cmake" \
>  --debugger gdb_7_11 \
>  --debuggerengine 1 \
>  --Ctoolchain ProjectExplorer.ToolChain.Gcc:tc_gcc49 \
>  --Cxxtoolchain ProjectExplorer.ToolChain.Gcc:tc_gccpp49 \
>  --cmake cmake \
>  --devicetype Desktop \
>  --cmake-config ""
>
> Leaving out --cmake-config will not write the relevant valuelist
> "CMake.ConfigurationKitInformation" to the file. QtCreator will then
> default to some stuff that we don't want. Passing an empty string as
> above creates the list with an empty -node. Leaving that node
> inside the configuration leads QtCreator to complain with:
>
> CMake configuration changed on disk.
> Key CMake Project
> 
When does this show?

That message is supposed to be shown when Creator and CMake disagree on 
the settings used in a cmake build directory.

So if you did set up your build directory before, then this is expected.
> Sidenote: sdktool and QtC seem to disagree on the type for debugger 
> EngineType:
> sdktool: 1
> qtcreator: 1

Please report a bug about stuff like this!

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Qt Creator plugin API question

[Tobias Hunger]

Hi,

On Fri, Oct 12, 2018, 14:01 Tino Pyssysalo  wrote:

> This is in fact needed in https://bugreports.qt.io/browse/QTPM-1475 to
> improve prioritizing tutorials and examples in Qt Creator Welcome screen.


Please do not post links to private bugs on public mailing lists. That is
not at all helpful.

> Now

> , we have a long list of highlighted examples in alphabetical order, but
> new users have no idea which one to choose. Wed like to show 3-5 most
> relevant examples and hide others behind some More button. To set the
> priorities, we need to know, which ones are the most popular and that's
> exactly what telemetry could provide us.
>

You are substituting a didactic concept with metrics: Hiding information
for new users based on metrics samples from a different group of users is
not going to help new users.

I would greatly prefer having one good introduction to Qt featured on the
welcome. A proper tutorial, idealy even with a bit of interaction that you
can follow along in creator and that also explains how to get productive
with creator and surrounding tools.

Best Regards,
Tobias

>
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] The great idea for Qt Creator

[Tobias Hunger]

Hi there,

the idea of "Projects" is to visualize the project structure as seen
by the build system you use. I think we need that structure visible
somewhere, as developers need to interact with the build system rather
regularly:-) In qmake there is a clear separation between Sources,
Headers, Resources, UI files, etc., so that needs to be visible in
"Projects" when working with qmake projects. Other build systems have
different project trees, reflecting how those see the world they are
building.

There is a long-standing bug open to add a view that is more geared
towards project navigation. IMHO that needs to be something different
from "Project" though.

Recently the filesystem view made steps into the direction of becoming
more navigation friendly and is rather well suited for that task
nowadays -- if you like to navigate based on files and directory
structure that is. If that is not what you want, then we need to talk
about adding something else.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Questions about CMake INTERFACE project

[Tobias Hunger]

Currently CMake does not provide the necessary information to include
this information in the tree.

There is currently work ongoing in cmake to provide it though, so
maybe this long-standing issue can be fixed soon -- provided you use
cmake >= 3.13 or whenever that change will be available in cmake and a
creator new enough to know about it.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Build/run/debug xcode projects (using xcodebuild)

[Tobias Hunger]

Hi Christoph,

lots of people are on vacation right now, incl. the regular mac users
in our team. I am not sure you will get a satisfactory reply here
soon.

Please consider to file a bug report an bugreports.qt.io. At least a
bug report will not get lost like mails to a mailing list tend to be.

Best Regards,
Tobias
On Mon, Jul 23, 2018 at 11:55 AM Christoph Keller
 wrote:
>
> Hello,
>
>
> when creating an iOS project with subdirs and libraries, qmake as called by 
> QtCreator generates Makefiles for all subdirs/libraries and a xcode project 
> for the "app" project.
>
> For my case I need all files to be xcode projects, so I configure the 
> "qmake"-step with additional parameters "-spec macx-xcode -recursive". For 
> some reason there's no way to stop QtCreator from adding "&& make qmake_all". 
> So it fails since there's no Makefile.
>
> Furthermore I removed the "make" step and added an "xcodebuild" 
> (IosBuildStep), but QtCreator does not accept this as "make" step and fails 
> building with the following message:
>
> 11:31:19: Could not determine which "make" command to run. Check the "make" 
> step in the build configuration.
>
> Error while building/deploying project library (kit: Qt 5.10.1 for iOS)
>
> When executing step "qmake"
>
>
> Therefore I can’t build/run/debug via QtCreator and I have to use XCode for 
> these tasks - which I do not prefer. Is there some way to get this 
> configuration working?
>
> Thank you,
> Christoph
>
> ___
> Qt-creator mailing list
> Qt-creator@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Exclude build directory from locator results

[Tobias Hunger]

Hi David!

On Mon, Jul 9, 2018 at 8:41 AM David Mirochnik  wrote:
>
> Hello,
> I am using Qt Creator 4.6.0 to compile CMake project. The build directory 
> keeps appearing in my searches and makes it very annoying.
>
> How to exclude build directory from:
>
> Method locator results (Ctrl+K , m )
> Usages results (Ctrl+Shift+U)
> Go to definition results (F2)

Those are all provided by the code model. I do not think they even
have the information whether or not those files are generated or not
anymore:-/ We can not really leave out those files from the code model
either: They are needed to parse the code after all.

The .ui files are handled by ExtraCompilers. The "big solution" would
probably be to write one for your .q files.

Sorry, I do not have a good idea on how to do what you want right now.
I'll think about it a bit more.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] How to put custom build steps into Git?

[Tobias Hunger]

On Fri, Jul 6, 2018, 08:02 Guenter Schwann via Qt-creator <
qt-creator@qt-project.org> wrote:

> Can you make use of the .pro.shared file for that?
> http://doc.qt.io/qtcreator/creator-sharing-project-settings.html


Good idea, but that will only work if you can make sure every developer has
the same kits. The only way to do that is with the SDK tool, since there is
no way to force the Kit's ID via the UI. They use UUIDs...

So if you can make sure every developer as his environment set up by an
installer running sdktool for them and that nobody will ever use self-made
kits, then you can use shared settings. Otherwise you can't.

Best regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] How to put custom build steps into Git?

[Tobias Hunger]

Hi Sean,

On Thu, Jul 5, 2018, 20:47 Murphy, Sean  wrote:

> For our project, we've got two build customizations that we do, that we'd
> like to be able to put into source control, so that all developers
> automatically get them. But it appears that adding those steps via Qt
> Creator causes that information to get stored locally in the .pro.user
> file, which appears to have user-specific file paths in it, thereby making
> it a file that I don't think should ever get checked into source control?
>

Yes, that is correct.

My idea still is to make creator look in the source directory for a
"project setup wizard" and run that when a project is first opened. That
would be the most powerful solution to your problem I can think of and
would allow fully automatic setup as well as a UI to get I put from the
users.

Alas that has been on my agenda for a long time now.

So what's the right way to handle this sort of stuff?


Ideally everything extra should be part of the build system itself so that
the "normal" sequence of commands is enough.

That makes things simple for the IDE but also for developers that chose not
to use Creator.

PS - my question is really more intended in the general sense but the two
> specific things we're trying to put in there are:
>  - under the Build Settings->Build Steps->Make->Make arguments we want to
> add the "-j" flag to speed up compilation
>

I make sure MAKEFLAGS is set to "-j8" in the project environment.

I do that via the global system environment that is set before creator is
started, but you could also set this up as part of the kits you use inside
creator.

 - I've written a custom application that runs as a pre-build step. This
> application updates a header file with the current Git hash information so
> that that info get compiled into the application in the About dialog. This
> way, when users report an issue, I know which commit to start from. This
> application is located in a path that has a fixed RELATIVE path to the .pro
> file for the main project, but we need it automatically included as part of
> the build process when a user clones into this repository and opens the
> .pro file that the pre-build step is known and executed.
>

That is something that should be done by the build system IMHO. Have that
take a app_version.h.in and use your program to generate app_version.h from
that. Now add a bit hook or something that touches the .in file on git
changes.

I have not tested that, but that is how I would try to address that problem.
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Qt-creator] Orgad is now maintainer of Version Control plugins in Qt Creator

[Tobias Hunger]

Hello,

I am pleased to announce that Orgad Shaneh is now maintainer of the plugins 
related to version control systems in Qt Creator. He has done most work in this 
area for a long time nowe and I am sure he will continue to do a great job in 
his new role as well.

The maintainers page has been updated accordingly and the default assignee in 
JIRA has been changed.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Qt-creator] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator

[Tobias Hunger]

Hello,

I want to propose Orgad Shaneh as maintainer of the version control related 
modules in Qt Creator.

So far I have been handling that responsibility, but since I took over the 
project-related Qt Creator plugins, I had way too little time on my hands to 
take a lead in the version management related code.

Orgad has been working in those modules, he did a lion's share of the reviews 
involved and he added functionality during that time and he is willing to take 
on the responsibility involved. So I would like formally propose Orgad as 
maintainer of the version management code. I am sure he will take good care of 
the code, especially of the vcsbase and git plugins.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator

[Tobias Hunger]

Hi Sree!

I think you are seriously underestimating the task at hand. I do not
see how you will do all this in the timeframe set by google for GSoC.

One step in the direction you are aiming at is to implement a
filesystem wrapper and introduce that into creator. That is a gigantic
task in itself.

Best Regards,
Tobias

On Wed, Mar 21, 2018 at 10:59 AM, Sree Gowtham Josyula
 wrote:
> Hello Everyone,
>
> Thanks for your interest and suggestions in my proposal. With your
> suggestions, I have modified my initial idea. Please find the modified
> idea in the link below.
> Link - 
> https://docs.google.com/document/d/1hC2rTrDN5UvgpS57S5ixLiuJUSdR0KPRfNE9wPm1hc8/edit?usp=sharing
> I am posting content of the above link below for your convenience -
>
> Title - Remote System Development Plugin for Qt Creator
>
> Keywords
> 1. Development Machine - This is the machine where the user interacts
> directly with Qt Creator IDE for development tasks (editing,
> compilation and debugging). The development tasks are triggered
> directly by user using the IDE interface on this machine.
> 2. Remote Machine - This is the machine to which the development tasks
> are routed by the Qt Creator IDE of Development Machine to perform the
> development tasks and results of which are returned to the user to be
> displayed on the Development Machine.
>
> Summary
> In order to enable development of a Qt and C++ projects on a remote
> machine, this Qt Creator IDE plugin enables editing, compiling and
> debugging of a project on a remote machine via the development
> machine, supporting existing Qt Creator IDE features like version
> control, code-completion, syntax-highlighting, goto-definition,
> code-refactoring and syntax-parsing.
> Link to discussion on Qt Creator mailing list -
> http://lists.qt-project.org/pipermail/qt-creator/2018-March/007159.html
>
> Features
> 1. IDE Interface for public key registration of development machine on
> Remote Machine for seamless syncing of files between the two machines
> via ssh. Also, making an extensible interface to support adb, sdb in
> future
> 2. Interface for setting up a toolkit (Compiler, Debugger, Qt
> Tool-chain, cmake, qmake, qbs, sysroot) of a Remote Machine on the
> Development Machine's IDE
> 3. Opening projects of Remote Machine in Development Machine (using an
> interface identical to the one used for opening project on Development
> Machine)
> 4. Automatic syncing of workspace between Development Machine and
> Remote Machine(on every save & periodically) - to be implemented using
> rsync
> 5. Compilation of code on the remote machine with the tool-chain setup there
> 6. Execution & Debugging code on Remote Machine or Target Machine
> 7. Supporting Clang based code completion, goto-definition &
> refactoring. Clang will run on the development machine
> 8. Provide Version Control interface for the project in Development
> Machine and perform corresponding actions on Remote Machine
> 9. Support multiple platforms(Windows, Mac, GNU/Linux) for the
> Development Machine and Remote Machine environment
>
> Plausible Difficulties
> 1. Writing a filesystem wrapper for handling access of files on remote
> system -  This change could impact multiple other plugins and it needs
> to be thoroughly tested for multiple use-cases
>
> Mentor -
> To be decided
>
> Kindly share your thoughts, comments and suggestions on the same.
>
> With Best Regards,
> Sree Gowtham Josyula
>
> On Tue, Mar 13, 2018 at 2:20 AM, Riitta-Leena Miettinen
>  wrote:
>> Hello,
>>
>> Creating custom compilers is documented here: 
>> http://doc.qt.io/qtcreator/creator-tool-chains.html#adding-custom-compilers
>>
>> Leena
>>
>> --
>> Leena Miettinen
>> Documentation Engineer
>>
>> The Qt Company Germany GmbH
>> Rudower Chaussee 13
>> D-12489, Berlin, Germany
>> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
>> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
>> HRB 144331 B
>> riitta-leena.mietti...@qt.io
>> +49 30 63 92 3255
>> http://qt.io
>>
>>> -Original Message-
>>> From: Qt-creator [mailto:qt-creator-bounces+riitta-leena.miettinen=qt.io@qt-
>>> project.org] On Behalf Of Eike Ziller
>>> Sent: Dienstag, 13. März 2018 10:00
>>> To: Sree Gowtham Josyula 
>>> Cc: qt-creator@qt-project.org
>>> Subject: Re: [Qt-creator] GSoC 2018: New feature proposal for Qt Creator
>>>
>>>
>>> > On Mar 13, 2018, at 09:54, Sree Gowtham Josyula
>>>  wrote:
>>> >
>>> > Hi Orgad,
>>> >
>>> > I do not understand what you mean by a custom compiler. Is it some
>>> > sort of a script on development machine which returns the same values
>>> > as the remote compiler when queried with -v and -dM flags? What is its
>>> > significance?
>>>
>>> In Qt Creator settings (Build & Run > Compilers > 

Re: [Qt-creator] Qt Creator Clazy Support

[Tobias Hunger]

Hi Jeff,

I am no expert on the code model, please correct me if I am wrong!

Even with clang code model support: This will probably not work with the
system-provided clang:-(

The code model uses libclang, which can not load dynamic plugins. So you
need to have the flags plug-in statically linked into clang for it to be
available.

This makes building clang annoying: You need to build clang, then a static
version of flags, and then clang again, linking to the static flags:-(

The simplest thing you can do is probably to grab a pre-build clang from
download.qt.io.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] What makes a message a "Compile Error"

[Tobias Hunger]

Hi Michael,

On Tue, Mar 6, 2018 at 2:34 PM, Michael Jackson <mike.jack...@bluequartz.net> 
wrote:
> I'm using Qt classes, we compile on Linux (GCC), macOS (clang) and Windows 
> (VS 2015/2017). We use C++ and CMake for the build system. The part that 
> throws a false positive is a custom build step where we call "cmake -P" to 
> load another generated script. It is that script that puts out the error 
> messages. I used to have the absolute path to the CMake script file as part 
> of the output but that seemed to trigger the error. Now I just put "MKDOCS: 
> Something happened" and that seems to not trigger the error messages.
>
> Could you point me to the regex expressions? I don't really have the source 
> for QtCreator up and compiling at the moment.

Sure. These should cover most of them:

https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/qtsupport/qtparser.cpp
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/projectexplorer/gccparser.cpp
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/projectexplorer/gnumakeparser.cpp
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/projectexplorer/ldparser.cpp
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/projectexplorer/osparser.cpp
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/cmakeprojectmanager/cmakeparser.cpp

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] What makes a message a "Compile Error"

[Tobias Hunger]

On Tue, Mar 6, 2018 at 1:41 PM, Michael Jackson
 wrote:
> As part of our build we execute a few external programs that create output. 
> It seems that QtCreator seems to think that these messages are errors even 
> though they are not.

Creator uses classes derived from IOutputParser to decide what to list
in the issues tab.

> Is there a specific pattern that we can use in our output messages so that 
> QtCreator can interpret them correctly?

Lot's of them:-) All nicely defined in lots of RegExps.

The actual patterns used do depend a lot on your project though:
Creator uses a list of IOutputParsers and feeds all stdout/stderr text
from the build process through the chain of parsers.

The actual parsers in the chain do depend on OS, build system used,
compiler selected, whether you use Qt or not and probably some more
factors:-)

> Sometime those programs actually _do_ error out and we want those errors to 
> show up in QtCreator's error list.

You will need to add another outputparser to the chain then or extend
an existing parser to match the messages you want.

I am happy to add more patterns, provided they are generally
applicable of course and that somebody provides the necessary test
data (the actual error messages and whether those come from stdout or
stderr).

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator support for Unreal Engine 4

[Tobias Hunger]

Hi,

I would personally look at something more battle-hardened than qbs,
especially considering that UE4 already supports more build systems
from what I understand.

Maybe one of those that are already supported will work better with Qt
Creator than qmake already? CMake is a likely candidate, as that will
most likely have seen way more testing and polish than the .pro files
on the UE4 side.

On Mon, Mar 5, 2018 at 1:22 PM,   wrote:
> As an aside, qmake is going to be deprecated eventually in favour of
> Qbs, so if you start with Qbs, your work is likely to me more future-
> proof.

I am not aware that this decision has been made yet: It's still up to
the Qt Project to decide on that eventually. And Qbs needs a serious
amount of non-trivial work between now and then.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator support for Unreal Engine 4

[Tobias Hunger]

Hi San,

Before we continue: Creator supports more than just qmake as a build
system. Is there any that works better?

On Sat, Mar 3, 2018 at 9:57 AM, Sander Smid  wrote:
> Thanks Tobias for your reply.
>
> So I've been looking into what QtCreator already provides, what steps are
> already done on the UE4 side of things and what is missing to get proper
> integration. What UE4 currently provides is a qmake project file (.pro) and
> a few project include files (.pri) which mainly list all the project source
> and header files. The UE4.pro file does contain some description of targets
> but not all of them are picked up when the user configures the project file.
> All of the settings that actually deal with defines (UE4Defines.pri) seem
> stubbed and don't contain actual build defines. Probably because it is
> required by qmake but simply doesn't have a purpose as UE4 uses its own
> build system.
>
> The current UE4 documentation recommends each user needs to create a
> UE4.pro.user file in which the qmake build and clean steps are removed and
> (manually) replaced with a make command. This is all described in an array
> of "ProjectExplorer.Project.Target" structures in the UE4.pro.user that
> define the build and run settings. As a quick test I moved that part over to
> a UE4.pro.shared file as that file is intended to be shared. Unfortunately
> QtCreator prompts me to configure the project so I assume this isn't
> supported.

Moving that to a .shared file will not work: The kit ids will not
match and then get ignored. Kit-specific stuff like build steps
currently can not effectively get shared in creator.

> The alternative would be to generate the UE4.pro.user file in a similar way
> the .pro file is generated (I should have all the information at that the
> moment the .pro and .pri files are being generated) however I got the
> impression that is not the recommended way to go about this.

I doubt that would work for the same reason as the .shared files fail:
You do not know the right kit Ids to put into the .user file.

> This bring me to the following set of questions:
>
> Fixing the qmake build steps:
>
> Each user currently needs to define their kits (which makes sense as it
> includes build target locations) but after generating them not all the
> targets as described in UE4.pro are not all available. Can you what steps
> are missing here?

No idea. Everything in a .pro file should get picked up.

> Can you see any reason why the qmake project files are not working?

Bugs? :-)

I am actually not sure whether creator is supposed to show aux targets or not.

> I know
> this is a broad question so feel free to skip this.
> Is there any other place than the .pro.user files where QtCreator stored
> information about project configurations that might be relevant (e.g
> ~/.config)?

No. All the project-specific data is stored in the .user-file.

> Use qmake project as a shell for code navigation and focus on getting build
> and run configurations working with make:

Why qmake?

> I'm thinking to generate a set of "ProjectExplorer.Project.Target"
> structures that call 'make' to build the projects. I think I can generate
> the structure for a UE4.pro.user but that conflicts with the kit
> generation/configure step. Is there any other place where I can store this
> structure so it is available to all users?

No.

> And is this a sane approach?

No, it is user specific:-/

> I'm
> a bit worried about some of the Ids in there (e.g.
> ProjectExplorer.ProjectConfiguration.Id and EnvironmentId) will bite me once
> I got the UE4.pro.user file generated. Any ideas on that?

It will not work. That is a known problem for a while now.

My plan is to eventually have project-specific wizards that can do the
necessary magic. But those are not there yet (and I am currently
poking into other corners, so do not hold your breath).

> For reference I attached the generated .pro and .pri files which might help
> filling in the blanks where my explanation (with very limited experience
> with qmake) might fall short.

So basically you are defining custom targets for the things you
actually want to build? I am not sure that this is supported in
creator, it will definitely not be supported well.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] [Development] Requesting repository for telemetry plugin in Qt Creator

[Tobias Hunger]

Hi Tino,

On Fri, Feb 23, 2018 at 4:58 PM, Tino Pyssysalo  wrote:
> I’ll clarify little bit, as my earlier comment about “any backend” has been
> confusing. I requested a repo for a QtCreator analytics plugin, but we
> realized why not to use a similar solution in other tools as well. I want to
> concentrate on a Qt Creator plugin first to fully understand the problem
> domain. Once that is done we can discuss how to move forward with this
> project”. Our intention is usage data collection, but nothing else at this
> point. Obviously, we plan to use the collected data to improve Qt. As a
> concrete example, we have provided a lot of nice features in Qt Quick
> Designer in the recent Qt Creator releases, but we have no idea, if the use
> of Qt Quick Designer has changed in any way. This kind of data would be very
> valuable to us.

So this is a simple creator plugin to collect data about Qt Creator
users. That makes the scope clear to me, so I can step retract my -1
for undefined scope.

A repository in the qt-creator namespace makes sense to me for that
scope, but considering the experimental nature of this work, a
playground project might work out better. I am not deep enough in the
usual practices to have a firm opinion on that topic.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] [Development] Requesting repository for telemetry plugin in Qt Creator

[Tobias Hunger]

Hi Pasi,

On Fri, Feb 23, 2018 at 10:33 AM, Pasi Keränen  wrote:

> I object to using “Spyware” term in this context. Spyware is SW that does
> things behind your back.

I noticed that my mail could be read in the way you read it pretty
much right after sending it. I need to apologize for expressing myself
so poorly!

What I meant to say that it is possible to write a spyware plugin
(following pretty much exactly what you lay out below) for creator or
any one Qt application that will collect basically everything about a
user and to feed that into a database on the internet somewhere in a
couple of weeks. On the other hand the task of writing a framework
that does anonymized data collection that follows all the relevant
data protection laws and standards and that pushes it to a server that
is easy to manage and set up is an entirely different scope. I wanted
to find out where our discussion is between these two poles.

I did not intend to imply that what we are discussing here is spyware.

> Siphons contact information, user account info etc.
> without telling you. We’re NOT talking about such use cases here! I don’t
> think anyone in The Qt Company wants to do such things. From what I hear the
> intention is to track certain things in an open, transparent manner,
> respecting the communitys clear wish to keep things in the open and for the
> benefit of our end users.

I am sorry for giving the impression that I thought anybody here is
considering spyware. That was not my intention and I want to apologize
to anybody that got that impression.



Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] [Development] Requesting repository for telemetry plugin in Qt Creator

[Tobias Hunger]

Hi Pasi,

On Feb 23, 2018 08:05, "Pasi Keränen"  wrote:

Hi there,

+1 for having a generic telemetry plugin in Qt.


I planned to stay out of this, but

-1 since I am totally confused about the scope of this project at this
point.

So are we talking about a generic telemetry framework for Qt applications
or about watching Qt Creator users specifically?

Tino started by making the claim that this is a generic library and then
kept listing Qt Creator specific integrations. You focus entirely onto the
generic part, leaving out creator completely.

What exactly are we talking about here?

A Qt creator spyware plug-in (which does more than what we discuss here I
hope:-) would be a matter of a couple of weeks to do, putting a generic
framework into place with all the bits and pieces for that to be actually
useful in a wide list of possible contexts is a very different beast.

This is great initiative and very much the way today's app and application
industry works. UX studies performed by UX experts have been minimized and
targeted for specific (usually new/experimental) features or upcoming new
software (like we did with Qt 3D Studio back in last spring). And the mass
information on "how do our users use the SW? do they find the stuff we've
put in there? how often they hit a wall in doing sequence X? how many
crashes do they experience when doing Y?" is collected via automated
telemetry. It is great as it brings data from the actual user in their
actual work and you can then use that to concentrate on functionality that
really matters to your users. Making stuff they repeat hundred times a week
easier and faster, making them more productive.


I see value in this approach when you can do lots of small releases fast.
So you can do evaluate the effect of small changes by doing one change to
evaluate per release and measure how that effects usage.

We can not do more than two releases per year in Qt. Is this approach even
applicable to us?

I want to also point out that answering any of the questions you used as an
example require *way* more information than I am even remotely comfortable
to collect.

I see definite need for this in Qt 3D Studio so please don’t make this just
with Qt Creator in mind. Also, in my humble opinion, in order to be
relevant in today's UI development, Qt should also offer this kind of a
plug-in to our customers. A ready-to-go plug-in that automatically ensures
the data is collected in a way that fulfills data privacy acts and respects
the privacy of the user would be great. Especially for startups and smaller
companies, but also for bigger companies wanting to switch to the modern
way of doing UI development. It is not as easy to do as one might think at
glance.


I agree that having a general framework has value to some customers.

Such a framework would need to be integrated into big solutions like Google
analytics or something similar so the users can actually evaluate the
collected data and cross-reference that to other data they collect. Just
dumping data into some server somewhere does not help anybody.

Will the server-side code be part of this project by the way?

What about evaluation of the collected data? Is that in scope for this
project, too?

I would ask anyone who has not done work with usability and user experience
people in the past to give this way of working a chance. I've worked 7
years in application development while we grew usability knowledge in the
team over that time. The first time I got to observe a real world user
working with our software in actual real world situation was eye opening.
We had gotten so many important things wrong in our idealistic thinking and
forgotten to handle certain cases that occur on the field. Also you become
blind to your own creations faults as you just know how the software works.
It's just a fact of life.


Sure. We do way too little validation of what we do against the real world
usage.

Let us do some usability studies, let us talk to users, let us do surveys,
let's evaluate all the data users provide to us on the mailing list, the
bug tracker, the forums, stack overflow and in lots of other places. We do
have a very active and supportive community of users and customers, let us
use the feedback they provide already!

Collecting some semi-random data from a self-selected group of users and
dumping that onto a server somewhere is next to useless compared to all the
other options we have already. Even in an ideal situation (which we do not
have within Qt!), metrics are not comparable to a real user study where you
actually watch users doing their thing.

This is even more true when not leaving out any information that can be
used to identify individual users from the collected data, which we
obviously will do.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Collapse all methods/classes in opened file

[Tobias Hunger]

Hi Dimitry,

> Hi, is there any hot-key that allows to collapse all methods and classes in 
> current document?

No, but there is a "CollapseAll" action available, so you can assign one in 
Tools>Options>Environment>Keyboard, so you can assign one yourself.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator support for Unreal Engine 4

[Tobias Hunger]

Hi Sander,

> I was wondering if QtCreator could see some improvements in supporting
> third-party builds systems and/or integration with bigger projects. Unreal
> Engine 4 is one of the biggest game engines and, when you agree with
> their terms, you get access to the full source code. This helped quite a
> bit in supporting other platforms.

I have no plans at this time to support Unreal Engine. Contributions are of 
course welcome, but I don't think this is something that we should offer in the 
core Qt Creator. It would be a wonderful 3rd party plugin though.

> One of the weaker points with this engine is that for each platform you 
> require
> to adapt to a another IDE or build process. Unreal uses their own build 
> system,
> which can generate projectfiles/-solutions for various other build systems
> (e.g. CMake) and IDEs. If QtCreator could integrate better with UE4 there
> would be a single IDE that works on all platforms.

Sure, Creator is a great IDE and if Unreal sees value in having a nice 
cross-platform IDE, then they are free to contribute or fork or do whatever the 
license allows:-) I do not see why the Qt Project should do that work though.

> The official UE4 docs[1] already mention QtCreator

Nice! I was not aware of that.

> but if you take the time
> to look at the steps the integration is very weak. Changing a build target,
> variant or platform means changing the builds steps by hand. This is one
> of the reasons people often recommend CodeLite for development on
> Linux because that IDE allows you to switch target and variant by using
> the drop down menus just like you would on Visual Studio.

According to the documentation you link you should be able to switch between 
debug/release via creator's UI just as well, once you did the initial setup.

> Is if there is willingness to add UE4 support in QtCreator

I am willing to answer questions on build system integration into Creator, but 
I do not plan to work on this myself.

> or are there ways to improve the current integration?

Nothing obvious. Maybe another supported build system would work better than 
the half-baked .pro-file they ask you to load? I do not have UE around to test, 
so I don't know.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Correct way to start a light IDE based on Qt Creator

[Tobias Hunger]

On Wed, Jan 10, 2018 at 6:49 PM, Seyyed Razi Alavizadeh
 wrote:
> Hi there,
> I want to start an IDE based on Qt Creator. But I need some advice and idea
> before doing anything. Some questions:
>
> 1- As there are some (maybe a lot of) my application users using Windows XP,
> so I need to support XP.
> Do I have to start based on an old version of QtCreator supporting XP or I
> should forget about XP?

XP is unsupported by Microsoft for a long time. So no updates, no
security updates, no support from new compilers.

The latter is pretty important as Creator is using more and more C++14
and later features.

> 2- As "Qt Creator" is hard-coded everywhere. To rename qtcreator I have to
> change a lots of files. This will cause some problems for updating base code
> to latest qtcreator code.*

That should be configurable now in the master branch.

> Which solution is better? And, what is your suggestion?
>  2.a - Start implementing my app based on current stable version of
> QtCreator and do not consider QtCreator as an upstream project. So no need
> to update base code.
>  2.b - Start implementing my app based on latest development version of
> QtCreator and regularly ( daily? :/ ) update base code of my application
> with the latest commits from QtCreator. Maybe daily update is not very
> practical?

I would use the master branch and follow Creator releases.

Try to keep your changes in your own plugins as much as possible and
contribute the rest to upstream.

Anything to keep the diff to upstream small spares you from the hassle
to maintain it:-)

> *: I would liked there was an XML file that by modifying it QtCreator was
> completely renamed to MY_APP name. :D
>
> 3- (somehow like 1) As I want a simple and light IDE. Is it good to start
> based on an old version of QtCreator (such as v2.6) that have much smaller
> code size than newer versions of QtCreator?

What do you want to do to slim things down?

> Sorry for my bad English.

No worry, bad English is the standard around here:-)

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] prepare-commit-msg and commit-msg hooks

[Tobias Hunger]

Hi Seth!

You are almost correct AFAICT.

> - User types commit message into blank Description box

Actually GitClient::getCommitData retrieves the text for the commit
message that is shown in the description box. That can be blank or
some of the different templates used by git. Creator does not run any
hooks at that point though.

> - User presses "Commit"

... and creator runs "git commit", triggering all the magic git does
with the user-provided commit message as input.

Hooks do get run at this point, but it is admittedly a bit late for
the pre-commit or the prepare-commit-msg hook. Do you have any idea
how we can improve this -- without reimplementing all the logic built
into git?

Best Regards,
Tobias


On Mon, Jan 8, 2018 at 3:25 PM, Seth Raymond  wrote:
> With the current Qt Creator git plugin implementation, it is difficult (and
> perhaps impossible?) to use the prepare-commit-msg and commit-msg hooks to
> check if a commit message is stylistically valid. This is because Qt Creator
> does not run `git commit` until after the message has been written in the
> "Description" box and the "Commit" button has been pressed. The current
> sequence is as follows:
>
> -User types commit message into blank Description box
> -User presses "Commit"
> -Description is written to temp/commit/msg
> -prepare-commit-msg hook is run on path/to/repo/.git/EDIT-COMMITMSG
> -Data from temp/commit/msg is pseudo-appended to
> path/to/repo/.git/EDIT-COMMITMSG
> -commit-msg hook is run on path/to/repo/.git/EDIT-COMMITMSG
>
> My temporary workaround is to use a static template, but the template cannot
> dynamically insert text into the commit (such as the current branch name). I
> could "fix" the commit message after the user is done, but that is not
> ideal. Suggestions?
>
> ___
> Qt-creator mailing list
> Qt-creator@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator
>
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Qt-creator] Fw: more granular deployment from cmake project?

[Tobias Hunger]

Sorry, I forgot to CC the list:

Hi Rich,

> I was wondering if it would be possible to change the
> functionality of Qt Creator.

Of course it is possible to change functionality in Qt Creator!

> Currently, in the Deployment settings, there is no way to
> avoid deploying every target that is created in a CMake
> project. For example, if I create an executable and a bunch
> of unit tests - all of those targets are deployed. If one of the
> targets has not been built, then I am not allowed to debug
> the others, because the deploy step requires every target
> to be deployed.

That is correct.

> My thought was that the deployment would be perhaps
> tied to what is selected in the lower-left side in Qt Creator -
> just above the Play green triangle.  If you have selected
> Debug under Build and under Run have selected one of
> the targets for the remote device, then the deployment
> would key off of that.  Or - make it possible to select which
> target(s) to deploy similar to how you can choose which
> targets to build in the Project settings via the
> checkboxes available in Build Steps.

Please file a suggestion in the bug tracker: Mails tend to be forgotten as new 
mails come in, but bugs are tracked forever:-)

I am not sure this can be done reliably with cmake, but I agree that this would 
be a nice feature.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Does someone understand this CMake error

[Tobias Hunger]

On Thu, Oct 26, 2017 at 11:42 AM, Nikos Chantziaras  wrote:
> Solved by ticking the "Auto-create build directories" checkbox in
> Options->Build & Run->CMake.
>
> That should have been enabled by default, IMO, given that you can't build
> your project without it and get the most obscure error message.

So far I never ran into that problem with the temporary directories
Creator builts into (till you actually build stuff:-). Unfortunately
there is no way to make cmake not write things, so without the
temporary directory hack it will create lots of directories and files
and people report that creator should not clutter up their drives just
because they want to take a quick look into some code.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Requesting repository for Haskell support in Qt Creator

[Tobias Hunger]

+1 from my side.

Sorry, I left out the mailing list in my first reply to this topic.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B



From: Qt-creator <qt-creator-bounces+tobias.hunger=qt...@qt-project.org> on 
behalf of Eike Ziller <eike.zil...@qt.io>
Sent: Friday, October 6, 2017 8:57:07 AM
To: qt-creator@qt-project.org
Subject: [Qt-creator] Requesting repository for Haskell support in Qt Creator

Description:

Support for the Haskell programming language
Currently includes
1) code highlighting
2) informative tool tips in the editor and follow symbol
3) simplistic .cabal project support and build and run configurations
where 2+3 currently require you to use Hakell Stack, and 2 requires ghc-mod

Responsible: Eike Ziller

Repository: qt-creator/plugin-haskell

Existing code: https://github.com/e4z9/qtcreator-haskell

--
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Time to update sdktool's README.

[Tobias Hunger]

On Sep 29, 2017 09:55, "Christian Gagneraud"  wrote:

>From my tests, i got different behaviours on an open source install
and an enterprise install.
For some reasons, the Enterprise sdktool updated
/Tools/QtCreator/shared, while the open source updated my
~/.config/QtProject/QtCreator/... Maybe it's my setup/env, but i'm
pretty sure it did hapenned.


Both flavors do exactly the same thing: Sdktool writes into
../shared/qtcreator/QtProject/. This directory is assumed to be read-only
after the installer is done, so all settings are mirrored into the user
configuration so that the user can store additional information about the
kits.

This is necessary since plugins can extend kits with their own information,
which the installer does not necessarily know about.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Time to update sdktool's README.

[Tobias Hunger]

Hi Jake,

On Thu, Sep 28, 2017 at 6:35 PM, Jake Petroules  wrote:
> What does sdktool have to do with Qbs?

Nothing:-)

You can set the other build tools in the kit, but since Qbs is linked
into creator there is nothing to set.

That is actually a huge problem since qbs changes so much that you
need to closely match the Qt Creator version you use to the code you
want to build with it.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator 4.3/4.4 + CMake likes to "rebuild" my project, a lot.

[Tobias Hunger]

Hi Michael,

On Wed, Sep 27, 2017 at 3:58 PM, Michael Jackson
 wrote:
> I have seen this problem more than a few times and with a 45 minute build 
> time for our project it is starting to get in the way. Our project is CMake 
> based (I am using CMake 3.8 or 3.9 depending on the particular workstation 
> that I am using at the time) and also uses Qt 5.9.1 64 bit. All the code is 
> C++. What will happen is that I load the project, QtCreator properly 
> configures for the build (Debug) and I build the project successfully. I quit 
> QtCreator. Relaunch QtCreator and when I click Debug for our application 
> QtCreator will pretty much rebuild the entire project. NOTHING changed 
> between when I last built, quit QtCreator and relaunched QtCreator. I use 
> ninja as the build tool.

When you open the project, then cmake will go through the
configure/generate steps again. Is that what you are referring to?
That is how cmake wants this to be handled, so there is nothing I can
do there.

Or does the actual build rebuild huge parts of the project? That could
be triggered by cmake configur/generate mentioned above: Do you create
some central header file or something from cmake? That would be a bug
that I'd need to file with upstream cmake:-/

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Default Assignee for BB10/QNX support

[Tobias Hunger]

Hi Dan,

On Thu, Sep 21, 2017 at 4:09 PM, Dan Cape  wrote:
> I created a JIRA recently that went to the “BlackBerry 10 / QNX Support”
> component but the default assignee hasn’t been active since April 2015. Can
> the default assignee be changed to someone who is active so it’s not just a
> black hole?

Do you know of an active Qt maintainer/reviewer with a QNX background
that could fill that hole?

I am currently not aware of anybody that fits that description, and I
am not aware of any volunteers in that area either. Any help is highly
welcome!

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] qtcreator does not find sytem include path on gentoo linux

[Tobias Hunger]

> Project compile and run fine, but code model does not find system include 
> path. (classic
> code model and clang code model) "Header paths" Tab in "Inspect c++ code
> model" is empty.
>
> My system is Gentoo.
> QtCreator 4.4.82.
> Qt 5.7.1
> GCC 6.4.0
> CMAKE 3.9.2 server mode

What does this print:

LC_MESSAGES=en_US.utf8 gcc -xc++ -E -v -

?

If this uses localized output, then creator might fail to detect the include 
paths.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] CMake config failure == unfixable

[Tobias Hunger]

Hi Andy,

Sorry, I left this as a draft and right to send it:-(

On Aug 29, 2017 20:15, "Andy"  wrote:

I'm trying to config a relatively complex project with Qt Creator 4.3.1.

1. I select a new option - call it "foo".
2. It fails to configure because there are new paths to set for "foo".
3. I decide to not configure "foo", so I deselect that option from step 1.
4. It still fails to configure - with no way to fix it now.
5. The "Advanced" checkbox is disabled meaning I can't remove the new stuff
it added in step 2 to get a working config again.
6. I tried to configure it using the CMake application instead, but now
when I load the project I get a completely blank configuration with errors
pointing at the paths from step 2.


You can always ask Creator to throw away the current configuration and
start over. There is a menu entry to blow away CMakeCache.txt for exactly
this case:-)

Is there a way to avoid using this config interface completely and just use
the CMake application like we used to do?


Creator still uses cmake, it just calls it with different parameters:-)

Best regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] qmake will not build c++ file named something like format.cc and ostream.cc

[Tobias Hunger]

Hi Yun,

https://bugreports.qt.io/browse/QTBUG-61842 describes a similar issue in Qmake. 
Maybe it helps to report your information there.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] 4.3.1 & cmake project configuration

[Tobias Hunger]

Hi Andy,

On Jul 9, 2017 03:32, "Andy"  wrote:

I created a new entry under Build & Run for 5.9.1. I started to configure
the project in the CMake section and it now just says "Configuration
failed." with no settings in the list. So there doesn't appear to be a way
for me to fix the configuration...

Any suggestions?


For now you will need to add the flags via the add button. Annoying, but we
are working with cmake upstream to fix this:-)

UX note: I find configuring a cmake project through this interface very
tedious and error-prone. The project I'm working on has a couple of hundred
settings when "Advanced" is on and trying to work with the (non-resizable)
list is not fun at all. I would suggest an interface more like the actual
CMake app where you can filter and group the settings properly. (And please
let me resize the list so I can actually read everything.)


Click into the cmake settings and press Ctrl-F to search. I recently
approved a patch adding filtering, too, so that will be in At Creator 4.4.

The resizing is not there yet. Not sure how well that will work in project
mode.

Patches to make things more convenient are always welcome:-)

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QTCreator + CMAKE Project View.

[Tobias Hunger]

Hi Michael,

On Mon, Jul 3, 2017 at 4:45 PM, Michael Jackson
 wrote:
> I am not sure what you are seeing but this is what I see with QtCreator
> 4.3.0 on macOS 10.10.x

Creator does not show how files relate to targets in the old tea-leaf
mode (the one relying on Codeblocks files and a bunch of others).
Server-mode does show this information though. For server-mode to be
used in creator 4.3 you need cmake >= 3.7 with server-mode enabled
(the default when building cmake).

Server-mode is getting adopted by other projects and is not exclusive
to Creator anymore. I had hoped that this would be the case when I
implemented it based on a prototype by Steven Kelly. These projects
recently have started to contribute new functionality they need to
cmake upsteam! I want to spend my time enabling support those
improvements in Creator, so I do want to deprecate tea-leaf mode from
creator as soon as possible and I will not spend time on bringing
features to tea-leaf mode.

> When you go between Visual Studio and QtCreator (We do all the time) there
> is a "mental mapping" that one needs to do.
>
> QtCreator Project = Visual Studio Solution
> QtCreator Target = Visual Studio Project.
>
> Maybe there needs to be a "Target View" in QtCreator that just lists the
> targets in alphabetical order?

How would that be useful? You say yourself that the current view is
cluttered and reports seem to indicate that much of the clutter is due
to too many targets being displayed.

> I like the hierarchy view but with the latest
> use of CMake-Server there is a lot of clutter to get around.

Any ideas to de-clutter it that still leaves the targets in and shows
how files relate to targets? Maybe I could move all the utility
targets into a subfolder?

I have tried hiding the utility targets, but users that trigger these
utility targets via the context menu of the project view complained
about that.

> I know the QtCreator Devs work *hard* on good CMake support.

Actually that is just me working on CMake support:-/ Any help is appreciated!

> It has gotten
> better and better over the years and they do respond well to feedback that
> includes concrete cases and reproducible bugs.

Thanks!

> I would suggest starting a topic about your concerns and having a discussion
> about features that would enhance the CMake/QtCreator experience.

Yes, please!

I do not use CMake that often -- I spent most of my time working on Qt
Creator, using qmake. I do miss paper cuts (or even real big problems)
that are obvious to more cmake-centric users. Please tell me about
those so that they can get fixed! :-)

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QTCreator + CMAKE Project View.

[Tobias Hunger]

Hi Andy,

sorry, I somehow managed to miss your mail:-/

On Thu, Jun 29, 2017 at 9:14 PM, Page, Andy (UK)
 wrote:
> I can’t believe I am the only person to have queried this behaviour.
>
> When I run CMAKE from QTCREATOR - I don't see source files associated with
> individual CMAKE targets(libraries / exes) rather I see all source files.

Qt Creator 4.3 together with cmake >= 3.7 will show targets.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] importing "foreign" cmake projects remains problematic

[Tobias Hunger]

Hi René,

sorry, this somehow ended up in my spam folder and I only noticed your
mail just now.

On Sat, Jun 10, 2017 at 12:54 PM, René J.V. Bertin  wrote:
> To make another (more succinct) case for having a way to configure a cmake 
> configuration step:
>
> - there are moments in the lifetime of a project you're working on where you 
> need to reset the build. Sometimes that means discarding the whole build 
> directory, sometimes you only need to discard the CMakeCache.txt file, and 
> sometimes it's proven to be a good compromise to discard "CMake*" in the 
> build.dir toplevel.

Build > Clear CMake Configuration nukes your CMakeCache.txt file.

It does auto-set the configuration you have made via creator, so that
you do not have to start from scratch. Maybe that is not what you
want?

> - consider a project that can be built for Mac, MSWindows, X11 and why not 
> Wayland, each with their own set of included source files and possibly build 
> targets. In an IDE like KDevelop you can simply add a new build directory to 
> the project and configure all aspects of the details cmake invocation - 
> aspects which will be saved and used each time cmake needs to be run.

You can set the generator and all the related things via the kit. I
think that is the place where that makes the most sense.

You can set generic settings you want for all projects, also via the kit.

Once that has gone through you have a UI to configure the project in
more details.

What is missing?

> In both cases I'd typically want to be able to get the project layout 
> displayed appropriately in the IDE before I run a build. IOW, Creator's 
> feature where you launch the build via `cmake --build  --target ` 
> is not exactly what I'd expect even if it probably does the job (just kill 
> the build when it starts, right?).

cmake --build . --target  is how cmake says you should build
cmake projects. Why do you think using that is a problem?

It will do the right thing for all generators, so following what cmake
says you should do as a developer makes creator work with all possible
generator and spares it from hard-coding a mapping of cmake generators
and actual build commands to call.

> I've managed to support "server" mode via my cmake2port wrapper. With that I 
> indeed get the entire project in view, including files generated in the 
> build.dir. But there appears to be no way to specify the usual -DCMAKE_FOO 
> arguments in that mode so I'm a bit suspicious of the whole thing.

Everything you set in the kit configuration or in the project
configuration will be set in server mode. No worry:-)

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] importing "foreign" cmake projects remains problematic

[Tobias Hunger]

Hi Rene,

I probably do not fully understand what you are doing, so please be
patient with me:-)

On Thu, Jun 8, 2017 at 3:07 PM, René J.V. Bertin  wrote:

> I've had another look at the current state of things in Qt Creator (v 4.3.82 
> aka 4.4.0 beta1), esp. CMake support.
>
> There are things that seem to have improved, enough that I am getting 
> interested in trying out the IDE, but CMake support remains problematic 
> enough that I can't for most of my projects.

Thank you for taking the time to provide your feedback instead of just
running off to greener pastures! I very much appreciate the feedback
on our cmake support: Without it CMake support in Creator would not be
where it is today.

> I have a wrapper script that can be called instead of cmake and that ensures 
> that the proper command is executed which will in turn execute cmake with the 
> appropriate arguments.

Can you register your wrapper script with creator? That should work,
provided it it (mostly) transparent and forwards the relevant
arguments to the real cmake.

> What's really missing from Creator is support for a separate configuration 
> step with exact control of the arguments to be used.

What do you mean here? You want the call to cmake to configure the
project to be more explicit? Make/ninja are calling out to cmake all
the time. Why would creator not do the same? It needs the same level
of information.

> I also notice that Creator still calls cmake (without any control over 
> additional arguments) even if the "automatic" option is disabled in the CMake 
> settings panel.

Sure it does.

It starts cmake and asks it for information on the project you opened
directly. At least it does in server-mode. With the older
tealeafreader mode it just runs cmake once to make sure the
configuration is still up to date.

> But that's maybe not the only glitch. I tried to import one of those MacPorts 
> projects, configured as usual but with the "CodeBlocks - Unix Makefiles' 
> generator under the assumption that Creator would be able to infer the 
> project structure from that.

Is one of these projects open-source? Can I open such projects on
Linux for testing? I'd like to give this a whirl:-)

> The basic cmake (v3.8.2) call is

So you almost certainly have server-mode in your cmake:-)

> %> cd /path/to/work/build ; cmake -G "CodeBlocks - Unix Makefiles" 
> -DCMAKE_BUILD_TYPE=MacPorts -DCMAKE_EXPORT_COMPILE_COMMANDS=ON  options> /path/to/work/source

I do not see why that would not work from creator.

The CodeBlocks part is optional for you (your cmake has
server-mode;-). So -G "Unix Makefiles" is ok. You can define the
generator in the Kit.

CMAKE_BUILD_TYPE=MacPorts can be configured as well. If you want to
use this setting a lot, then you can set this up in the Kit as well.
It has a section for CMake Configuration settings. That configuration
will then be used whenever that kit is used. You can also set this via
the project configuration if you do not want to see this applied so
widely. You will need to manually add it there though.

CMAKE_EXPORT_COMPILE_COMMANDS is not used by creator. You can still
add it, with the same options as for CMAKE_BUILD_TYPE.

> When I import the resulting build dir in Creator I don't see the source in 
> the IDE, but install tree.

What does that mean exactly? You do not see the files in the source
directory but a list of files as they are installed?

> The same thing happens with CodeBlocks, btw, so this may be more a problem 
> with Cmake's CodeBlocks generator than with Creator. I do note however that 
> KDevelop imports the same configured project perfectly, using the 
> compile_commands.json file that is created because of 
> CMAKE_EXPORT_COMPILE_COMMANDS . (Not really surprising given how the intended 
> target user of that file - the Eclipse IDE - is in a completely different 
> league as CodeBlocks...)

I have considered using compile_commands.json file, but that would
just be another hack that will fail for non-trivial projects. You get
the exact compiler call for all source files from that file, but there
is no context information in it, so you can not say which call belongs
to which target. That is problematic when you build the same file
several times -- something that happens a lot in the wild, e.g. in
tests.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Qt Creator 4.3.0, Qt 5.9.0: problems with cmake support

[Tobias Hunger]

> this is strange:
> If I use the kits manager to set the compilers to  I get:

Please do not do that. The compiler information is needed by Qt Creator. If you 
want to change the information that is seen by CMake, please just edit the 
CMake Configuration of the Kit. There is a Change button where you can edit 
what is passed to all CMake invocations using that Kit.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Qt Creator 4.3.0, Qt 5.9.0: problems with cmake support

[Tobias Hunger]

https://bugreports.qt.io/browse/QTCREATORBUG-18325 is the bug report for this 
issue.

--
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Qt Creator 4.3.0, Qt 5.9.0: problems with cmake support

[Tobias Hunger]

Hi Helmut,

On Jun 1, 2017 18:19, "Helmut Mülner"  wrote:

Running "C:\Program Files\CMake\bin\cmake.exe -E server
"--pipe=\\.\pipe\{cdb7ec38-096b-4a3d-9b84-fc91923889d4}" --experimental" in
C:\Users\mue\AppData\Local\Temp\QtCreator-P1XkOA\qtc-cmake-XXF8mA7w.

The C compiler identification is unknown The CXX compiler identification is
unknown CMake Error at CMakeLists.txt:3 (project):

  No CMAKE_C_COMPILER could be found.

Does your project contain files that need to be built with a c compiler?
You might want to tell cmake not to bother checking for one if not:-)
PROJECT has a way to do that.

For this you need to delete / rename your Qt Creator compiler / kit
configuration xml files.



On Linux they are found under ~/.config/QtProject/qtcreator/, on Windows
probably under %appdata% ...



On Windows these files are under %appdata%\QtProject\QtCreator



I rename toolchains.xml, also removed all build-directories in my project
folder – to no avail.

I also rename CMakeLists.txt.user in the project folder, leading to a crash
of qtcreator at the next start, but working again at the following start.

The stuff is in profiles.xml. Do not bother to delete that, just fix it!

I still cannot build with Qt 5.9.0 msvc2017-64.

The Kits Manager show a warning : Cmake configuration has no path to a
C[++] compiler set,  even though the kit has a valid toolchain. I select
“Microsoft Visual C++ Compilter 15.0 (amd64)” in the compiler comboboxes,
and this is shown in the kit tooltip, but the problem persists.

Tools>Options>Build & Run>Kits, click the kits, change the cmake
configuration. That is where the c comoiler/c++ compilers are defined. If
you did not change those before, it should be enough to reset those to
default values.

Best Regards,
Tobias

PS: Did you upgrade Creator or is this mess with blank settings? It should
leave the cmake configuration of the kits alone (I can't be sure the user
has not explicitly set those!), but the compilers should have worked:-) So
sorry for the mess.
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Qt Creator 4.3.0, Qt 5.9.0: problems with cmake support

[Tobias Hunger]

> 1. Build a project mit cmake and Qt 5.8.0 (msvc2013-64) works, but I cannot 
> debug qml (Enable QML in Debugger Settings is checked, but Application Output 
> says:

The "Enable QML in Debugger Settings will just start the debugger in Creator 
and try to attach to the debugging port of your application.

You will need to build the support for debugging into the application for that 
to work though. I am no QML expert, but apparently all you need to do is to 
define QT_QML_DEBUG before including QtQuick. Adding that to the relevant CMake 
targets should work fine.

Please make sure to disable QML debugging support when creating release 
binaries that you want to ship.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Qt Creator 4.3.0, Qt 5.9.0: problems with cmake support

[Tobias Hunger]

> For this you need to delete / rename your Qt Creator compiler / kit 
> configuration xml files.

Actually it should be enough to double check the compilers set up in your kit 
(Tools>Options>Build & Run>Kits) and maybe reset the cmake configuration for 
that kit.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtC 4.3 cmake-servermode feature - how to disable that?

[Tobias Hunger]

Hi Mapron,

Am 28.05.2017 16:20 schrieb "mapron" :

I was happy user of QtC cmake support until update to 4.3.0 release. I have
cmake 3.8 (and I don't want to downgrade to 3.6) for my project.


After cmake configuration, all project tree is messed up - instead of
directory tree with multilevels, I have tons of targets, and pseudo-targets
(with no files in list), no logical structure, It's awful! I hadn't find
the way how to disable "servermode support", can you help me?


That is how cmake sees your project:-)

The only way I can think of is to use a wrapper script that removes the
server mode flag from cmake -E capabilities output.

I do plan to remove the non-server-mode support at some point. Probably
when most Linux distributions ship with a server-mode enabled cmake binary.

This is blocking me from upgrade to 4.3 release.


That is unfortunate:-(

Some information: I have around 200 targets, *2 for cmake object libraries
(i cant dissable that), plus 5 cmake targets for each app bundle (~15), It
totally messed up!


So what do you want to see? How can I improve the tree for you?

I don't want to see all that (or at lest have multiple level groups like
MSVS generator does)


No idea what MSVS generator does:-(

Creator needs a view of how the build system thinks the project is
structured. "Project" is that view.

We have a lot of people that want a navigation view of the project, which
would need to be more configurable:-) I got a bug report for that open for
a long time now, but never got around to implement it.

Best regards,
Tobias

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Project Wizard: Label with Hyperlink

[Tobias Hunger]

Hello Günther,

> I was wondering if it is possible to use Hyperlinks in custom JSON-based Qt 
> Creator Project Wizards.

> When adding a custom Field Page with a Label Widget, it's possible to use 
> RichText, for example to make the text bold or add a link using the  tag.

> The text within the  tag is correctly marked as a link, but I didn't find 
> a way to react to the linkActivated signal of the label to e.g. open the 
> web-page.

> Is there a way to open links with JSON-based wizards, and if yes how?

Not that I am aware of:-)

How would you want that handled? Is it enough to always open an external web 
browser? That kind of functionality should be easy to add.

> Thanks for your help!

You are welcome.

Best Regards,
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, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Plugin development - Anubis language support

[Tobias Hunger]

Hi JeremY,

Based on your screenshot: My guess is that Qt Creator does not have any 
compiler defined for your language.

What does the Tool chains tab show? Is there an anubis compiler listed there?

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Code review process for Qt Creator patches

[Tobias Hunger]

On Tue, 2017-04-18 at 04:42 +, Roessler, Alexander wrote:
> Hello,
> 
> 
> I have made some changes to the Autotoolsprojectmanager plugin for Qt Creator
> which I would like to push upstream.

Thank you for considering to upstream your work! That is appreciated:-)

> How can I submit my patch to the code review process for Qt Creator?

The initial setup is a more challenging than it should be:-/ But the setup works
well once you are over the initial hump. I guess this is why nobody bothered to
polish the first steps:-)

https://wiki.qt.io/Setting_up_Gerrit (already pasted by André) seems to be the
simplest set of instructions I know of:-)

Please add me as a reviewer (or ping me by mail), I will look into the patch
once it is up for review on gerrit.

Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] RubyCreator upstream or not upstream

[Tobias Hunger]

Hi Hugo,

I would personally like to see a ruby plugin: I like ruby and
occasionally have to do small changes to ruby projects. Eike is the
one to make that call though.

This is not a decision of "in or out": We could also set up a
repository on our infrastructure and add that into the public Qt
Creator super repository (see here:
https://codereview.qt-project.org/gitweb?p=qt-creator/qtc-super.git;a=summary
).

Your plugin gets a bit more visibility that way and will be part of
the build of more developers. That already helps with the "we break
stuff all the time and do not even notice" problem:-)

Ideally we would even build the plugins (provided they do build at the
time) to avoid the hassle of creating plugins that are compatible with
our Qt Creator binaries. We have plans for that, but as far as I
understand the problem we will need to get Qt Creator into the Qt CI
first. So this is not happening anytime soon.

Best Regards,
Tobias

On Sat, Apr 8, 2017 at 1:44 AM, Hugo Parente Lima  wrote:
> Hi QtC devs.
>
> I'm a C++ developer that 3 years ago started a job with Ruby/Web, so to not
> loss my C++ skills and to continue to use the IDE I love I started
> RubyCreator, a plugin to QtC that add support to Ruby on QtC.
>
> I use it on my daily work since then and add features when I have time and
> motivation to do so, Orgad Shaneh help me with patches adapting my plugin to
> the frequent QtC API changes (since I usually only catch these changes when
> ArchLinux updates QtC), so he also gave me the suggestion to try to push my
> plugin upstream, this would:
>
> - Reduce the headaches of adapt my code to the frequent QtC API changes.
> - Solve the problem of windows/mac compilation/distribution.
> - Have more users :-), some friends of mine use mac and refuse to waste time
> compiling things.
>
> Ok, so I ask you guys if the QtC devs have some interest in accept this
> plugin upstream, if so, some things need to be adjusted beforehand.
>
> - Convert file naming code style to QtC one.
> - Convert general code style to QtC one (I think it's already done).
> - Review all the code before let it merged (of course), since I probably
> missused some QtC API.
>
> If there is not interest, I'm fine too, and I'll just keep the development
> as it is now.
>
> Here is more info about the plugin:
>
> Outdated webpage: http://hugopl.github.io/RubyCreator/
> Github project: https://github.com/hugopl/RubyCreator
>
> Thanks
> --
> Hugo
>
> ___
> Qt-creator mailing list
> Qt-creator@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Where to install Ninja on macOS Sierra (10.12)

[Tobias Hunger]

Hi Mike,

I am not much of an Apple user, so I hope I do not make a fool out of myself by
trying to answer:


Creator should not default to ninja unless it sees a "ninja" binary in PATH.

On Thu, 2017-04-06 at 12:42 -0400, Mike Jackson wrote:
> What is the recommended location to install ninja on macOS Sierra so 
> that QtCreator can find it? We tried the usual /usr/local/bin but 
> QtCreator does not seem to find it there.
> 
> Note: putting it in /usr/bin or /bin is NOT a correct answer since SIP 
> is on by default and will not allow it.

Add the directory with Ninja to PATH? Does that work?

Creator will call "cmake --build .". CMake needs to find ninja somehow. From
what I see in the manual CMake should find anything in PATH, but I got a report
that this is apparently not the case on Macs.

> Could QtCreator ship with a Ninja in its "Resources" directory or is 
> there some preference setting (like the CMake path) that we are missing?

No, there is no special setting.

I would love to ship more development tools with Qt Creator (e.g. cmake, ninja,
git) and have them optionally installed along with the IDE. But this is not my
call to make, no idea whether or not we will do so.


Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator 4.3 Beta and CMake 3.7.x Server Mode Slowness

[Tobias Hunger]

On Wed, 2017-03-29 at 15:32 -0400, Mike Jackson wrote:
> > I did look into the duplicate Source Directories you reported today.
> > Those are caused by the same target being listed for different
> > projects, but so far I could not see how those targets ended up in
> > different projects. I think that is not even allowed in cmake, IIRC
> > the target names need to be unique per build system. I will need to
> > check the docs again to make sure though.
> > 
> > I need to think about what to do in such a situation. It will probably
> > be best to mark up the targets as "project::target" or something and
> > keep them separate.
>
> I would vote for that just to help us clean up our CMake codes. If we 
> have something messed up that the other generators deal better with 
> (Althrough the Xcode generator would show similar issues) then it would 
> be a big help for us.

I asked on the cmake list and they pointed here:

https://cmake.org/cmake/help/v3.8/policy/CMP0002.html

So having the same target name below different project names in one bigger build
system is a bug. Technically I would feel fine to just ignore the issue, but
then I will keep getting bug reports about broken cmake projects going forward.
There seem to be a lot of those out there:-).

Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator 4.3 Beta and CMake 3.7.x Server Mode Slowness

[Tobias Hunger]

Hi Mike,

On Wed, Mar 29, 2017 at 3:24 PM, Mike Jackson  wrote:
>> Please try again with the upcoming nightly builds. For Cristian they make
>> things
>> work better: Initial project tree setup went down from 140s to 2s for his
>> project. I hope you will see similar results.
>
>
> I did a HUGE improvement in load speed. Not counting the actual running of
> CMake, the load time is definitely under 10 seconds now. MUCH much better.

Great!

> Is there anything I can do differently in our CMake files to get the headers
> to be actual project files. They all show with a light gray text which means
> code completion does not work in the files.

The light grey means they were not explicitly listed in cmake, but
cmake did have an include path to that location.

You should also get headers in black -- provided you listed your
headers as SOURCES in cmake. Those will be with the other sources in
the respective target.

Whether a header is grey or black should not have any influence on the
code model: It evaluates the include paths only.

> Thanks for the improvements.

I did look into the duplicate Source Directories you reported today.
Those are caused by the same target being listed for different
projects, but so far I could not see how those targets ended up in
different projects. I think that is not even allowed in cmake, IIRC
the target names need to be unique per build system. I will need to
check the docs again to make sure though.

I need to think about what to do in such a situation. It will probably
be best to mark up the targets as "project::target" or something and
keep them separate.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator 4.3 Beta and CMake 3.7.x Server Mode Slowness

[Tobias Hunger]

On Wed, 2017-03-29 at 08:10 -0400, Mike Jackson wrote:
> I have been using the nightlies and the time to open our project 
> (DREAM.3D) is getting better but still can induce a spinning beach ball 
> on my macOS 10.10 machine (12 Core Xeon with SSD).

Please try again with the upcoming nightly builds. For Cristian they make things
work better: Initial project tree setup went down from 140s to 2s for his
project. I hope you will see similar results.

In master I want to move the whole project tree creation into a thread.
Unfortunately the preparation took too long to get this into 4.3 :-/

> One of the issues that I wanted to make sure that you are also seeing is 
> the "Multiple Targets" issue where we get executables that are numbered 
> like DREAM3D,DREAM3D2,DREAM3D3.

That is still on my Todo list, sorry.

> There is also an issue with multiple "Source Directory" and "Build 
> Directory" showing up in each target in the projects view. I have a 
> feeling that some of this may be how we are using CMake?

It probably is: I do not see that issue with my projects. But Cristian has
reported the same issue, so you are not alone:-)

> Our project as 
> a whole ends up having multiple "project(...)" invocations.

That _should_ be safe with server mode (and ignored in the tealeaf reader).

> Also is 
> there an implicit assumption the for each "CMakeLists.txt" is a project? 

No. The Project is basically just a kind of tag that gets assigned to the
CMakeLists.txt files that contain PROJECT.

> In our plugins we use CMakeLists.txt files BUT they do not have a 
> "project()" call in them and they are included with "include()" instead 
> of "add_subdirectory()" which might make a difference.

That might be what is causing the multiple Source directories. I'll need to look
into that.

> Thanks for moving the CMake integration forward.

You are welcome.

Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator 4.3 Beta and CMake 3.7.x Server Mode Slowness

[Tobias Hunger]

Hi Mike,

I found a couple of optimization opportunities. Let's see how much
difference these will make:-)

Some smaller ones are in already, but the big one (finding CMakeLists
again after they were inserted) is still open.

On Fri, Mar 24, 2017 at 4:43 PM, Mike Jackson <imikejack...@gmail.com> wrote:
> Tobias Hunger wrote:
>>
>> On Fri, Mar 24, 2017 at 2:04 PM, Mike Jackson<imikejack...@gmail.com>
>> wrote:
>>>>
>>>> Well, server-mode does get way better information out of cmake, so
>>>> that is kind of expected:-)
>>>>
>>>> What does the code model say (Tools>C++>Inspect C++ code model)? Does
>>>> it list the expected include directories?
>>>
>>>
>>> I just noticed that the issue is when I look at a .h file in the editor.
>>> In
>>> the project list the .h file is grayed out and the code model only shows
>>> a
>>> few include paths. Its like the Project Model does not know how to handle
>>> the .h files because they are not compiled?
>>
>>
>> That should not make any difference: Those header files are not ever
>> passed on to the code model:-) That just gets the sources and include
>> paths and then figures stuff out itself.
>>
>>>> I want to get rid of the tealeaf mode as soon as possible. The name is
>>>> fitting: What Creator is doing without server-mode is reading in tea
>>>> leaves, mostly tea leaves that are documented to change meaning at any
>>>> time!
>>>>
>>>> Perpetuating tealeaf mode by having users enable it for newer cmakes
>>>> is definitely not in my interest!
>>>
>>>
>>> I agree philosophically but there may be a practical side of things. Lets
>>> see if the issues all get fixed by release of QtCreator 4.3 then I really
>>> will not have any argument at that point.
>>
>>
>> I do not find anything to fix: DREAM.3D opens in<  5s for me.
>>
>> A couple seconds later (for C++ parsing, Test scanning, etc.) the CPU
>> usage is down to below 5% on all cores.
>>
>> Ninja reports only 1351 things that need building though, so maybe I
>> did something wrong?
>
>
> I tried again with build -997 and it does seem much faster now. I wonder
> what changed between -992 and -997. Do you still see multiple "DREAM3D"
> targets on the list? I see DREAM3D, DREAM3D2, DREAM3D3 and a few other
> targets within the main project show up like that.
>
>>
>>>> I'm currently trying to set up DREAM.3D for testing:-)
>>>>
>>>> So far I found two smaller issues with creator's cmake support due to
>>>> it -- and I did not even manage to make it build yet:-) What a
>>>> wonderful test project!
>>>
>>> Interesting. What were the issues? If you do find issues with DREAM.3D or
>>> any of its subprojects just let us know or put in an issue at GitHub.com.
>>> Our use of CMake may not be completely standard or may be unexpected.
>>> Some
>>> of the CMake code has been in there since 2009.
>>
>>
>> Small stuff inside Creator. E.g. Creator should *always* show at least
>> the top level CMakeLists.txt file and a broken configuration of
>> DREAM.3D broke that. Fixed now.
>>
>> 
>>>>
>>>> Well, cmake is heavily single-threaded, so all your cores will not
>>>> help with anything cmake-related:-)
>>>
>>> So when QtCreator is spinning a beach-ball on macOS and QtCreator is only
>>> burning 100% is that because CMake is taking a while to do something?
>>
>>
>> No idea:-)
>>
>> What does the progress bar say when creator is busy? That should give
>> a hint as to what is going on. As I said: It takes about 5s to open
>> DREAM.3D on my laptop and that is a considerably less capable machine
>> than yours.
>
>
> The beach-ball really prevents anything from being seen. Nothing obvious
> that I can see. Is it possible to output something to the "Application
> Output" or "Compile Output" widgets that indicates that information is being
> gathered from CMake? Or maybe there is a way for me to log that and I just
> don't know about it (Most likely..).
>>
>>
>>> Configuring our project can take upwards of 30 seconds on macOS and Linux
>>> and even longer on Windows. You can check the times at
>>> http://my.cdash.org/index.php?project=DREAM3D, clicking the gear icon in
>>> the
>>> upper right side and selecting Advanced View.
>>
>>
>&g

Re: [Qt-creator] QtCreator 4.3 Beta and CMake 3.7.x Server Mode Slowness

[Tobias Hunger]

On Fri, Mar 24, 2017 at 2:04 PM, Mike Jackson  wrote:
>> Well, server-mode does get way better information out of cmake, so
>> that is kind of expected:-)
>>
>> What does the code model say (Tools>C++>Inspect C++ code model)? Does
>> it list the expected include directories?
>
>
> I just noticed that the issue is when I look at a .h file in the editor. In
> the project list the .h file is grayed out and the code model only shows a
> few include paths. Its like the Project Model does not know how to handle
> the .h files because they are not compiled?

That should not make any difference: Those header files are not ever
passed on to the code model:-) That just gets the sources and include
paths and then figures stuff out itself.

>> I want to get rid of the tealeaf mode as soon as possible. The name is
>> fitting: What Creator is doing without server-mode is reading in tea
>> leaves, mostly tea leaves that are documented to change meaning at any
>> time!
>>
>> Perpetuating tealeaf mode by having users enable it for newer cmakes
>> is definitely not in my interest!
>
>
> I agree philosophically but there may be a practical side of things. Lets
> see if the issues all get fixed by release of QtCreator 4.3 then I really
> will not have any argument at that point.

I do not find anything to fix: DREAM.3D opens in < 5s for me.

A couple seconds later (for C++ parsing, Test scanning, etc.) the CPU
usage is down to below 5% on all cores.

Ninja reports only 1351 things that need building though, so maybe I
did something wrong?

>> I'm currently trying to set up DREAM.3D for testing:-)
>>
>> So far I found two smaller issues with creator's cmake support due to
>> it -- and I did not even manage to make it build yet:-) What a
>> wonderful test project!
>
> Interesting. What were the issues? If you do find issues with DREAM.3D or
> any of its subprojects just let us know or put in an issue at GitHub.com.
> Our use of CMake may not be completely standard or may be unexpected. Some
> of the CMake code has been in there since 2009.

Small stuff inside Creator. E.g. Creator should *always* show at least
the top level CMakeLists.txt file and a broken configuration of
DREAM.3D broke that. Fixed now.


>> Well, cmake is heavily single-threaded, so all your cores will not
>> help with anything cmake-related:-)
>
> So when QtCreator is spinning a beach-ball on macOS and QtCreator is only
> burning 100% is that because CMake is taking a while to do something?

No idea:-)

What does the progress bar say when creator is busy? That should give
a hint as to what is going on. As I said: It takes about 5s to open
DREAM.3D on my laptop and that is a considerably less capable machine
than yours.

> Configuring out project can take upwards of 30 seconds on macOS and Linux
> and even longer on Windows. You can check the times at
> http://my.cdash.org/index.php?project=DREAM3D, clicking the gear icon in the
> upper right side and selecting Advanced View.

I must be doing something wrong then, my machine is much faster than that.

> Maybe popping up a dialog if it is taking longer than xx seconds to run the
> CMake part? That way it does not look like it is hung up? I imagine for
> smaller projects this is not a problem because CMake runs fast enough on
> those projects.

I do not think that cmake is the problem here. You know how long it
takes to run cmake on the command line and Creator should never be
slower than that.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator 4.3 Beta and CMake 3.7.x Server Mode Slowness

[Tobias Hunger]

Hi Mike,

On Thu, Mar 23, 2017 at 8:13 PM, Mike Jackson  wrote:
> One thing that I notice is that with Server-mode the code completion engine
> can not find things like #include  which basically messes
> up the code completion on the file.This does not preclude the fact that our
> CMake may be non-optimal and missing some include_directories() and we just
> have never noticed it before on Visual Studio, Ninja, NMake, Makefiles and
> Xcode, but none of those use Server-Mode so we may be in new territory.

Well, server-mode does get way better information out of cmake, so
that is kind of expected:-)

What does the code model say (Tools>C++>Inspect C++ code model)? Does
it list the expected include directories?

>>> My point is NOT to complain since I understand these features are
>>> experimental and still being developed. If by the the final release the
>>> slowness is still there, is there going to be a way to turn OFF the CMake
>>> server mode link if I am using CMake 3.7?
>>
>>
>> None is planed.
>
>
> I know it is late, but I would _really_ want to discuss that. Again, if
> there is time or it would be simple to implement, like a check box in the
> CMake configuration widget.

I want to get rid of the tealeaf mode as soon as possible. The name is
fitting: What Creator is doing without server-mode is reading in tea
leaves, mostly tea leaves that are documented to change meaning at any
time!

Perpetuating tealeaf mode by having users enable it for newer cmakes
is definitely not in my interest!

> All of our projects are open-source.
> http://www.github.com/bluequartzsoftware/dream3d. There are other repos that
> will need to be pulled. I there are some really rough docs that point you to
> them. We have a bunch of dependent libraries. If you clone
> https://github.com/BlueQuartzSoftware/DREAM3DSuperbuild that should help
> build up an SDK for DREAM.3D to use. I have not tested it too much on newer
> Linux distributions so not sure how well it would behave. You could probably
> get DREAM.3D to compile without the DREAM3DSuperbuild by just pointing CMake
> to all the various locations on your Linux machine.

I'm currently trying to set up DREAM.3D for testing:-)

So far I found two smaller issues with creator's cmake support due to
it -- and I did not even manage to make it build yet:-) What a
wonderful test project!

> Just some stats on the project with a full compile of all our Plugins there
> is something like 2400 compilable files. We do depend on things like Boost
> and Eigen which are heavily templated which might be the cause.
>
> I would also be ok setting up a Google Hangout and screen sharing my machine
> so you can see what is going on.

Thanks, for the offer. I might take you up on it if I can not
reproduce the issue locally.

> I jumped on the Qt4.3 bandwagon with CMake 3.7 pretty quickly to test it
> out. If I remember correctly back in January time frame the speed wasn't
> noticeably slower. I would have to go pull those versions and start testing
> to figure out when it really went slow.
>
> I restarted with the -settingspath /tmp/foo and the code completion seems to
> subjectively be faster. THe command-K is definitely faster. Project loading
> is still slow, to the point where I get the spinning beach ball for about 1
> minute. This is on a 12 Core (24 Threads) Mac Pro running macOS 10.10.5 off
> an SATA SSD (850 EVO).

Well, cmake is heavily single-threaded, so all your cores will not
help with anything cmake-related:-)

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator 4.3 Beta and CMake 3.7.x Server Mode Slowness

[Tobias Hunger]

Hi Mike,

you are not the first to report this:-/ This needs to be fixed before
the release.

On Thu, Mar 23, 2017 at 6:40 PM, Mike Jackson  wrote:
> I have been testing the nightly builds of 4.3 and the main issue that I am
> running into for our project is that most everything is very slow. From
> loading the CMake based project, to "command-K" to code-completion. The
> slowness is somehow attributed to using CMake 3.7.x and its server mode. If
> I load my project using CMake 3.6 then the everything returns be being fast
> again.

That is interesting: The only difference between server mode and
tealeafreading mode is in getting data from cmake and parsing that
data. After the project data is read, everything is using exactly the
same code.

The project tree is a bit different, but that should not be noticable.

> My point is NOT to complain since I understand these features are
> experimental and still being developed. If by the the final release the
> slowness is still there, is there going to be a way to turn OFF the CMake
> server mode link if I am using CMake 3.7?

None is planed.

> We are starting to depend on a few
> of the CMake 3.7 features but then that causes QtCreator to just drag down
> in speed to the point where it becomes somewhat unusable.

I never had that happen to me before. Is one of the projects you work
with open source so that I can test with that?

Could you try with clean settings (just run with -settingspath
/tmp/foo)? Does it get faster if you disable non-essential plugins?

Did you notice that slowdown before? You said you started to depend on
some of those features, so I guess you did run server-mode before:-)

> Thanks and keep up the great work with the CMake integration. It has come so
> far and I really enjoy working with QtCreator.

You are welcome.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Gcc and internationalization

[Tobias Hunger]

On Thu, 2017-03-16 at 08:52 +0100, Frédéric Marchal wrote:
> Hi,
> 
> I'm using Qt Creator 4.2.1 Based on Qt 5.8.0 (GCC 5.3.1 20160406 (Red Hat 
> 5.3.1-6), 64 bit) Built on Jan 20 2017 01:20:15 From revision 7071b61e02.
> 
> Two features of QtCreator are broken if gcc messages are translated.

Yes, that is correct. The entire parsing of compiler output is based on
strings... and the GCC people thought it is a good idea to translate things like
"error" and "warning" that Creator latches onto.

MSVC does not do that, so that still mostly works, even when translations are
present.

> Is there something I can do from the QtCreator side to fix it?
> 
> Or should I open two bug reports?

I do not consider these two to be bugs: I fully expect that to not work and I do
not see any way we will ever be able to enable that (without GCC producing a
machine-readable output that is:-).

Creator should start the GCC with the C locale enforced. If that is not the
case, then that is a bug I will need to look into.

Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator 4.3.Beta1 + CMake 3.7.2 Header files of Project not found?

[Tobias Hunger]

On Tue, 2017-02-21 at 08:23 -0500, Mike Jackson wrote:
> Using the latest nightly from QtCreator 4.3.Beta1(866) there seems to be 
> a problem with include paths for header files? Screenshot attached. All 
> of our headers are listed as sources for each of their respective 
> projects. This works very well with QtCreator 4.2.x.

Headers explicitly listed as source files in CMake do get detected for me just
like they are in tea leaf reading mode (CMake without server-mode).

>  This is also 
> leading to the code completion not working with our header files because 
> the include paths can not be found.

What include paths do you set in CMake? Do you "set(CMAKE_INCLUDE_CURRENT_DIR
ON)" in your CMakeLists.txt files?

> Just giving some feedback on what we are seeing with the latest builds. 
> This is on macOS 10.10.5 with Xcode 7.2.1 tooling.

Thanks for the feedback, it is very much appreciated!

Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Plugin development - Anubis language support

[Tobias Hunger]

Hi Larrieu,

sorry for taking so long to reply!

On Tue, 2017-02-21 at 07:12 +0100, Larrieu JeremY wrote:
> Currently, I'm developing a plugin to support a "new" language in
> qtcreator: Anubis (FR https://fr.wikipedia.org/wiki/Anubis_(langage)).
> 
> I've already developed the part to support project files and i need some
> help for the "Build & run" part.
>
> Anubis works with a compiler (called anubis) and a virtual machine (called
> anbexec).
> I've tried to use BuildConfigurations (IBuildConfigurationFactory, ...) but
> it refers to kits which seems to not fit the need.
> Kits refers to compiler like gcc and several options that are not relevatnt
> to the Anubis environment.

The NimPlugin is probably something you can use as a rough guideline.

It is still pretty simple, but already registers Nim as a supported programming
language, enables Nim compilers in the Kits and does build and run Nim programs.

> So, I planned to add a page in the options dialog to manage the Anubis
> environments: several versions of the environment can exist on the same
> machine (each have a seperate folder).
> And an option page in the project options near the "Build & run" page.
> But, I don't see how I can make the "Build" (ctrl+b) or the "Run" (green
> play button) triggers the Anubis compiler or vm.

You will need to provide Build- and RunConfigurations for that to work. You
might also need a RunControl to handle the actual process of running something.

Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Gerrit improvements?

[Tobias Hunger]

On Mon, 2017-02-20 at 17:03 +0100, Jason H wrote:
> Recently, I was requested to interact on Gerrit, and I checked out the gerrit
> config on creator.I was happy that there was a gerrit section but there seemed
> to be quite a difference between that and the gerrit setup instructions  at ht
> tps://wiki.qt.io/Setting_up_Gerrit were quite complicated. It would be nice if
> the existing gerrit support could be amended to perform these actions for me?

Yes, I agree.

> Compared to the "examples" experience (which is quite awesome - super user
> friendly) I think this section could use a little love.

I worked on a wizard to get a contribution-ready Qt/Qt Creator a while ago. I
could not automate most of the server-side configuration issues, so I never
commited that though.

The Qt Account was just getting introduced back then, so the whole registration
process was in flux, too. Maybe I could try again now that the web-side of
things apparently has stabilized. But even today we do not really have one place
where a user can set up all the required information to work with JIRA, Gerrit
and all the other Qt sites AFAIK. Having that would simplify that task a lot.

Creator could definitely help with e.g. generating SSH keys.

Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] REST support in Gerrit dialog

[Tobias Hunger]

On Wed, 2017-02-15 at 12:26 +0200, Orgad Shaneh wrote:
> Hi,
> 
> The Gerrit dialog was improved recently, and it now connects to the
> remote[s] according to the origin url of the active repository. This
> currently supports SSH remotes only.
> 
> I'd like to add support for querying using gerrit's REST API in the Gerrit
> dialog.
> 
> This has the following advantages:
> 
>    - It is typically faster than SSH
>    - It is typically *not* blocked by firewalls
>    - It is more advanced (we can get more data than by ssh query)
>    - Some servers (like gerrit-review.googlesource.com) support *only* HTTP

Sounds nice:-)

> In order to use REST, the user must generate HTTP password in gerrit's
> preferences, and configure it locally.
> 
>    - On linux, ~/.netrc should contain a line like:
>    machine codereview.qt-project.org login  password 
>    - On Git for Windows it's similar, but the file is named ~/_netrc. In
>    addition, if git is configured to use the Git Credentials Manager, then the
>    user will be asked for the credentials on first connection to the server
>    using Git (usually on git fetch).
>    - On macOS I have no idea, but it's likely to be similar to linux (macOS
>    users, please approve).
> 
> Apart from that, Gerrit uses Digest authentication by default, but can be
> configured to use Basic auth (for example, to enable LDAP authentication).
> 
> Now, since this is not a trivial task user-wise, I'd like to hear your
> opinions.
> 
>    1. Should Qt Creator ask for the user's credentials and configure them
>    automatically (if they're not present in .netrc)?

Yes.

>    2. Does it make sense to have some kind of a wizard when a new server is
>    discovered, to guide the user through generating the password etc.?

Yes.

>    3. When should we test (and configure if needed) the connection to the
>    server?
>   1. Right when the user chooses the server?
>   2. When hitting the "Refresh"  button?
>   3. Add a new button for that, next to the remotes list?

1) makes the most sense to me.

>    4. Where/how do we store the list of "supported" servers? What I
>    currently have in mind is Qtc configuration, in sections like
>    GitServers//GerritRest = 1 etc.

Can't you try to connect using REST on first connect and then cache that
information going forward?

>    5. Is it ok to use curl on all platforms, or do we have a reliable Qt
>    HTTP transport, which supports Basic/Digest authentications (gerrit uses
>    Digest by default, but can be configured for Basic)?

Qt has no support for HTTP? That would be surprising:-) But I admit I never
tried.

Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Handling of Qt frameworks in the combination of clang code model and generic project manager

[Tobias Hunger]

Hi Andreas,

On Tue, 2017-02-07 at 15:20 +0100, Andreas Pakulat wrote:


> I wonder though; Would it be possible that QtCreator detects that one
> of the given entries is a framework and pass this information on to
> the clang code model (and likely eventually libclang) so that the
> include-resolving happens the same way it works during compilation?

Not right now. But of course code could get contributed to add such a feature.
The simplest way would probably be to put to enable that.

The simplest possible approach is probably to just treat include paths ending in
"" as frameworks or something. Should not be too hard to add.

As always: Patches are welcome.

Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Proposal: Increase requirements for compiling Qt Creator to GCC>=4.9

[Tobias Hunger]

On Mon, 2017-01-16 at 11:48 +, Eike Ziller wrote:
> I propose increasing the GCC compiler requirements for compiling Qt Creator,
> starting with 4.3, to GCC >= 4.9.
> https://codereview.qt-project.org/182471

+1

Best Regards,
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, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator