All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH 4/5] bitbake.conf: Handle S and B separately for debug mapping
Date: Mon, 15 Aug 2022 17:56:31 +0100	[thread overview]
Message-ID: <90f10fdbc5d44e771ce2c7e4b7c61a8e453c55e0.camel@linuxfoundation.org> (raw)
In-Reply-To: <ac198bef4bb248cead2a1c2e45b682eb@axis.com>

On Mon, 2022-08-15 at 16:37 +0000, Peter Kjellerstedt wrote:
> > -----Original Message-----
> > From: openembedded-core@lists.openembedded.org <openembedded-
> > core@lists.openembedded.org> On Behalf Of Richard Purdie
> > Sent: den 13 augusti 2022 22:35
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH 4/5] bitbake.conf: Handle S and B separately for
> > debug mapping
> > 
> > We don't really need to keep S and B separate for debug source purposes
> > and there shouldn't be source references in WORKDIR that isn't S and B
> > either.
> > 
> > Separating these out simplifies the shared-work directory handling for
> > gcc and should also help fix external source usage. Therefore handle
> > S and B in DEBUG_PREFIX_MAP separately and clean up other code.
> > 
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> >  meta/conf/bitbake.conf                      | 11 +++++++----
> >  meta/recipes-devtools/gcc/gcc-runtime.inc   | 13 -------------
> >  meta/recipes-devtools/gcc/libgcc-common.inc |  8 --------
> >  3 files changed, 7 insertions(+), 25 deletions(-)
> > 
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index bdfb6784371..dd2df8a5520 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -645,10 +645,13 @@ EXTRA_OEMAKE:prepend:task-install =
> > "${PARALLEL_MAKEINST} "
> >  # Optimization flags.
> >  ##################################################################
> >  # Beware: applied last to first
> > -DEBUG_PREFIX_MAP ?= "-fmacro-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> > -                     -fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> > -                     -fdebug-prefix-map=${STAGING_DIR_HOST}= \
> > -                     -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
> > +DEBUG_PREFIX_MAP ?= "-fmacro-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> > + -fdebug-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> > + -fmacro-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> > + -fdebug-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> > + -fdebug-prefix-map=${STAGING_DIR_HOST}= \
> > + -fmacro-prefix-map=${STAGING_DIR_HOST}= \
> > + -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
> >  "
> 
> That should be:
> 
> DEBUG_PREFIX_MAP ?= " \
>     -fmacro-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
>     -fdebug-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
>     -fmacro-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
>     -fdebug-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
>     -fdebug-prefix-map=${STAGING_DIR_HOST}= \
>     -fmacro-prefix-map=${STAGING_DIR_HOST}= \
>     -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
> "
> 
> to follow common variable indentation.

I should have mentioned this in the commit message but this was
deliberate. It avoids a ton of whitespace in the compiler commandline
which I think overrides the indentation standard give how commonly it
is used.

Cheers,

Richard




  reply	other threads:[~2022-08-15 16:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-13 20:34 [PATCH 1/5] gcc: Resolve relative prefix-map filenames Richard Purdie
2022-08-13 20:34 ` [PATCH 2/5] package: Switch debug source handling to use prefix map Richard Purdie
2022-08-13 20:34 ` [PATCH 3/5] libgcc/gcc-runtime: Improve source reference handling Richard Purdie
2022-08-13 20:35 ` [PATCH 4/5] bitbake.conf: Handle S and B separately for debug mapping Richard Purdie
2022-08-15 16:37   ` [OE-core] " Peter Kjellerstedt
2022-08-15 16:56     ` Richard Purdie [this message]
2022-08-13 20:35 ` [PATCH 5/5] gcc-cross: Fix relative links Richard Purdie

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=90f10fdbc5d44e771ce2c7e4b7c61a8e453c55e0.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter.kjellerstedt@axis.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.