Qtilities Update

[Jaco Naude]

Hi Simon

A quick update with regards to our previous discussions and the emails you've sent this morning. I've set up a MSVC environment on my side in order to reproduce the issues you are seeing.

1) The previous commit which I mentioned with regard to the getenv() function call warning did not do the trick. This is now fixed.

2) With regard to the #include <Qtilities> problem. I've decided to remove the ability to do that since it can lead to nasty issues since that file tries to include all files in Qtilities. This would add a bunch of dependencies on your app even if you just want to use QtilitiesCore. For example, it will try to include QtGui based classes etc. Thus, I'm removing it and you need to manually include the modules which you are interested. This is a better and much more controlled approach.

3) With regard to the dominance problem on TreeNode, this is now fixed. I saw that there are hundreds of those errors when building in MSVC. Apologies for that.

4) In regard with the problems you were seeing with QTILITIES_NO_HELP, this is also fixed.

4) I've been testing Qtilities against the final Qt 5 release and there were numerous issues which were introduced since the betas. Most of there are fixed now, but there are a few last outstanding things that needs to be done before its ready and the v1.2 release will be out.

All changes mentioned above are contained in this commit.

As a final note, I'm really impressed with the speed of MSVC, as well as the number of warnings it picks up that MingW and GCC completely missed. I've done limited testing in the past with it, but decided to move my development environment over to MSVC at last, after thinking about doing it for a long time.

Regards,

Jaco Naude'

Qtilities: Building blocks for Qt applications.

http://www.qtilities.org

[Simon Gemmell]

Hi Jaco,

Can confirm issues 1 through 4 are fixed with the latest.

I still get one warning when compiling with QTILITIES_NO_DEBUG commented in and QTILITIES_PROPERTY_BROWSER commented out. 

source\DebugWidget.cpp(397) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

source\DebugWidget.cpp(431) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

source\DebugWidget.cpp(445) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

source\DebugWidget.cpp(459) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

source\DebugWidget.cpp(974) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

source\DebugWidget.cpp(987) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

On the MSVC front: You're impressed with the speed of the built executable? Or MSVC compilation times? I'm sure GCC/MinGW would pick up those warnings with -Wall (no?), but understand that it also generates a lot of other guff. Don't ditch the .pro files - if you're automating your build process you won't be able to run lupdate or lrelease unless you have a .pro file (or you can right click it in VS, but that's not so easy to script :) ). If you're using it as your main dev env, would highly recommend Vissual Assist X. If you work out how to get .pro files playing nicely with VisualStudio Filters let me know as we have a VS project structure but no .pro/.pri files. 

Regards,

Simon

[Jaco Naude]

Hi Simon

Please see my replies inline below.

Thanks,

Jaco

On Wed, Jan 16, 2013 at 6:06 AM, Simon Gemmell <simong...@gmail.com> wrote:

Hi Jaco,

Can confirm issues 1 through 4 are fixed with the latest.

I still get one warning when compiling with QTILITIES_NO_DEBUG commented in and QTILITIES_PROPERTY_BROWSER commented out. 

source\DebugWidget.cpp(397) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

source\DebugWidget.cpp(431) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

source\DebugWidget.cpp(445) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

source\DebugWidget.cpp(459) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

source\DebugWidget.cpp(974) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

source\DebugWidget.cpp(987) : warning C4101: 'explorer_service' : unreferenced l

ocal variable

Fixed, thanks.

 

On the MSVC front: You're impressed with the speed of the built executable? Or MSVC compilation times?

Both actually. I have quite a big project which took around an hour to build with Mingw which went down to about 10min. On top of that I see huge improvements in the built executable (I have some launch timers etc. built in so that I can verify speed improvements between old and new releases).

 

I'm sure GCC/MinGW would pick up those warnings with -Wall (no?), but understand that it also generates a lot of other guff.

To be honest I've not run mingw with -Wall, so it might be there but I can't comment. 

 

Don't ditch the .pro files - if you're automating your build process you won't be able to run lupdate or lrelease unless you have a .pro file (or you can right click it in VS, but that's not so easy to script :) ). If you're using it as your main dev env, would highly recommend Vissual Assist X. If you work out how to get .pro files playing nicely with VisualStudio Filters let me know as we have a VS project structure but no .pro/.pri files. 

I'm staying with .pro files and Qt Creator right now. I've just changed my toolchain to be msvc. Thanks for the tips.

Regards,

Simon

On Friday, January 11, 2013 5:30:24 PM UTC+11, Jaco Naude wrote:

Hi Simon

A quick update with regards to our previous discussions and the emails you've sent this morning. I've set up a MSVC environment on my side in order to reproduce the issues you are seeing.

1) The previous commit which I mentioned with regard to the getenv() function call warning did not do the trick. This is now fixed.

2) With regard to the #include <Qtilities> problem. I've decided to remove the ability to do that since it can lead to nasty issues since that file tries to include all files in Qtilities. This would add a bunch of dependencies on your app even if you just want to use QtilitiesCore. For example, it will try to include QtGui based classes etc. Thus, I'm removing it and you need to manually include the modules which you are interested. This is a better and much more controlled approach.

3) With regard to the dominance problem on TreeNode, this is now fixed. I saw that there are hundreds of those errors when building in MSVC. Apologies for that.

4) In regard with the problems you were seeing with QTILITIES_NO_HELP, this is also fixed.

4) I've been testing Qtilities against the final Qt 5 release and there were numerous issues which were introduced since the betas. Most of there are fixed now, but there are a few last outstanding things that needs to be done before its ready and the v1.2 release will be out.

All changes mentioned above are contained in this commit.

As a final note, I'm really impressed with the speed of MSVC, as well as the number of warnings it picks up that MingW and GCC completely missed. I've done limited testing in the past with it, but decided to move my development environment over to MSVC at last, after thinking about doing it for a long time.

Regards,

Jaco Naude'

Qtilities: Building blocks for Qt applications.

http://www.qtilities.org

--
To post to this group, send email to qtil...@googlegroups.com
To unsubscribe from this group, send email to
qtilities+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/qtilities?hl=en?hl=en

--