Qt5 QWidget project dependencies? OpenGL? Direct3D? WTH?
-
[quote author="Lukas Geyer" date="1359571502"]Looks like you don't link against gdi32.lib for some reason. Do you build from a VisualStudio command line?[/quote]
I use the Windows SDK command line. I didn't notice any link errors relating to that lib.
-
All those unresolved symbols (__imp__StartPage@4, __imp__StartDocW@8, ...) are part of gdi32.lib which doesn't seem to be linked for some reason.
I've never seen this problem occouring before.
I would suggest a fresh build from a Windows SDK command line; it this doesn't work please file "bug report":https://bugreports.qt-project.org/.
-
[quote author="Lukas Geyer" date="1359574684"]All those unresolved symbols (__imp__StartPage@4, __imp__StartDocW@8, ...) are part of gdi32.lib which doesn't seem to be linked for some reason.
I've never seen this problem occouring before.
I would suggest a fresh build from a Windows SDK command line; it this doesn't work please file "bug report":https://bugreports.qt-project.org/.[/quote]
I DID a fresh build from source on the Win SDK command line. I followed EVERYTHING in the notes. For what it's worth, I did file the issue as a bug linked "here":https://bugreports.qt-project.org/browse/QTBUG-29360
-
If you do not see the relevance...go and find an oculist.
Is there any serious design advantage or technical reason to impose unused and HUGE runtime dependency (25,9 MB!!!!!) unless you recompile your version of the whole Qt Framework?!?
This is a pain in the ass, no way to not admit it.I only hope is not a slow strategy to make, in the time, the LGPL alternative less attractive than the commercial one...I think I'm wrong in that, but when I read answer like yours to a more than licit objection really some doubt raise.
-
If you do not see the relevance...go and find an oculist.
Is there any serious design advantage or technical reason to impose unused and HUGE runtime dependency (25,9 MB!!!!!) unless you recompile your version of the whole Qt Framework?!?
This is a pain in the ass, no way to not admit it.I only hope is not a slow strategy to make, in the time, the LGPL alternative less attractive than the commercial one...I think I'm wrong in that, but when I read answer like yours to a more than licit objection really some doubt raise.
[quote author="Lukas Geyer" date="1357136305"]I didn't mean to infantilize you.
I just don't see the relevance of your request in practice. This does neither mean that your requests are "...groundless..." that make you an "...clueless idiot..." and me the incarnation of ..."greatness and concern...", nor that I'm right and you are wrong - it just means that I have a different opinion on the question you've asked and the points you've raised, and that I do not find your arguments suitable enough to convince me of the contrary. That's the nature of discussions, and no reason to get into a huff.
Granted, the granularity of modularization can be argued over, most probably for all eternity. But I don't see the current one beeing disputable relating to dependencies, because there is still the option to not depend on stuff I do not want or need to, for example OpenGL or DirectX. Officially released shared libraries will always compel you to distribute stuff your application does not depend on, be it other shared libraries or data and code in existing libraries you do not use, because they are made to support any application, not a specific one.
It is indeed your right to think that I'm wrong and to demand changes if you think that a wrong decision has been made, by either filing a bug report or participating in development - of course at the risk that others don't find your arguments suitable enough as well. Not every decision you find "...stupid..." has to be actually stupid.
And I again invite you to join the Qt Development Mailing List and the Qt Open Governance Code Review to find out how and why decisions are made in the Qt Project.[/quote]
-
[quote author="nomegenerico" date="1367248622"]Is there any serious design advantage or technical reason to impose unused and HUGE runtime dependency (25,9 MB!!!!!) unless you recompile your version of the whole Qt Framework?!?[/quote]
WebKit (commercial and open source) requires ICU, Windows as in WebGL, WinRT and (Intel) OpenGL (commercial and open source) requires DirectX and ANGLE; feel free to forward your request to WebKit.org, Microsoft and Intel.You'll also find a sympathetic ear at "bugreports.qt-projects.org":https://bugreports.qt-project.org/ (to be honest, I'm not so confident for the others).
Alternatively use a Qt which does not depend on ICU or ANGLE, either downloaded or built on your own, which is work equivalent to a coffee break.
It is licit for you to find this an unreasonable burden; it is licit for me and the oculist to find it isn't.
-
bq. Alternatively use a Qt which does not depend on ICU or ANGLE, either downloaded or built on your own, which is work equivalent to a coffee break.
Considering on a fast modern machine building Qt takes at least 2 hours and much more for a humble system, where is that amazing workplace with 2+ hours coffee breaks? And that is provided the build doesn't fail like it often does.
-
Downloading the sources, opening a command prompt and typing in <code>configure -skip webkit -no-icu -opengl desktop && jom</code> requires less than 2 minutes.
As the resulting binaries are (source code) compatible feel free to continue developing while Qt is building, be it 30 minutes, 2 hours or a weekend. This is a deployment question, not a development question.
And I hope you don't mind I don't jump your fail so often train, because it is completely contrary to the perception of someone building Qt on Tier 1 platforms on a regular basis.
-
[quote author="Lukas Geyer" date="1367267319"]
WebKit (commercial and open source) requires ICU, Windows as in WebGL, WinRT and (Intel) OpenGL (commercial and open source) requires DirectX and ANGLE; feel free to forward your request to WebKit.org, Microsoft and Intel.
You'll also find a sympathetic ear at "bugreports.qt-projects.org":https://bugreports.qt-project.org/ (to be honest, I'm not so confident for the others).
Alternatively use a Qt which does not depend on ICU or ANGLE, either downloaded or built on your own, which is work equivalent to a coffee break.
It is licit for you to find this an unreasonable burden; it is licit for me and the oculist to find it isn't.
[/quote]So the dependency should appear only when a project include webkit, such as:
CONFIG += webkit
If not, why not make always and all dependent from whatever plugins or library?? Come on!!
And what to say about large project that can possibly mix application that needs webkit and other that do not...we need to configure a different Qt toolkit for each to obtiani executable that require the right runtime. This is fun for how much is silly.
The "sympathetic ear" is almost deaf just like you blind eyes.
An otolaryngologist is needed too!!
:-DDDDD
Bye bye.
-
[quote author="Lukas Geyer" date="1367295179"]Downloading the sources, opening a command prompt and typing in <code>configure -skip webkit -no-icu -opengl desktop && jom</code> requires less than 2 minutes.
As the resulting binaries are (source code) compatible feel free to continue developing while Qt is building, be it 30 minutes, 2 hours or a weekend. This is a deployment question, not a development question.
And I hope you don't mind I don't jump your fail so often train, because it is completely contrary to the perception of someone building Qt on Tier 1 platforms on a regular basis.[/quote]Qt is a cross platform framework: most people have more than one platform to target in the same project.
An on a single platform you can have more than one compiler (example: mingw and msvc on windows).If it is not enough for you to see some little "drawback", as long as I know, is not straightforward the way you tell us to compile Qt from sources and any different platform and compiler have it's own pitfalls.
And you have to re-do all this for each minor release you would like to upgrade to!!!!
An oculist??
-
[quote author="Lukas Geyer" date="1367295179"]Downloading the sources, opening a command prompt and typing in <code>configure -skip webkit -no-icu -opengl desktop && jom</code> requires less than 2 minutes.
As the resulting binaries are (source code) compatible feel free to continue developing while Qt is building, be it 30 minutes, 2 hours or a weekend. This is a deployment question, not a development question.
And I hope you don't mind I don't jump your fail so often train, because it is completely contrary to the perception of someone building Qt on Tier 1 platforms on a regular basis.[/quote]
I've had Qt fail to build a few times in a row, ending up costing me far more than a few hours until I get a complete and working build. And considering I do nothing but configure the build, its failure can hardly be due to me doing something wrong. Building and deploying Qt is sadly far from as effortless as you and some other people present it. I've built pretty much every minor Qt release the last couple of years, and yes, there were releases that built effortlessly the first time, but there were also those who failed over and over again until I pinpoint the faulty modules and disable them. It would appear people at what is now digia don't do anywhere close to the necessary amount of testing on different software and hardware platforms, probably because testing is focused on what you refer to as "tier 1" platforms, whatever that might be...
-
[quote author="nomegenerico" date="1367302724"]So the dependency should appear only when a project include webkit, such as:
CONFIG += webkit
If not, why not make always and all dependent from whatever plugins or library?? Come on!!
And what to say about large project that can possibly mix application that needs webkit and other that do not...we need to configure a different Qt toolkit for each to obtiani executable that require the right runtime. This is fun for how much is silly.[/quote]Which dependencies are you having issues with? On Windows, the only DLLs near the 20MB mark are WebKit and ICU. WebKit is not required by all Qt programs -- if you don't use it in your program, you don't need to include the DLL. The Qt developers are working to shrink ICU now (http://lists.qt-project.org/pipermail/releasing/2013-March/001124.html )
[quote author="utcenter" date="1367318492"]I've had Qt fail to build a few times in a row, ending up costing me far more than a few hours until I get a complete and working build. And considering I do nothing but configure the build, its failure can hardly be due to me doing something wrong. Building and deploying Qt is sadly far from as effortless as you and some other people present it. I've built pretty much every minor Qt release the last couple of years, and yes, there were releases that built effortlessly the first time, but there were also those who failed over and over again until I pinpoint the faulty modules and disable them. It would appear people at what is now digia don't do anywhere close to the necessary amount of testing on different software and hardware platforms, probably because testing is focused on what you refer to as "tier 1" platforms, whatever that might be...[/quote]Do you build from git or from released source code packages? If you use git, calling 'git submodule update' prior to 'configure' should give you a stable(r) set of modules. If you use packaged source code, it probably needs to be reported.
If you're interested, here's a "definition":http://qt-project.org/groups/qt-contributors-summit-2011/wiki/Qt5ProductDefinition#4582cf86974b397c8f3a2ed2fd502f8c and a "list":http://permalink.gmane.org/gmane.comp.lib.qt.devel/7805 of Reference and Tier 1 platforms in the Qt Project, as of November 2012.
-
@JKSH - mostly from git. Gonna try calling ‘git submodule update’ next time and see if it helps.
-
[quote author="JKSH" date="1367322846"]Which dependencies are you having issues with? On Windows, the only DLLs near the 20MB mark are WebKit and ICU. WebKit is not required by all Qt programs -- if you don't use it in your program, you don't need to include the DLL. The Qt developers are working to shrink ICU now (http://lists.qt-project.org/pipermail/releasing/2013-March/001124.html ) [/quote]
The problem is more heavy for the biggest ICU dll (one in particular) but the point is that you should not have dependency for unused feature AT ALL.
Sadly, dependencies from the dynamic libraries mentioned at the top of this discussion are present for a simple "hello world" widget (c++ and Qt only) project, in other worlds are always present.This is the sitation, at this tiome, unless you recompile the whole framework: an absurd idea, if you mind the fact that this should be done on envery platform, with every compilers you use and every time you want to switch to a new Qt release and last but not list, that rebuild Qt is a "I know when I'll start but I do not know when I'll be finisched".
Thank you for your answer, nice to know that there is an attempt to make ICU smaller, but is not a solution...but is better than nothing. ;-)
-
The big problem is that dependencies are not on a per-project level, but on per-framework level. I am really surprised this issue has not been addressed yet, and what is worse, there is no outlook of that happening anytime soon. It is certainly doable, but I guess no one wants to bother, commercial users can avoid such problems by linking statically. For the rest, custom builds are pretty much mandatory in order to get within the reasonable.
-
[quote author="nomegenerico" date="1367303870"]Qt is a cross platform framework: most people have more than one platform to target in the same project.
An on a single platform you can have more than one compiler (example: mingw and msvc on windows). If it is not enough for you to see some little “drawback”, as long as I know, is not straightforward the way you tell us to compile Qt from sources and any different platform and compiler have it’s own pitfalls.[/quote]This is a pure Windows issue, with a trivial fix, requiring work equivalent to a coffee break all three to six months at the release of a minor Qt version, is completely source code and binary compatible and guaranteed to work on all Tier 1 platforms using the officially released (non-git) source packages; rather than beeing ignored it is actively beeing worked on and most probably solved for the next minor Qt release.This doesn't cause such agitation for me; if it does for you feel free to go on.
-
[quote author="utcenter" date="1367350805"]The big problem is that dependencies are not on a per-project level, but on per-framework level. I am really surprised this issue has not been addressed yet, and what is worse, there is no outlook of that happening anytime soon.[/quote]It is a known and discussed issue and it is actively beeing worked on.
Not all trivial problems have trivial solutions.
[quote author="utcenter" date="1367350805"]It is certainly doable, but I guess no one wants to bother, commercial users can avoid such problems by linking statically. For the rest, custom builds are pretty much mandatory in order to get within the reasonable.[/quote]icudt.dll contains data, not code. Feel free to compile a subset of this data into the shared library to reduce its size, the same way a commercial customer will compile a subset of this data into a static library to reduce its size.
-
To be honest you should already have the option to use the "ICU data library customizer":http://apps.icu-project.org/datacustom/ to create a stripped down version of the ICU data library specific to your needs and distribute it with a stock Qt so you do not have to build Qt on your own (your mileage may vary).
-
It generates a .dat file. How to convert it to a dll file?
-
I too don't see how OpenGL being a Qt compile option, instead of supporting projects of both types in Qt4 without a compile, is progress. Yes, OpenGL does widgets faster, but unless you have a lot, saving ~ 2 1/2 MB on an install is of significance. It looks like core will go away. For some reason, I thought I needed WebKit and about five others when I didn't; so that reply back there helped me a lot. I do see Lukas' point that complaining here is not nearly as effective as posting a bug/feature report.