Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 305905 - dev-build/qconf generates configure scripts that call qmake directly
Summary: dev-build/qconf generates configure scripts that call qmake directly
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it
URL:
Whiteboard:
Keywords: NeedPatch
Depends on:
Blocks: portage-multilib
  Show dependency tree
 
Reported: 2010-02-19 17:06 UTC by Nathan Phillip Brink (binki) (RETIRED)
Modified: 2024-01-17 17:16 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
qconf-skip-qmake.patch (qconf-skip-qmake.patch,1.37 KB, patch)
2010-09-18 13:07 UTC, Peter Volkov (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-02-19 17:06:43 UTC
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.
Comment 1 Davide Pesavento gentoo-dev 2010-02-20 20:24:31 UTC
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.
Comment 2 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-02-21 01:05:33 UTC
> 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 ;-).
Comment 3 Davide Pesavento gentoo-dev 2010-02-25 17:30:44 UTC
Why don't you ask upstream to fix qconf?
Comment 4 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-02-26 05:12:35 UTC
(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 ;-).
Comment 5 Peter Volkov (RETIRED) gentoo-dev 2010-03-01 10:38:54 UTC
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.
Comment 6 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-03-01 17:27:34 UTC
(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.
Comment 7 Ben de Groot (RETIRED) gentoo-dev 2010-03-26 18:27:27 UTC
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).
Comment 8 Peter Volkov (RETIRED) gentoo-dev 2010-09-18 13:07:08 UTC
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.
Comment 9 Davide Pesavento gentoo-dev 2010-09-18 14:24:43 UTC
(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.
Comment 10 Peter Volkov (RETIRED) gentoo-dev 2010-09-18 15:22:30 UTC
(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?
Comment 11 Davide Pesavento gentoo-dev 2010-09-18 17:37:32 UTC
Well, you'll need to generate the spec file each time to get correct *FLAGS. I don't see the benefit of doing this.
Comment 12 Peter Volkov (RETIRED) gentoo-dev 2010-09-19 07:17:25 UTC
(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.
Comment 13 Davide Pesavento gentoo-dev 2010-09-19 09:37:26 UTC
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.
Comment 14 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-09-19 23:43:26 UTC
(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.
Comment 15 Pacho Ramos gentoo-dev 2013-06-21 09:51:09 UTC
Can anybody knowing about this tell us how to solve this? (or, even better since this is maintainer-needed, directly fix this :P)

Thanks!
Comment 16 Michael Palimaka (kensington) gentoo-dev 2013-06-21 13:44:30 UTC
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.
Comment 17 Pacho Ramos gentoo-dev 2013-06-21 15:58:23 UTC
CCing psi maintainers then
Comment 18 Peter Volkov (RETIRED) gentoo-dev 2013-07-25 07:32:32 UTC
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.
Comment 19 Davide Pesavento gentoo-dev 2013-07-25 07:50:42 UTC
(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
Comment 20 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-02-07 17:52:14 UTC
(removing proxy-maint@, no clue why we're here)