[PATCH] Yocto: qt4: Let qmake control some compiler/linker flags

[PATCH] Yocto: qt4: Let qmake control some compiler/linker flags

[Marek Vasut]

In the case of building an Qt application outside of the Yocto
build system, we want to make sure that a "debug" configuration
of the application does contain debug symbols and is has the
compiler optimalization unset. On the other hand, we want to
have a "release" build which does not contain the debug symbols
and has the compiler optimalization turned on.

The OE_QMAKE_* flags serve to pass all kinds of flags into the
qmake-generated Makefile. Currently, we set OE_QMAKE_CFLAGS to
be ${CFLAGS} and ditto for CXXFLAGS and LDFLAGS in the SDK
toolchain environment script. This poses a problem, since the
CFLAGS can contain optimization options (-O*) and even flags to
produce debugging info (-g). The LDFLAGS may also contain some
harmful flags.

The easy way out is to let qmake's army of configuration files
handle the proper configuration of CFLAGS, CXXFLAGS and LDFLAGS
for the generated Makefile and don't interfere with qmake's
decisions by adding arbitrary flags. This patch completely
scrubs OE_QMAKE_C{,XX}FLAGS and leaves only harmless flags in
OE_QMAKE_LDFLAGS. With this patch, the behavior is as it is
explained in the first paragraph.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Eric Bénard <eric@eukrea.com>
---
 meta/recipes-qt/meta/meta-toolchain-qt.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-qt/meta/meta-toolchain-qt.inc b/meta/recipes-qt/meta/meta-toolchain-qt.inc
index c9bdeae..6b162bd 100644
--- a/meta/recipes-qt/meta/meta-toolchain-qt.inc
+++ b/meta/recipes-qt/meta/meta-toolchain-qt.inc
@@ -7,9 +7,9 @@ require recipes-core/meta/meta-toolchain.bb
 QT_TOOLS_PREFIX = "${SDKPATHNATIVE}${bindir_nativesdk}"
 
 toolchain_create_sdk_env_script_append() {
-    echo 'export OE_QMAKE_CFLAGS="$CFLAGS"' >> $script
-    echo 'export OE_QMAKE_CXXFLAGS="$CXXFLAGS"' >> $script
-    echo 'export OE_QMAKE_LDFLAGS="$LDFLAGS"' >> $script
+    echo 'export OE_QMAKE_CFLAGS=""' >> $script
+    echo 'export OE_QMAKE_CXXFLAGS=""' >> $script
+    echo 'export OE_QMAKE_LDFLAGS="${TARGET_LINK_HASH_STYLE}"' >> $script
     echo 'export OE_QMAKE_CC=$CC' >> $script
     echo 'export OE_QMAKE_CXX=$CXX' >> $script
     echo 'export OE_QMAKE_LINK=$CXX' >> $script
-- 
2.0.1

Re: [PATCH] Yocto: qt4: Let qmake control some compiler/linker flags

[Otavio Salvador]

Hello Marek,

On Thu, Aug 7, 2014 at 12:25 PM, Marek Vasut <marex@denx.de> wrote:
> In the case of building an Qt application outside of the Yocto
> build system, we want to make sure that a "debug" configuration
> of the application does contain debug symbols and is has the
> compiler optimalization unset. On the other hand, we want to
> have a "release" build which does not contain the debug symbols
> and has the compiler optimalization turned on.
>
> The OE_QMAKE_* flags serve to pass all kinds of flags into the
> qmake-generated Makefile. Currently, we set OE_QMAKE_CFLAGS to
> be ${CFLAGS} and ditto for CXXFLAGS and LDFLAGS in the SDK
> toolchain environment script. This poses a problem, since the
> CFLAGS can contain optimization options (-O*) and even flags to
> produce debugging info (-g). The LDFLAGS may also contain some
> harmful flags.
>
> The easy way out is to let qmake's army of configuration files
> handle the proper configuration of CFLAGS, CXXFLAGS and LDFLAGS
> for the generated Makefile and don't interfere with qmake's
> decisions by adding arbitrary flags. This patch completely
> scrubs OE_QMAKE_C{,XX}FLAGS and leaves only harmless flags in
> OE_QMAKE_LDFLAGS. With this patch, the behavior is as it is
> explained in the first paragraph.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Eric Bénard <eric@eukrea.com>

I understand your problem however I don't think the solution you found
is optimal. It does fix the issue you refer in the commit log however
it also makes difficult for user to "reuse" default SDK flags to test
the application.

Please also when preparing commit logs please follow the guidelines[1].

1. http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

All your patches need to be adapted to follow those guidelines on the
commit messages. Please prepare a v2 for them.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] Yocto: qt4: Let qmake control some compiler/linker flags

