Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Andreas Oberritter <obi@opendreambox.org>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: Peter Urbanec <openembedded-devel@urbanec.net>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] gstreamer1.0: Shorten __FILE__ in gst_debug_log output on all platforms.
Date: Thu, 26 Feb 2015 23:27:13 +0100	[thread overview]
Message-ID: <54EF9DC1.20403@opendreambox.org> (raw)
In-Reply-To: <CAP9ODKpyYwZ1bAzfo9U0gcagLHyYdfbDEYOcLcD52UKH2WKbZg@mail.gmail.com>

On 26.02.2015 23:11, Otavio Salvador wrote:
> On Thu, Feb 26, 2015 at 6:56 PM, Andreas Oberritter
> <obi@opendreambox.org> wrote:
>> On 26.02.2015 22:47, Richard Purdie wrote:
>>> On Fri, 2015-02-27 at 04:31 +1100, Peter Urbanec wrote:
>>>> On WIN32 the file argument to gst_debug_log_valist is shortened to just
>>>> the filename. This is useful not only for MSVC, but also with gcc/Linux
>>>> when doing cross-compilation builds and out-of-tree builds.
>>>
>>> Ultimately I think we need to address this issue in gcc itself, probably
>>> setting some kind of base path in the environment which it removes from
>>> __FILE__ (set to ${S}). There were more complex discussions about using
>>> the same mapping code as can be used with the debug symbols code too.
>>
>> FWIW, here's a patch I'm using with gcc 4.8, which just cuts off the
>> whole directory part.
>>
>> http://git.openembedded.org/openembedded-core-contrib/commit/?h=obi/master&id=a1e8d6cfb71367d745f2478c13a7250e41ca4f1b
> 
> Ideally it could drop the S from the string. So the internal path
> would be respected.
> 
> What do you think?

I thought about that before, but preferred not to do it for the sake of
simplicity. Usually __FILE__ is used for debug output, so it's printed
together with a more or less unique debug message. I guess it should be
easy to find the right location inside the source tree in almost every
case, even if some filenames might appear more than once in a project.

Note that generated source files may live in ${B}, which is not below
${S}. You could cut off ${WORKDIR} instead, though.

Regards,
Andreas


  reply	other threads:[~2015-02-26 22:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-26 17:31 [PATCH] gstreamer1.0: Shorten __FILE__ in gst_debug_log output on all platforms Peter Urbanec
2015-02-26 21:47 ` Richard Purdie
2015-02-26 21:56   ` Andreas Oberritter
2015-02-26 22:11     ` Otavio Salvador
2015-02-26 22:27       ` Andreas Oberritter [this message]
2015-02-26 22:00   ` Otavio Salvador
2015-02-26 22:37     ` Randy Witt
2015-02-26 22:40       ` Otavio Salvador
2015-02-27  3:28     ` Peter Urbanec

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=54EF9DC1.20403@opendreambox.org \
    --to=obi@opendreambox.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=openembedded-devel@urbanec.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox