From: Marek Vasut <marex@denx.de>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] Yocto: qt4: Let qmake control some compiler/linker flags
Date: Thu, 28 Aug 2014 14:52:59 +0200 [thread overview]
Message-ID: <201408281452.59494.marex@denx.de> (raw)
In-Reply-To: <20140826020430.GB18989@haswell>
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
prev parent reply other threads:[~2014-08-28 14:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-07 15:25 [PATCH] Yocto: qt4: Let qmake control some compiler/linker flags Marek Vasut
2014-08-11 0:49 ` Otavio Salvador
2014-08-15 20:53 ` Marek Vasut
2014-08-26 1:33 ` Otavio Salvador
2014-08-26 2:04 ` Khem Raj
2014-08-28 12:52 ` Marek Vasut [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201408281452.59494.marex@denx.de \
--to=marex@denx.de \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.