I have a package which indirectly calls qmake (from Qt5). Is there a way to inject the standard build flags using environment variables, or do I have to patch the invocation of the qmake command itself to pass the flags, similar to what %{qmake_qt5} does?
Would it make to add rpmbuild-qmake or something similar to qt5-rpm-macros which get the build flags from CFLAGS/CXX/FLAGS/LDFLAGS and pass it to qmake?
Thanks, Florian
Florian Weimer wrote:
I have a package which indirectly calls qmake (from Qt5). Is there a way to inject the standard build flags using environment variables, or do I have to patch the invocation of the qmake command itself to pass the flags, similar to what %{qmake_qt5} does?
%{qmake_qt5} already does that in general. it will use any existing values for environment variables CFLAGS, CXXFLAGS, LDFLAGS.
In short, set CFLAGS, CXXFLAGS, and/or LDFLAGS prior to calling %{qmake_qt5}
Does that help?
-- Rex
Rex Dieter wrote:
Florian Weimer wrote:
I have a package which indirectly calls qmake (from Qt5). Is there a way to inject the standard build flags using environment variables, or do I have to patch the invocation of the qmake command itself to pass the flags, similar to what %{qmake_qt5} does?
%{qmake_qt5} already does that in general. it will use any existing values for environment variables CFLAGS, CXXFLAGS, LDFLAGS.
In short, set CFLAGS, CXXFLAGS, and/or LDFLAGS prior to calling %{qmake_qt5}
Oh, *indirectly* calls qmake, that may be trickier. Which package?
-- Rex
Rex Dieter wrote:
Rex Dieter wrote:
Florian Weimer wrote:
I have a package which indirectly calls qmake (from Qt5). Is there a way to inject the standard build flags using environment variables, or do I have to patch the invocation of the qmake command itself to pass the flags, similar to what %{qmake_qt5} does?
%{qmake_qt5} already does that in general. it will use any existing values for environment variables CFLAGS, CXXFLAGS, LDFLAGS.
In short, set CFLAGS, CXXFLAGS, and/or LDFLAGS prior to calling %{qmake_qt5}
Oh, *indirectly* calls qmake, that may be trickier. Which package?
I found some qt(4), examples of using a qmake wrapper, but the principle is the same, one is: https://marc.info/?l=fedora-extras-commits&m=145585036023552&w=2
-- Rex
On 01/24/2018 07:18 PM, Rex Dieter wrote:
Rex Dieter wrote:
Rex Dieter wrote:
Florian Weimer wrote:
I have a package which indirectly calls qmake (from Qt5). Is there a way to inject the standard build flags using environment variables, or do I have to patch the invocation of the qmake command itself to pass the flags, similar to what %{qmake_qt5} does?
%{qmake_qt5} already does that in general. it will use any existing values for environment variables CFLAGS, CXXFLAGS, LDFLAGS.
In short, set CFLAGS, CXXFLAGS, and/or LDFLAGS prior to calling %{qmake_qt5}
Oh, *indirectly* calls qmake, that may be trickier. Which package?
pcp: https://bugzilla.redhat.com/show_bug.cgi?id=1538187
I doubt that setting the QMAKE variable works; the required shell quoting would be pretty horrible (three or four levels).
I found some qt(4), examples of using a qmake wrapper, but the principle is the same, one is: https://marc.info/?l=fedora-extras-commits&m=145585036023552&w=2
I don't want to copy this solution in the dozen or so packages which need this (and I probably would have missed QMAKE_STRIP). Surely it would make sense to provide a generic solution?
Thanks, Florian
Florian Weimer wrote:
On 01/24/2018 07:18 PM, Rex Dieter wrote:
Rex Dieter wrote:
Rex Dieter wrote:
Florian Weimer wrote:
I have a package which indirectly calls qmake (from Qt5). Is there a way to inject the standard build flags using environment variables, or do I have to patch the invocation of the qmake command itself to pass the flags, similar to what %{qmake_qt5} does?
%{qmake_qt5} already does that in general. it will use any existing values for environment variables CFLAGS, CXXFLAGS, LDFLAGS.
In short, set CFLAGS, CXXFLAGS, and/or LDFLAGS prior to calling %{qmake_qt5}
Oh, *indirectly* calls qmake, that may be trickier. Which package?
...
I don't want to copy this solution in the dozen or so packages which need this (and I probably would have missed QMAKE_STRIP). Surely it would make sense to provide a generic solution?
If something is needed more broadly, I agree. I'll take a closer look at pcp and see if I can come up with a better generic solution.
-- Rex
Rex Dieter wrote:
Florian Weimer wrote:
Oh, *indirectly* calls qmake, that may be trickier. Which package?
...
I don't want to copy this solution in the dozen or so packages which need this (and I probably would have missed QMAKE_STRIP). Surely it would make sense to provide a generic solution?
If something is needed more broadly, I agree. I'll take a closer look at pcp and see if I can come up with a better generic solution.
This is the best I've come up with so far: * Qt packaging providing a qmake wrapper. first horriblish iteration: https://src.fedoraproject.org/rpms/qt5/c/d9172949ad3ad54908de9ecfd41bf125f8f...
* Adapt packages to use the wrapper. this can take the form of explicitly setting QMAKE (or equivalent), adjusting PATH to prefer the qt5 wrapper dir, or patching, or some combination of the above.
In the specific case of pcp, it supports QMAKE, so it's a one liner, something like this appears to achieve what we want:
diff --git a/pcp.spec b/pcp.spec index 72a7583..71d59a6 100644 --- a/pcp.spec +++ b/pcp.spec @@ -2089,6 +2089,7 @@ updated policy package. rm -Rf $RPM_BUILD_ROOT
%build +export QMAKE=%{qmake_qt5_wrapper} %if !%{disable_python2} && 0%{?default_python} != 3 export PYTHON=python%{?default_python} %endif
How's that sound?
On 01/24/2018 10:05 PM, Rex Dieter wrote:
Rex Dieter wrote:
Florian Weimer wrote:
Oh, *indirectly* calls qmake, that may be trickier. Which package?
...
I don't want to copy this solution in the dozen or so packages which need this (and I probably would have missed QMAKE_STRIP). Surely it would make sense to provide a generic solution?
If something is needed more broadly, I agree. I'll take a closer look at pcp and see if I can come up with a better generic solution.
This is the best I've come up with so far:
- Qt packaging providing a qmake wrapper. first horriblish iteration:
https://src.fedoraproject.org/rpms/qt5/c/d9172949ad3ad54908de9ecfd41bf125f8f...
Thanks for working on this.
I'm not sure if the use of eval is correct. I would have expected something like this instead:
exec $QMAKE $QMAKE_FLAGS "$@"
- Adapt packages to use the wrapper. this can take the form of explicitly
setting QMAKE (or equivalent), adjusting PATH to prefer the qt5 wrapper dir, or patching, or some combination of the above.
In the specific case of pcp, it supports QMAKE, so it's a one liner, something like this appears to achieve what we want:
diff --git a/pcp.spec b/pcp.spec index 72a7583..71d59a6 100644 --- a/pcp.spec +++ b/pcp.spec @@ -2089,6 +2089,7 @@ updated policy package. rm -Rf $RPM_BUILD_ROOT
%build +export QMAKE=%{qmake_qt5_wrapper} %if !%{disable_python2} && 0%{?default_python} != 3 export PYTHON=python%{?default_python} %endif
I doubt that this will work for pcp because it fails building with -z defs and therefore has to use:
%undefine _strict_symbol_defs_build
But the qmake wrapper will not see this directive in the spec file and pass the full set of linker flags. At least that's what I expect, I haven't tried it.
I suspect we need something that captures the contents of CFLAGS etc. which is called from %build in different environment variables, and also sets QMAKE.
Thanks, Florian
Florian Weimer wrote:
On 01/24/2018 10:05 PM, Rex Dieter wrote:
Rex Dieter wrote:
Florian Weimer wrote:
Oh, *indirectly* calls qmake, that may be trickier. Which package?
...
I don't want to copy this solution in the dozen or so packages which need this (and I probably would have missed QMAKE_STRIP). Surely it would make sense to provide a generic solution?
If something is needed more broadly, I agree. I'll take a closer look at pcp and see if I can come up with a better generic solution.
This is the best I've come up with so far:
- Qt packaging providing a qmake wrapper. first horriblish iteration:
https://src.fedoraproject.org/rpms/qt5/c/d9172949ad3ad54908de9ecfd41bf125f8f...
Thanks for working on this.
I'm not sure if the use of eval is correct. I would have expected something like this instead:
exec $QMAKE $QMAKE_FLAGS "$@"
- Adapt packages to use the wrapper. this can take the form of explicitly
setting QMAKE (or equivalent), adjusting PATH to prefer the qt5 wrapper dir, or patching, or some combination of the above.
In the specific case of pcp, it supports QMAKE, so it's a one liner, something like this appears to achieve what we want:
diff --git a/pcp.spec b/pcp.spec index 72a7583..71d59a6 100644 --- a/pcp.spec +++ b/pcp.spec @@ -2089,6 +2089,7 @@ updated policy package. rm -Rf $RPM_BUILD_ROOT
%build +export QMAKE=%{qmake_qt5_wrapper} %if !%{disable_python2} && 0%{?default_python} != 3 export PYTHON=python%{?default_python} %endif
I doubt that this will work for pcp because it fails building with -z defs and therefore has to use:
%undefine _strict_symbol_defs_build
But the qmake wrapper will not see this directive in the spec file and pass the full set of linker flags. At least that's what I expect, I haven't tried it.
I suspect we need something that captures the contents of CFLAGS etc. which is called from %build in different environment variables, and also sets QMAKE.
It should capture all of CFLAGS, CXXFLAGS, LDFLAGS , see https://src.fedoraproject.org/rpms/qt5/blob/master/f/macros.qt5 where it pulls from %{optflags} and %{?__global_ldflags} as appropriate
Unfortunately, setting QMAKE is not a standard thing to rely on (as far as I know). Do you have any docs or evidence to the contrary?
-- Rex
Rex Dieter wrote:
It should capture all of CFLAGS, CXXFLAGS, LDFLAGS , see https://src.fedoraproject.org/rpms/qt5/blob/master/f/macros.qt5 where it pulls from %{optflags} and %{?__global_ldflags} as appropriate
It will capture CFLAGS, CXXFLAGS, LDFLAGS from the environment, but it will not pick up the correct defaults from the specfile if the specfile does not export the environment variables.
You are using rpm --eval %{?_qt5_qmake_flags} from the shell script to get the flags. That spawns a separate instance of RPM, which will not see any defines/globals in the specfile. So %{optflags} and %{?__global_ldflags} will be the global RPM defaults, unaffected by any settings in the specfile. The only way flags from the specfile will be picked up is through the *FLAGS environment variables, because those override the %{optflags} and/or %{?__global_ldflags} in the definition of %{_qt5_qmake_flags}.
Kevin Kofler
Kevin Kofler wrote:
Rex Dieter wrote:
It should capture all of CFLAGS, CXXFLAGS, LDFLAGS , see https://src.fedoraproject.org/rpms/qt5/blob/master/f/macros.qt5 where it pulls from %{optflags} and %{?__global_ldflags} as appropriate
It will capture CFLAGS, CXXFLAGS, LDFLAGS from the environment, but it will not pick up the correct defaults from the specfile if the specfile does not export the environment variables.
You are using rpm --eval %{?_qt5_qmake_flags} from the shell script to get the flags. That spawns a separate instance of RPM, which will not see any defines/globals in the specfile. So %{optflags} and %{?__global_ldflags} will be the global RPM defaults, unaffected by any settings in the specfile. The only way flags from the specfile will be picked up is through the *FLAGS environment variables, because those override the %{optflags} and/or %{?__global_ldflags} in the definition of %{_qt5_qmake_flags}.
caveats accepted. (requiring use of exported *FLAGS environment vars)
Better ideas or implementations welcome (I have none at the moment)
-- Rex
On 01/24/2018 11:18 PM, Rex Dieter wrote:
It should capture all of CFLAGS, CXXFLAGS, LDFLAGS , see https://src.fedoraproject.org/rpms/qt5/blob/master/f/macros.qt5 where it pulls from %{optflags} and %{?__global_ldflags} as appropriate
Ahh—it's conditional whether CFLAGS etc. have been set. If they are, those variables are used, and not the built-in RPM defaults. So this part works.
I'm still concerned about the eval. I think it will cause unintended shell evaluation of the remaining part of qmake arguments, e.g.:
$ eval echo '$(foo)' bash: foo: command not found
There has to be a better way to do this.
But otherwise, this approach looks as good as it can be. Could you document it in a .md file within the package? Then I can link to it from:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflag...
Thanks, Florian
Florian Weimer wrote:
- Adapt packages to use the wrapper. this can take the form of explicitly
setting QMAKE (or equivalent), adjusting PATH to prefer the qt5 wrapper dir, or patching, or some combination of the above.
In the specific case of pcp, it supports QMAKE, so it's a one liner, something like this appears to achieve what we want:
diff --git a/pcp.spec b/pcp.spec index 72a7583..71d59a6 100644 --- a/pcp.spec +++ b/pcp.spec @@ -2089,6 +2089,7 @@ updated policy package. rm -Rf $RPM_BUILD_ROOT
%build +export QMAKE=%{qmake_qt5_wrapper} %if !%{disable_python2} && 0%{?default_python} != 3 export PYTHON=python%{?default_python} %endif
I doubt that this will work for pcp because it fails building with -z defs and therefore has to use:
%undefine _strict_symbol_defs_build
Adding my export + your undefine yielded a successful scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=24422357
proof of concept appears to be a success.
-- Rex
-
Florian Weimer -
Kevin Kofler -
Rex Dieter