[Marek Vasut]

On Monday, August 11, 2014 at 02:49:16 AM, Otavio Salvador wrote:
> Hello Marek,
> 
> On Thu, Aug 7, 2014 at 12:25 PM, Marek Vasut <marex@denx.de> wrote:
> > In the case of building an Qt application outside of the Yocto
> > build system, we want to make sure that a "debug" configuration
> > of the application does contain debug symbols and is has the
> > compiler optimalization unset. On the other hand, we want to
> > have a "release" build which does not contain the debug symbols
> > and has the compiler optimalization turned on.
> > 
> > The OE_QMAKE_* flags serve to pass all kinds of flags into the
> > qmake-generated Makefile. Currently, we set OE_QMAKE_CFLAGS to
> > be ${CFLAGS} and ditto for CXXFLAGS and LDFLAGS in the SDK
> > toolchain environment script. This poses a problem, since the
> > CFLAGS can contain optimization options (-O*) and even flags to
> > produce debugging info (-g). The LDFLAGS may also contain some
> > harmful flags.
> > 
> > The easy way out is to let qmake's army of configuration files
> > handle the proper configuration of CFLAGS, CXXFLAGS and LDFLAGS
> > for the generated Makefile and don't interfere with qmake's
> > decisions by adding arbitrary flags. This patch completely
> > scrubs OE_QMAKE_C{,XX}FLAGS and leaves only harmless flags in
> > OE_QMAKE_LDFLAGS. With this patch, the behavior is as it is
> > explained in the first paragraph.
> > 
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Eric Bénard <eric@eukrea.com>
> 
> I understand your problem however I don't think the solution you found
> is optimal. It does fix the issue you refer in the commit log however
> it also makes difficult for user to "reuse" default SDK flags to test
> the application.

What solution do you propose then?

The default SDK flags effectively disallow qmake to operate correctly -- that 
is, to control the compiler/linker flags.

[...]

Best regards,
Marek Vasut

Re: [PATCH] Yocto: qt4: Let qmake control some compiler/linker flags

[Otavio Salvador]

On Fri, Aug 15, 2014 at 5:53 PM, Marek Vasut <marex@denx.de> wrote:
> On Monday, August 11, 2014 at 02:49:16 AM, Otavio Salvador wrote:
>> Hello Marek,
>>
>> On Thu, Aug 7, 2014 at 12:25 PM, Marek Vasut <marex@denx.de> wrote:
>> > In the case of building an Qt application outside of the Yocto
>> > build system, we want to make sure that a "debug" configuration
>> > of the application does contain debug symbols and is has the
>> > compiler optimalization unset. On the other hand, we want to
>> > have a "release" build which does not contain the debug symbols
>> > and has the compiler optimalization turned on.
>> >
>> > The OE_QMAKE_* flags serve to pass all kinds of flags into the
>> > qmake-generated Makefile. Currently, we set OE_QMAKE_CFLAGS to
>> > be ${CFLAGS} and ditto for CXXFLAGS and LDFLAGS in the SDK
>> > toolchain environment script. This poses a problem, since the
>> > CFLAGS can contain optimization options (-O*) and even flags to
>> > produce debugging info (-g). The LDFLAGS may also contain some
>> > harmful flags.
>> >
>> > The easy way out is to let qmake's army of configuration files
>> > handle the proper configuration of CFLAGS, CXXFLAGS and LDFLAGS
>> > for the generated Makefile and don't interfere with qmake's
>> > decisions by adding arbitrary flags. This patch completely
>> > scrubs OE_QMAKE_C{,XX}FLAGS and leaves only harmless flags in
>> > OE_QMAKE_LDFLAGS. With this patch, the behavior is as it is
>> > explained in the first paragraph.
>> >
>> > Signed-off-by: Marek Vasut <marex@denx.de>
>> > Cc: Eric Bénard <eric@eukrea.com>
>>
>> I understand your problem however I don't think the solution you found
>> is optimal. It does fix the issue you refer in the commit log however
>> it also makes difficult for user to "reuse" default SDK flags to test
>> the application.
>
> What solution do you propose then?
>
> The default SDK flags effectively disallow qmake to operate correctly -- that
> is, to control the compiler/linker flags.

I understand your issue and I agree we need to address this somehow,
however we should not regret the usability we had before.

This remain unnoticed for such long time means people didn't notice
the lack of this so we need to find a way to support the debugging
without losing the use of SDK configured flags to release builds.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] Yocto: qt4: Let qmake control some compiler/linker flags

[Khem Raj]

