This is proposition of new function for qt eclasses. Almost all ebuild of qt apps are using qmake. Maybe it would be better to provide more generic use of it? Basicly what eqmake does is runing qmake on specified .pro file (or standard ${PN}.pro one if no argument was added to eqmake). It also: - specyfing which qmake should be used (as solution for some qt3/4 problems) - parse CXFLAGS, CXXFLAGS - parse CONFIG+="no_fixpath" as solution for common problems with non standard portage temp dir - check is debug is used and parse CONFIG+="debug" if so Attached files are patch for original qt3.eclass and full new qt3.eclass. As my english isn't perfect I'm pretty sure, there are some spelling mistakes. If anybody wants to correct them - fill free. This would be very usefull for many ebuilds (i.e. some patches that adds no_fixpath to CONFIG, wouldn't be necessary anymore). Regards, Przemek
Created attachment 77957 [details, diff] qt3.eclass.patch
Created attachment 77958 [details] qt3.eclass full qt3.eclass file
After some reading I think same function with same parameters (but different qmake version) could be used for qt4 apps. I need to find qt4 app to check this... Regards, Przemek
I'm looking at this and so far I like it. Let me think about it a few more days.
Created attachment 78305 [details] qt3.eclass small improvement when not using USE="debug" parse CONFIG+="release", so that debug wont be build if user don't want it
Created attachment 78306 [details, diff] qt3.eclass.patch
Created attachment 78307 [details] qt4.eclass tested with scythia-0.7 and cdfly-0.1 (both are qt4 apps) - works as expected only change to qt3.eclass is to used different qmake version
Created attachment 78308 [details, diff] qt4.eclass.patch
s/is to used/is to use/ I bolieve there are other spelling mistakes... sorry. Regards, Przemek
Created attachment 97893 [details] qt3.eclass I read more curfully manuals and here: http://doc.trolltech.com/3.3/qmake-manual-8.html can be found information, that if CONFIG = debug is in projects pro file (what isn't anything new :) ), than project will always be build as debug (even when we add CONFIG += release when running qmake; reading qt4 manual : http://doc.trolltech.com/4.1/qmake-variable-reference.html#config leads to the same conclusion). Solution for this is quite simple - always add CONFIG -= debug when running wmake (what is a proper usage of -= operator, according to http://doc.trolltech.com/3.3/qmake-manual-6.html and same for qt4 can be easily find). Anyway. As for qt3 debug build wasn't a real problem, it will be in qt4, where qt libraries have extra suffix _debug. Regards, Przemek
Created attachment 97894 [details, diff] qt3.eclass.patch
Created attachment 97895 [details] qt4.eclass
Created attachment 97896 [details, diff] qt4.eclass.patch
Created attachment 97903 [details] qt4.eclass wrong version - sorry. change in this version: if USE="debug" is being used, eqmake checks if qt4 was build against debug USE flag as well - if not, than it can be build only as release. Regards, Przemek
Created attachment 97904 [details, diff] qt4.eclass.patch
After some more tests I can say: debug disabling is done wrong way. :/ With method like in eclass - debug is disabled for compilation, but not for ebuild enviroment. This means that package can be compiled with USE="debug", having it disabled. emerge -vp some_pkg will show that pkg was compiled like expected. Better solution would be to disable debug in some pre_ function. AFAIR there was some way to do this in ebuild. I have to read some more docs :/ Regards, Przemek
You may want to take a look at qt 4.2 which does debug and release a bit differently than previous versions. I say this because I hate for you to spend a lot of time fixing something that is changing in 4.2
(In reply to comment #17) > You may want to take a look at qt 4.2 which does debug and release a bit > differently than previous versions. I say this because I hate for you to spend > a lot of time fixing something that is changing in 4.2 Caleb - I checked the qmake documentation from 4.2 (Release Candidate 1) documentation and I'm not sure what was on your mind, because I don't seee anything is changing... Could you tell me what do I have to read more curfully? And after some studies and test with qmake I can say that there's a really nasty bug in it. If in .pro there's a line with CONFIG += debug, running qmake from hand with "CONFIG -= debug" "CONFIG += release" will not work (to say more : it will not produce Makefile for release version, but still for debug one). However there is quite simple workaround for this. Just before running qmake, you would have to do something like: echo -e "CONFIG -= debug\nCONFIG += release" >> myprofile.pro and now after running qmake, Makefile looks as expected - only for release version. And as for installing app with debug USE flag, I see a clean solution to determine in qt4_pkg_setup function is debug in USE. If so - was qt4 build with debug? And if not - simply call die withy information about missing qt build with debug USE flag. (similar solution was made for php ebuilds, with checks various combination of USE flags and will not let install this package, with wrong / unsupported set of them). Few things in gentoo are still uknown for me (I'm checking them), but maybe it is a good solution? Caleb? can you tell me should I read and work more or just to dump the hall idea? Best reagrds, Przemek
Created attachment 97986 [details] qt4.eclass Next try: - exported function qt4_src_setup inside eclass, to check is debug USE flag is set and have qt was build with this flag. That way user want install a package with debug, to time, he/she can't do this. - simple workaround for qmake, who is not handling CONFIG +/-= right way - CFLAGS and CXXFLAGS also for debug compilation Caleb: I have checked available on doc.trolltech.com documenation for qt-4.2_rc1 and to be true... I haven't foung anything really different. If there is something specific I should read - plz send me link. Regards, Przemek
Created attachment 97987 [details, diff] qt4.eclass.patch
I think debug/release is the same for 4.2, but I remember seeing something different about it for 4.2 in the way it build the libraries. In this case, you may not be affected.
(In reply to comment #21) > I think debug/release is the same for 4.2, but I remember seeing something > different about it for 4.2 in the way it build the libraries. In this case, > you may not be affected. Can I use 4.2_rc1 as a reference? Cause if so, than in filelist (on my friends machine) from `equery files qt` output there is: <cut> /usr/lib64/qt4/libQt3Support.so.4.2.0.debug /usr/lib64/qt4/libQtAssistantClient.so.4.2.0.debug /usr/lib64/qt4/libQtCore.so.4.2.0.debug /usr/lib64/qt4/libQtDesigner.so.4.2.0.debug /usr/lib64/qt4/libQtDesignerComponents.so.4.2.0.debug /usr/lib64/qt4/libQtGui.so.4.2.0.debug /usr/lib64/qt4/libQtNetwork.so.4.2.0.debug /usr/lib64/qt4/libQtOpenGL.so.4.2.0.debug /usr/lib64/qt4/libQtSql.so.4.2.0.debug /usr/lib64/qt4/libQtSvg.so.4.2.0.debug /usr/lib64/qt4/libQtTest.so.4.2.0.debug /usr/lib64/qt4/libQtXml.so.4.2.0.debug <cut> As I see it, only difference is in libraries names - it's not _debug, but .debug . Anyway - just my 2 cents. Regards, Przemek
Right. I was under the impression too that now if you build a qmake project in debug mode, it doesn't link against the .debug libraries directory. All projects link against the normal library, and it's up to you to tell it to use debug at runtime. Might want to check that out. Dunno if I'm right on that or not.
Well, the fixes here are wrong. You cannot name the function the same in both eclasses, that kills the whole point of the wrapper function in the first place and will produce a random behaviour based on the order in which the eclasses will get inherited. Should be called eqmake3 and eqmake4 or something like that instead.
Created attachment 125739 [details] qt4.eclass A hopefully improved version of qt4.eclass: - Brought up to date with portage version; - Renamed eqmake to eqmake4 as jakub suggested; - Added LDFLAGS support; - Use toolchain-funcs to get the right compiler and pass it to qmake; - Respect qmake return value in eend.
Created attachment 125740 [details, diff] qt4.eclass.patch
Created attachment 126353 [details] qt4.eclass Further improved version. - Added support for logging qmake messages to ${T}/qmake-$$.out in a way similar to autotools.eclass; - Now each parameter to eqmake4 except the first (which is the name of the .pro file that should be processed by qmake) is appended unmodified to qmake command line; - Other misc changes of minor importance.
Created attachment 126356 [details, diff] qt4.eclass.patch
Created attachment 126357 [details] qt3.eclass Improved version with the changes already implemented for qt4.eclass (see above).
Created attachment 126358 [details, diff] qt3.eclass.patch
Please could someone commit these eclasses to portage? I think they are extremely useful and simplify a lot the process of writing ebuilds for packages that use Qt. In particular eqmake{3,4} ensures that C(XX)FLAGS, LDFLAGS and the correct compiler and linker are used when invoking qmake. Furthermore this bug is blocking bug #168964: having separate eqmake3 and eqmake4 function call will definitely solve that problem.
Okay, I've committed this to portage save for one item: In the qt4.eclass, the section of: if use debug && ! built_with_use =x11-libs/qt-4* debug; then I don't think is necessary with the latest versions of Qt4. You should be able to build a debug version of your app even if the non-debug version of Qt is installed (at least, it works that way on my system). Can someone confirm if this section is still truly needed or not? Otherwise, it should all be in the eclasses now save for any goof-ups I might have made.
Thanks Caleb! Now we should just add a bit of "documentation" to eqmake to explain its usage (see next two patches). Probably we can also get rid of the line PATH="${QTDIR}/bin:${PATH}" and just pass QTDIR=${QTDIR} to qmake, because we already make sure that we are calling qt3's qmake by using the full path to the executable. This should also solve bug #168964.
Created attachment 126616 [details, diff] Explain eqmake3 usage + remove PATH=... line
Created attachment 126617 [details, diff] Explain eqmake4 usage
(In reply to comment #34 and comment #35) Please use format parsable and usable by app-portage/eclass-manpages. See e. g. http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/eutils.eclass?r1=1.282&r2=1.283
(In reply to comment #36) > (In reply to comment #34 and comment #35) > > Please use format parsable and usable by app-portage/eclass-manpages. Here you are. Please review as I'm not so good at english ;)
Created attachment 126656 [details, diff] Documentation for qt3.eclass
Created attachment 126657 [details, diff] Documentation for qt4.eclass
Created attachment 126693 [details, diff] Documentation for qt3.eclass
Created attachment 126695 [details, diff] Documentation for qt4.eclass
(In reply to comment #40 and comment #41) They look good for me.
Caleb: you may merge the documentation patches if you think they are fine. After that I think this bug can be closed as FIXED. Thank you.
will try and get these merged soon. Is it okay to put your names (Davide,Przemyslaw,etc) in the docs as well, so you get credit for your work?
(In reply to comment #44) > will try and get these merged soon. Is it okay to put your names > (Davide,Przemyslaw,etc) in the docs as well, so you get credit for your work? > Yes, of course. I have no problem. I don't know if a "@AUTHOR:" meta-directive exists for eclasses documentation, and I don't think "@MAINTAINER:" is appropriate in this case, so I left my name out. It would be cool however to add something like "@AUTHOR:" to each function (if the author of that function is different from the eclass maintainer)... well, do what you can. Thank you very much.
I just read that "The [[ ]] form is generally safer than [ ] and should be used in all new code." (http://devmanual.gentoo.org/tools-reference/bash/index.html) So please patch eqmake[34] changing all instances of [[ with [ . Also, please remove the useless lines: IUSE="${IUSE}" from both qt3 and qt4 eclasses. Thanks again.
Of course I meant "changing all instances of [ with [[" .
(In reply to comment #45) > It would be cool however to add something like "@AUTHOR:" to each function > (if the author of that function is different from the eclass maintainer) Functions can have individual @MAINTAINERs. See eutils.eclass.
Created attachment 127769 [details, diff] qt3.eclass.patch Here you are. Everything (documentation and misc cleanups) in one patch, should apply cleanly against current porttree version of qt3.eclass.
Created attachment 127771 [details, diff] qt4.eclass.patch The same for qt4.eclass...
(In reply to comment #49) PATH="${QTDIR}/bin:${PATH}" probably shouldn't be deleted now. (In reply to comment #49 and comment #50) Eclasses and ebuilds are encoded in UTF-8, so "Przemyslaw Maciag" could be replaced with "Przemysław Maciąg".
(In reply to comment #51) > (In reply to comment #49) > > PATH="${QTDIR}/bin:${PATH}" probably shouldn't be deleted now. > Could you explain why please?
(In reply to comment #52) > (In reply to comment #51) > > (In reply to comment #49) > > > > PATH="${QTDIR}/bin:${PATH}" probably shouldn't be deleted now. > > > > Could you explain why please? Qt 3 installs binaries to "/usr/qt/3/bin", Qt 4 installs binaries to "/usr/bin". Some ebuilds using Qt 3 may need to use Qt 3's binaries instead of Qt 4's binaries. If they inherit qt3.eclass, PATH="${QTDIR}/bin:${PATH}" causes that Qt 3's binaries are preferred. I'm not saying only about commands written directly in ebuilds. It's possible that e. g. a custom configure script (not generated by Autotools) uses e. g. qmake. For safety, PATH="${QTDIR}/bin:${PATH}" should stay in qt3.eclass.
Created attachment 127984 [details, diff] qt3.eclass.patch Yes, you're right. This is the fixed patch. P.S.: following your reasons, bug #168964 should be closed as WONTFIX/CANTFIX, but messing with $PATH in qt3 eclass breaks packages that inherit both from qt3 and qt4 eclasses (as noted in comment #8 of that bug). Any better solution?
(In reply to comment #54) > P.S.: following your reasons, bug #168964 should be closed as WONTFIX/CANTFIX, > but messing with $PATH in qt3 eclass breaks packages that inherit both from qt3 > and qt4 eclasses (as noted in comment #8 of that bug). Any better solution? Bug #168964 shouldn't be closed until all packages are fixed to use eqmake3/eqmake4 instead of invoking qmake directly. At that point, there'll be no reason to mess with the PATH any more and this should be removed from qt3.eclass.
(In reply to comment #55) > (In reply to comment #54) > > P.S.: following your reasons, bug #168964 should be closed as WONTFIX/CANTFIX, > > but messing with $PATH in qt3 eclass breaks packages that inherit both from qt3 > > and qt4 eclasses (as noted in comment #8 of that bug). Any better solution? > > Bug #168964 shouldn't be closed until all packages are fixed to use > eqmake3/eqmake4 instead of invoking qmake directly. At that point, there'll be > no reason to mess with the PATH any more and this should be removed from > qt3.eclass. > I've already filed a couple of bugs, attaching modified ebuilds that use eqmake. Would you mind adding those bugs (#187545, #187555 and last attachment of #131528) to the list of bugs this one depends on? I'll try to fix some more packages in the next days...
(In reply to comment #56) > Would you mind adding those bugs (#187545, #187555) to the list of bugs this > one depends on? You can add those two bugs yourself. Those bugs should block this bug. ("A depends on B" == "B blocks A") You need to commit these changes in those bugs, not in this bug.
Created attachment 128811 [details, diff] qt4.eclass.patch Fixed a typo. This fix is rather important, nothing critical, but it would be better if caleb could committ this patch asap. Thanks.
Created attachment 135202 [details, diff] qt4.eclass.patch Updated patch. @caleb: please merge it and we can close this bug finally. :-)
A patch which includes mine and the patch from troll in bug #201772 has been committed. I think we're done here. Przemyslaw, I think you can close this bug. ;-)
