eqmake4() appends either "CONFIG += debug" or "CONFIG += release" to every project file it processes, depending on the 'debug' USE flag. This is usually fine, excepts when the project file itself changes the build behaviour depending on the value of CONFIG (which is usually set at the beginning of the project file). The problem arises because the value in the middle of the file will be equal to the value upstream set at the beginning; while at the end of the parsing the value will be the one set by eqmake4: the two values could possibly be different of course. The following test case demonstrates what I'm explaining... $ cat foo.pro CONFIG = release CONFIG(release):message(Release mode) CONFIG(debug):message(Debug mode) $ qmake foo.pro Project MESSAGE: Release mode $ grep "mkspecs/features" Makefile /usr/share/qt4/mkspecs/features/qt_functions.prf \ /usr/share/qt4/mkspecs/features/qt_config.prf \ /usr/share/qt4/mkspecs/features/exclusive_builds.prf \ /usr/share/qt4/mkspecs/features/default_pre.prf \ /usr/share/qt4/mkspecs/features/release.prf \ <======== OK /usr/share/qt4/mkspecs/features/default_post.prf \ /usr/share/qt4/mkspecs/features/qt_functions.prf \ /usr/share/qt4/mkspecs/features/qt_config.prf \ /usr/share/qt4/mkspecs/features/exclusive_builds.prf \ /usr/share/qt4/mkspecs/features/default_pre.prf \ /usr/share/qt4/mkspecs/features/release.prf \ <======== OK /usr/share/qt4/mkspecs/features/default_post.prf /usr/share/qt4/mkspecs/features/qt_functions.prf: /usr/share/qt4/mkspecs/features/qt_config.prf: /usr/share/qt4/mkspecs/features/exclusive_builds.prf: /usr/share/qt4/mkspecs/features/default_pre.prf: /usr/share/qt4/mkspecs/features/release.prf: <======== OK /usr/share/qt4/mkspecs/features/default_post.prf: *BUT* $ [imagine to call eqmake4() on foo.pro with USE="debug"] $ cat foo.pro CONFIG = release CONFIG(release):message(Release mode) CONFIG(debug):message(Debug mode) CONFIG -= release CONFIG += no_fixpath debug $ qmake foo.pro Project MESSAGE: Release mode <===== this means that in the middle of foo.pro CONFIG is equal to 'release' (WRONG!) $ grep "mkspecs/features" Makefile /usr/share/qt4/mkspecs/features/qt_functions.prf \ /usr/share/qt4/mkspecs/features/qt_config.prf \ /usr/share/qt4/mkspecs/features/exclusive_builds.prf \ /usr/share/qt4/mkspecs/features/default_pre.prf \ /usr/share/qt4/mkspecs/features/debug.prf \ <===== INCONSISTENT /usr/share/qt4/mkspecs/features/default_post.prf \ /usr/share/qt4/mkspecs/features/qt_functions.prf \ /usr/share/qt4/mkspecs/features/qt_config.prf \ /usr/share/qt4/mkspecs/features/exclusive_builds.prf \ /usr/share/qt4/mkspecs/features/default_pre.prf \ /usr/share/qt4/mkspecs/features/debug.prf \ <===== INCONSISTENT /usr/share/qt4/mkspecs/features/default_post.prf /usr/share/qt4/mkspecs/features/qt_functions.prf: /usr/share/qt4/mkspecs/features/qt_config.prf: /usr/share/qt4/mkspecs/features/exclusive_builds.prf: /usr/share/qt4/mkspecs/features/default_pre.prf: /usr/share/qt4/mkspecs/features/debug.prf: <======== INCONSISTENT /usr/share/qt4/mkspecs/features/default_post.prf: I'm going to attach a patch shortly.
Created attachment 170042 [details, diff] eqmake4.patch This patch fixes the issue explained above and it also contains several other improvements over the current implementation. It should also fix bug #221745.
Created attachment 186500 [details, diff] eqmake4.patch Updated patch, rebased on top of latest version of qt4.eclass in Portage. Drop the sed that removes stripping from the generated Makefile, since the issue has already been fixed in bug #221745 with a better patch.
Well I think now it 's time to touch this bug. Since your patch is quite big and modifies critical stuff I would like to have a futher conversation with you about this. So feel free to open a discussion on qt@gentoo.org about this. Its quite complicated (especially the awk part) so I would like to fully understand the functionality. If you are not so fond about the e-mail thinkie , you can always ask me or Ben ( yngwin ) on irc ( freenode servers ). We usually reside on #gentoo-kde. Thanks
This patch was applied on qt4-edge eclass on qting-edge overlay for further testing Thanks Davide
Blocking bugs fail with current eqmake4 ( portage version ) but works with the overlays' one. I am just adding them here in order to be aware of those situations
Davide do you have any further additions ? The new eqmake4 seems to work smoothly on qt4-edge eclass So if you are done with the changes, I ll wait one more week and then I ll commit the new eqmake4 Ben is that ok? :)
(In reply to comment #6) > Davide do you have any further additions ? > The new eqmake4 seems to work smoothly on qt4-edge eclass > > So if you are done with the changes, I ll wait one more week and then I ll > commit the new eqmake4 > As far as eqmake4 is concerned, I should be done :) We may want to expand the documentation a bit, to clarify that it's usually enough to run eqmake4 on the top-level project file even for recursive build systems... I'll attach a patch shortly. I think bug #265770 should be fixed before committing the new eclass too, just to avoid scaring users with spurious warnings.
Created attachment 189572 [details, diff] doc improvements and minor style fixes
Just to make things clear, do you intend to commit only the new eqmake4 implementation or the whole qt4-edge eclass?
(In reply to comment #9) > Just to make things clear, do you intend to commit only the new eqmake4 > implementation or the whole qt4-edge eclass? > No, just the eqmake4 function :). qt4-edge eclass is quite new ( hense experimental ) so it needs more and more testing especially now with all the LANGS/LANGSLONG/DOCS etc magics :) So for now, eqmake4 is the top priority for qt4(-edge) eclass :) ps: Thanks for all the fixes on qt4-edge eclass :) ps#2: your modifications applied on qt4-edge eclass
Commited. :) Thanks Davide for your hard work
