qt4-r2.eclass has the special eqmake4() function which sets some environment variables important to apps using qmake on Gentoo. When an ebuild calls ./configure and the configure script is autogenerated by sys-devel/qconf, the resultant script calls qmake (directly) to compile a Qt program. I suppose that this could be fixed by patching qconf's configure scripts to 1. not clear the environment 2. to call eqmake4 which might give it the definition from qt4-r2.eclass. The Qt program that ./configure builds is then run. This Qt program outputs some *.pro files and, afterwards, calls qmake using something like Qt's version of exec(). Such a call is not easily mappable to eqmake4. However, this call is _unneeded_ and can be removed from the ./configure-generated program with a sed expression. The *.pro files that are generated will be utilized when the src_configure() calls eqmake4(). Thoughts/conclusion: The easiest fix would probably be a qconf4.eclass which automatically attacks the ./configure script so that it calls eqmake4() and so that the program it compiles and runs doesn't try to needlessly execute qmake.
1) I don't think calling an eclass function from a standard shell script (configure in this case) is feasible. 2) There's no need to remove the direct qmake call from the generated configure script. Just call eqmake4 after ./configure is run.
> 2) There's no need to remove the direct qmake call from the generated configure script. Just call eqmake4 after ./configure is run. This does work in most cases. qconf is run to create ./configure. ./configure has a C++ program embedded in it that is written out along with some .pro files to a temporary subdirectory. ./configure attempts to find a runnable copy of qmake or qmake4. ./configure runs what it finds on the .pro files in the temporary subdirectory. At this point, there are a few important things going on. Whatever qmake is called will grab some data from /usr/share/qt4/mkspecs ( bug 304971 ) may or may not ignore any of the variables that are normally overridden by eqmake4(). This would include things that matter when building a 32-bit program in a multilib environment, such as those discussed in bug 304975 . Thus, on portage-multilib, one gets errors while this temporary program is being compiled. These errors are almost certainly caused by the system-installed qmake being called without being wrapped by eqmake4. Maybe upstream qconf people are willing to give more control over how its temporary configuration program is compiled and which arguments are passed to it. It is possible that I'm attacking this problem from the wrong angle, I'm a little confused about it atm ;-).
Why don't you ask upstream to fix qconf?
(In reply to comment #3) > Why don't you ask upstream to fix qconf? Because I'm lazy and I don't use qca or qt? OK, I'll try ;-).
If passing env to qmake is the only requirement then this should be not hard to do. Also please, post link on upstream report here (once filled :) ). running eqmake4 is really not really a solution.
(In reply to comment #5) > If passing env to qmake is the only requirement then this should be not hard to > do. Also please, post link on upstream report here (once filled :) ). http://lists.affinix.com/pipermail/delta-affinix.com/2010-February/001635.html I do prefer to file rather than fill my bugs ;-). The idea about env transfer does sound hopeful. > running > eqmake4 is really not really a solution. OK.
It doesn't look like that conversation brought any solution. Ideally we'd want to see qconf use eqmake4. Maybe someone could look into that and produce a patch. But the workaround currently in place works (i.e. running eqmake4 after running the qconf-generated configure).
Created attachment 247847 [details, diff] qconf-skip-qmake.patch This is patch to skip second qmake run (so we'll have to run eqmake4 after ./configure --skip-qmake). But since actual run of qmake is really cheap I'm not sure do we need something like that? May be just live with workaround in place? BTW: is it possible to pass required variables with spec file in eqmake4? Then it's really easy to update qconf and pass spec file to qmake.
(In reply to comment #8) > Created an attachment (id=247847) [details] > qconf-skip-qmake.patch > > This is patch to skip second qmake run (so we'll have to run eqmake4 after > ./configure --skip-qmake). But since actual run of qmake is really cheap I'm > not sure do we need something like that? May be just live with workaround in > place? Indeed. I don't see any problems with running qmake twice (once by configure itself and once by eqmake4 after configure). > > BTW: is it possible to pass required variables with spec file in eqmake4? Then > it's really easy to update qconf and pass spec file to qmake. > Which variables are you talking about exactly? qmake cache is disabled, but you can already pass "-spec foo" to eqmake4.
(In reply to comment #9) > (In reply to comment #8) > > BTW: is it possible to pass required variables with spec file in eqmake4? > > Then it's really easy to update qconf and pass spec file to qmake. > > Which variables are you talking about exactly? qmake cache is disabled, but > you can already pass "-spec foo" to eqmake4. "${EPREFIX}"/usr/bin/qmake \ -makefile -nocache \ -config ${CONFIG_ADD} \ QTDIR="${EPREFIX}"/usr/$(get_libdir) \ ... and so on... Is it possible to pass all this information with spec file?
Well, you'll need to generate the spec file each time to get correct *FLAGS. I don't see the benefit of doing this.
(In reply to comment #11) > Well, you'll need to generate the spec file each time to get correct *FLAGS. I > don't see the benefit of doing this. This allows an easy way to pass *FLAGS through qconf to qmake. But well, currently I think running qmake twice is the simplest solution here.
Last time I had a look at a qconf-generated configure script, the last (and most important) invocation of qmake was quite simple, without any particular flags. Configuration variables are written to config.pri, which is included by the main .pro file... but I may be remembering wrong.
(In reply to comment #13) > Last time I had a look at a qconf-generated configure script, the last (and > most important) invocation of qmake was quite simple, without any particular > flags. Configuration variables are written to config.pri, which is included by > the main .pro file... but I may be remembering wrong. Well, the first invokation of qmake is used to compile a C++-based ./configure-esque program. If this C++ code were to do any tests to determine ABI or paths to libraries or antything and the results of these tests were written to config.pri, then this first invokation of qmake would matter significantly. With qca's case, I don't think this is happening.... or enough things are being overwritten/sed-ized that the tests which matter are overridden. Thus, use of qconf can be worked around for portage-multilib users with no problems for the moment.
Can anybody knowing about this tell us how to solve this? (or, even better since this is maintainer-needed, directly fix this :P) Thanks!
Only psi depends on this package, so maybe we should just hack around this issue there. Changing the default behaviour of qmake is definitely not a good idea.
CCing psi maintainers then
Pacho but what problem you are trying to solve? Calling qmake twice still workarounds this issue or what do I miss? We can resolve this bug as LATER, but I think it's not worth it. Let's keep this issue open for record or until somebody decides to fix this issue as it should.
(In reply to Peter Volkov from comment #18) > but I think it's not worth it. Let's keep this issue open for record or > until somebody decides to fix this issue as it should. +1
(removing proxy-maint@, no clue why we're here)