On 14-08-07 17:25:57, Marek Vasut wrote:
> In the case of building an Qt application outside of the Yocto
> build system, we want to make sure that a "debug" configuration
> of the application does contain debug symbols and is has the
> compiler optimalization unset. On the other hand, we want to
> have a "release" build which does not contain the debug symbols
> and has the compiler optimalization turned on.
> 
> The OE_QMAKE_* flags serve to pass all kinds of flags into the
> qmake-generated Makefile. Currently, we set OE_QMAKE_CFLAGS to
> be ${CFLAGS} and ditto for CXXFLAGS and LDFLAGS in the SDK
> toolchain environment script. This poses a problem, since the
> CFLAGS can contain optimization options (-O*) and even flags to
> produce debugging info (-g). The LDFLAGS may also contain some
> harmful flags.
> 
> The easy way out is to let qmake's army of configuration files
> handle the proper configuration of CFLAGS, CXXFLAGS and LDFLAGS
> for the generated Makefile and don't interfere with qmake's
> decisions by adding arbitrary flags. This patch completely
> scrubs OE_QMAKE_C{,XX}FLAGS and leaves only harmless flags in
> OE_QMAKE_LDFLAGS. With this patch, the behavior is as it is
> explained in the first paragraph.

This is fine if you see it from QT app developer POV, however I see a
downside, where we are then not compiling the application with the same
consistent set of flags which you would use with OE-mill when you
integrate the app back into OE build system. This reminds me of the
scenario where apps built with MSVS ended up shipping debug builds
because that was what developers tested on and there wasnt enough time
to fix release builds.

Having said that, I would prefer that you add -g flag to whatever you
are getting from SDK and debug using that ( which will be -g -O2)
in most cases optimized code debugging works well with modern gcc if it
does not we can always complain to gcc community.

IMHO its better to debug the code that you will ship. It saves a lot of
time as various steps of code life cycle.

-Khem

Re: [PATCH] Yocto: qt4: Let qmake control some compiler/linker flags

[Marek Vasut]

On Tuesday, August 26, 2014 at 04:04:30 AM, Khem Raj wrote:
> On 14-08-07 17:25:57, Marek Vasut wrote:
> > In the case of building an Qt application outside of the Yocto
> > build system, we want to make sure that a "debug" configuration
> > of the application does contain debug symbols and is has the
> > compiler optimalization unset. On the other hand, we want to
> > have a "release" build which does not contain the debug symbols
> > and has the compiler optimalization turned on.
> > 
> > The OE_QMAKE_* flags serve to pass all kinds of flags into the
> > qmake-generated Makefile. Currently, we set OE_QMAKE_CFLAGS to
> > be ${CFLAGS} and ditto for CXXFLAGS and LDFLAGS in the SDK
> > toolchain environment script. This poses a problem, since the
> > CFLAGS can contain optimization options (-O*) and even flags to
> > produce debugging info (-g). The LDFLAGS may also contain some
> > harmful flags.
> > 
> > The easy way out is to let qmake's army of configuration files
> > handle the proper configuration of CFLAGS, CXXFLAGS and LDFLAGS
> > for the generated Makefile and don't interfere with qmake's
> > decisions by adding arbitrary flags. This patch completely
> > scrubs OE_QMAKE_C{,XX}FLAGS and leaves only harmless flags in
> > OE_QMAKE_LDFLAGS. With this patch, the behavior is as it is
> > explained in the first paragraph.
> 
> This is fine if you see it from QT app developer POV, however I see a
> downside, where we are then not compiling the application with the same
> consistent set of flags which you would use with OE-mill when you
> integrate the app back into OE build system.

This is fine, I want to build Qt application with the RELEASE build flags.

> This reminds me of the
> scenario where apps built with MSVS ended up shipping debug builds
> because that was what developers tested on and there wasnt enough time
> to fix release builds.

This is a different scenario -- I know what I want to achieve, but the SDK 
toolchain is broken and interferes with qmake's operation.

> Having said that, I would prefer that you add -g flag to whatever you
> are getting from SDK and debug using that ( which will be -g -O2)

I do not want to debug the code. I want to produce a RELEASE build, which means 
without debug symbols. If I want to debug, I want the code to be build with -g -
O0 to avoid optimization. Again, the SDK toolchain butts in and forces -O2 into 
the flags, which makes even the DEBUG build corrupted.

> in most cases optimized code debugging works well with modern gcc if it
> does not we can always complain to gcc community.

This is a toolchain problem, which disrupts the correct operation of qmake . And 
this worked until Yocto 1.3 too.

> IMHO its better to debug the code that you will ship. It saves a lot of
> time as various steps of code life cycle.

I think it would be better to fix the toolchain .

Best regards,
Marek Vasut