| Author |
 Topic  |
|
|
jschmidt
New Member
Canada
4 Posts |
 Posted - Jul 27 2011 : 09:52:56 AM
|
The Add Include option under the contextual menu Refactor is really a useful tool, but sometimes, when you use the option for types like QPushButton (mostly include from 3rd party) and such you get:
#include "qpushbutton.h" instead of #include <QPushButton> (without the .h, the quoting is not important, can be "" or <>)
Could it be possible to detect header without extension first and include them if available? I know it is really library dependent, but for QT it would be nice cause the casing is not the same. QT always have a extension less header that directly include the header with an extension.
Thanks |
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jul 31 2011 : 12:46:27 PM
|
*uh* This is a special problem. Every library has its own policy and some of them uses special logic, like in this case. It cannot be solved generally, since strictly speaking VA includes the header which contains the symbol definition, so it can be considered "normal".
Is this causing any serious problem (i.e. with compiling or using the library), or is it "just" a cosmetic issue?
Simply only detecting whether the header has extension would have cause problems for other libraries / projects.
I'm not sure if is there any simple solution here, rather that supporting QT specifically. |
 |
|
|
chrisaverage
Junior Member
Poland
20 Posts |
Posted - Feb 17 2014 : 10:21:24 AM
|
I'm a heavy user of Qt too, so it would be really nice to have this. Also Qt is quite popular these days so targeting it specifically might not be that bad of an idea.
There are not many libraries with Q-starting classes so maybe this could be used as an indicator?
If you don't like the idea of targeting specific libraries maybe this could be generalized into some sort of user defined regexp or templates like:
^Q.* --> <%SYMBOL%>
^SomeLib.* --> "Some/Lib/%SYMBOL_LOWERCASE%.h"
or something like this. This could cover a lot of (if not most of) the libraries out there. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Feb 18 2014 : 4:19:36 PM
|
We have added some special handling for Qt already, for handling signals and slots, and we do see quite a few support requests that involve Qt to some degree or other.
The regular expression idea is interesting, but it is likely to run into so many edge cases that I am not sure its going to be that useful.
As accord asked, is this actually causing any problems, or is it simply a cosmetic issue? If its causing actual problems then it is obviously more urgent. |
zen is the art of being at one with the two'ness |
|
|
|
chrisaverage
Junior Member
Poland
20 Posts |
Posted - Feb 20 2014 : 08:13:37 AM
|
There are no problems (that I know of) like something not compiling or linking etc. so yeah, it's not extremely urgent.
It's a matter of style and convenience mostly. It's along the lines of including "stdlib.h" instead of <cstdlib>.
As such it usually causes code review feedback so for Qt types I end up either fixing the includes or typing them in manually in the first place.
It's a very deeply rooted convention in Qt world and it's just that nobody actually does it differently, and if they do they're immediately asked why :)
Another comment here is that the extensionless headers correspond to the Qt classes, while it's not always the case with .h files, eg.
both <QDate> and <QDateTime> include "qdatetime.h" or <QEvent> actually includes "qcoreevent.h".
It's easier for example to cleanup the includes when they correspond exactly to used classes instead of finding which include is actually for what. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Feb 27 2014 : 11:40:46 AM
|
We are considering some way of handling this general situation, but its not yet clear how best to do that. I have added Qt to the libraries we want to look at for this:
case=37006 |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Apr 07 2014 : 3:40:30 PM
|
| build 2031 improves add include results for Qt 5 in some scenarios. |
|
|
|
chrisaverage
Junior Member
Poland
20 Posts |
Posted - Apr 07 2014 : 4:49:56 PM
|
| Thanks for this. It works almost ok but it still includes eg. "QByteArray" when it should include <QByteArray>. |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Apr 07 2014 : 6:52:00 PM
|
<> should be used if you added the Qt include dirs to:
Project Properties | Configuration Properties | VC++ Directories | Include Directories
"" is used if you added Qt include dirs to:
Project Properties | Configuration Properties | C/C++ | Additional Include Directories
(Unless you have modified the AddIncludeTokenStyle VA registry value from the default of 0 per http://support.wholetomato.com/default.asp?W338.)
|
|
|
|
chrisaverage
Junior Member
Poland
20 Posts |
Posted - Apr 08 2014 : 05:04:54 AM
|
Actually I did neither (myself). There's a Qt add-in for Visual Studio that does that when you select Qt modules in a configuration dialog.
From what I see they indeed add that in the C/C++ section. Do you think this is something I should ask Qt guys to fix in the plugin? |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Apr 08 2014 : 12:43:17 PM
|
One other difference about the two directory lists is that if you use the VA "Stable symbols in italic" option, then Qt symbols will be rendered in italic if the Qt dirs are listed on the VC++ Directories page rather than the C/C++ page.
I don't think it is a Qt config bug per se, but it would be good if they offered the option to add the include dirs to one or the other list.
|
|
|
|
Predelnik
Senior Member
Russia
37 Posts |
Posted - Apr 09 2014 : 10:22:30 AM
|
Well I also interested in such behaviour with Qt but even using 2031 beta, can't achieve anything similar.
I have AddIncludePreferShortestRelativePath set to 0 and it just prints full path to Qt header, starting from "C:\\...", if I have this option turned on path is relative but still long. So what should I do to enable this behavior?
And also regarding additional include directories, QMake default behavior is to put Qt related paths there, so I don't think it would be easy to change that.
|
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Apr 09 2014 : 11:36:08 AM
|
What version of Qt?
What paths are added to Additional Include Directories?
When AddIncludePreferShortestRelativePath is at the default value of 1, what text does add include insert? |
|
|
|
Predelnik
Senior Member
Russia
37 Posts |
Posted - Apr 09 2014 : 3:08:53 PM
|
Well I use stable branch from Qt git, `qmake -v` shows me 5.3.0 version.
Let's say "C:\\rfd\\qt-git-5-x64" - is path to my Qt
My additional include directories (I leave only Qt related paths):
quote:
"C:\\rfd\\qt-git-5-x64\\qtbase\\include";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtOpenGL";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtPrintSupport";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtSvg";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtWidgets";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtNetwork";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtGui";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtCore";C:\\rfd\\qt-git-5-x64\\qtbase\\mkspecs\\win32-msvc2013;"
On the other hand I would note(maybe it's important) that sources dir for the project I'm working on is written as a related path, like "..\\src". There is also a bunch of dependencies with full path which most likely do not matter in this case.
With AddIncludePreferShortestRelativePath - 1, it adds something like:#include "../src/corelib/io/qurl.h"
with 0, it adds something like: "c:/rfd/qt-git-5-x64/qtbase/src/corelib/io/qurl.h"
By the way correct (absolute) path to this file should actually be "c:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtCore\\qurl.h"
So it's very disturbing, maybe you have supported this stuff only for Qt4, because all of these duplicated headers in Qt5 seem to be confusing for VAX.
|
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Apr 09 2014 : 3:47:55 PM
|
Yes, the duplicate headers are a problem. It looks like you are trying to use AddIncludePreferShortestRelativePath to deal with that problem but AddIncludePreferShortestRelativePath just muddles the situation since it assumes a single header file in one location - it was not introduced to deal with header files being duplicated.
In my Qt project, I link to libs/dlls so I do not have any qt /src/ dirs in my additional include dirs. The include dirs you listed do not have any qt /src/ dirs either. Do you have the qt /src/ dirs listed somewhere? Or are you compiling qt /src/ dirs in your project?
|
|
|
|
Predelnik
Senior Member
Russia
37 Posts |
Posted - Apr 10 2014 : 07:12:04 AM
|
Well I've posted all Qt related directories here, so there's no src directory mentioned explicitly. And /src dirs are definetily not used in project.
That's really weird though, looks like path "../src/corelib..." is based on "%QT_DIR%/include" include which is kinda strange behavior. |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Apr 10 2014 : 12:10:18 PM
|
When your solution is loaded, open the VA Options dialog; on the C/C++ Directories page, what Platform is selected? By default, it should be Project defined.
Change the Show Directories for dropdown to Source files. Are the Qt src dirs listed there?
|
|
|
|
Predelnik
Senior Member
Russia
37 Posts |
Posted - Apr 11 2014 : 02:20:51 AM
|
Yes, "Project defined" is selected and there's no Qt src dirs in source files:
 |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Apr 11 2014 : 02:35:51 AM
|
Can you capture a log of the solution load and of running add include on a qt symbol?
File | Close solution
Enable logging on Performance page of VA options
Load solution
run add include
exit
then zip va.log and send it in via the contact form:
http://www.wholetomato.com/support/contact.asp
|
|
|
|
Predelnik
Senior Member
Russia
37 Posts |
Posted - Apr 11 2014 : 03:09:02 AM
|
| I've sent it. |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Apr 11 2014 : 7:13:44 PM
|
Thanks for the log. I'll use QDialog as an example.
I've just done an install with source from qt-opensource-windows-x86-msvc2012-5.2.1.exe that I downloaded from the project site.
Here are the QDialog headers that are installed:
D:\\src.qt\\Qt5.2.1\\5.2.1\\Src\\qtbase\\include\\QtWidgets\\QDialog (1 line -> includes qdialog.h in same dir)
D:\\src.qt\\Qt5.2.1\\5.2.1\\Src\\qtbase\\include\\QtWidgets\\qdialog.h (1 line -> includes qdialog.h in qtbase\\src dir)
D:\\src.qt\\Qt5.2.1\\5.2.1\\Src\\qtbase\\src\\widgets\\dialogs\\qdialog.h (full class definition - identical to other full one)
D:\\src.qt\\Qt5.2.1\\5.2.1\\msvc2012\\include\\QtWidgets\\QDialog (1 line -> includes qdialog.h in same dir - same as first QDialog)
D:\\src.qt\\Qt5.2.1\\5.2.1\\msvc2012\\include\\QtWidgets\\qdialog.h (full class definition - identical to other full one)
1 version of QDialog copied to 2 directories.
2 versions of qdialog.h where 1 version is copied to 2 directories and a different version is copied to a third directory.
Looking at the 5 paths above, there are 2 subtree groups:
Src\\qtbase\\...
msvc2012\\include\\...
The changes made in VA build 2031 work when using the 2nd subtree (msvc2012\\include\\...) as additional include directories, but not the first (Src\\qtbase\\...). We'll try to improve results for the 1st subtree in the next build.
|
Edited by - sean on Apr 11 2014 7:57:27 PM |
|
|
|
Predelnik
Senior Member
Russia
37 Posts |
Posted - Apr 12 2014 : 01:35:38 AM
|
Thank you.
Looks like Qt built from the source has first subtree only, maybe with some additional build parameters it would change but since it's working as intended without them, no one cares very much anyway. So better work with first subtree would be very much appreciated. |
|
|
|
chrisaverage
Junior Member
Poland
20 Posts |
Posted - Apr 12 2014 : 04:34:31 AM
|
I don't think it should use the first subtree. The so called "offline installers" like the one you used are kinda slice of what the main - online installer does. With it you can install several builds of Qt and source separately. The structure is then:
Src\\qtbase\\...
msvc2012\\include\\...
msvc2010\\include\\...
mingw48_32\\include\\...
I think VA should use the one the project is using, cause they can be configured quite differently, with different defines, modules enabled etc. The Src directory is kinda addition to them if you want to for example build Qt yourself. |
|
|
|
Predelnik
Senior Member
Russia
37 Posts |
Posted - Apr 12 2014 : 05:28:40 AM
|
quote:
Originally posted by chrisaverage
I don't think it should use the first subtree. The so called "offline installers" like the one you used are kinda slice of what the main - online installer does. With it you can install several builds of Qt and source separately. The structure is then:
Src\\qtbase\\...
msvc2012\\include\\...
msvc2010\\include\\...
mingw48_32\\include\\...
I think VA should use the one the project is using, cause they can be configured quite differently, with different defines, modules enabled etc. The Src directory is kinda addition to them if you want to for example build Qt yourself.
Well it's obvious that if Qt is configured to add include dirs from second subtree which is the case when it was installed by installers when the second subtree will be used just fine. So for installed versions nothing will change.
The problem is that when you build Qt yourself(which for example you need to do if you want to use if with MSVC2013 currently) you don't have second subtree at all(at least if you built it without any special options) and dirs from the first one is being added to project configuration and thus not handled correctly.
By the way the best usage of source in installed version is to be able to debug it, it really helps sometimes. |
Edited by - Predelnik on Apr 12 2014 05:29:11 AM |
|
|
|
chrisaverage
Junior Member
Poland
20 Posts |
Posted - Apr 12 2014 : 06:43:23 AM
|
| Well you should use special options (at least --prefix) and not build in the source dir in the first place. For VS 2013(which is MSVC 12.0) you can also find ready binaries(eg. here: http://www.tver-soft.org/qt64) which have a proper tree structure. They do have the .pdb files so you can debug with them, unless of course you want to debug Qt itself, in which case you do need sources. |
|
|
|
Predelnik
Senior Member
Russia
37 Posts |
Posted - Apr 12 2014 : 10:28:42 AM
|
Well but I certainly did not see any reason to add --prefix before this problem with VAX because everything else was working pretty much fine, so I think it's not exactly right to say that it is something completely obligatory.
Well it's nice that some custom sites do these builds on the other hand for example there was a bug in build for VS 2013 in released Qt version so I've had to use version from Git/ apply custom fix anyway, so until it's officially released there's no guarantee that it's working. Maybe now I'll try them though, thank you. |
|
|
|
Predelnik
Senior Member
Russia
37 Posts |
Posted - Apr 14 2014 : 04:24:03 AM
|
| I've tried installable version from http://www.tver-soft.org/qt64 and "add include" for Qt classes works pretty much fine except "QUrl"/<QUrl> issue of course. |
Edited by - Predelnik on Apr 14 2014 04:24:24 AM |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - May 23 2014 : 2:56:43 PM
|
case=80599 was opened for Add Include improvement for Qt.
case=80599 is fixed in build 2036. |
|
|
| |
Topic |
|
Add Include improvements
