All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] Yocto: qt4: Let qmake control some compiler/linker flags
Date: Fri, 15 Aug 2014 22:53:02 +0200	[thread overview]
Message-ID: <201408152253.02781.marex@denx.de> (raw)
In-Reply-To: <CAP9ODKpCTJTLg2iwP+JmL+X_dyj919gB0k85r2HtKNKy_nhd_w@mail.gmail.com>

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


  reply	other threads:[~2014-08-16  4:38 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 [this message]
2014-08-26  1:33     ` Otavio Salvador
2014-08-26  2:04 ` Khem Raj
2014-08-28 12:52   ` Marek Vasut

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=201408152253.02781.marex@denx.de \
    --to=marex@denx.de \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio@ossystems.com.br \
    /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.