public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos_odonell@mentor.com>
To: Roland McGrath <roland@hack.frob.com>
Cc: libc-alpha <libc-alpha@sourceware.org>, <libc-ports@sourceware.org>
Subject: Re: [PATCH] Changes to libc.pot for glibc core and ports.
Date: Fri, 15 Jun 2012 17:11:00 -0000	[thread overview]
Message-ID: <4FDB6CBE.10303@mentor.com> (raw)
In-Reply-To: <20120615165633.112D92C079@topped-with-meat.com>

On 6/15/2012 12:56 PM, Roland McGrath wrote:
> That is technically not really kosher since nothing says the add-on has to
> be under that name.  But since list-sources.sh is effectively only for
> maintainer use I suppose it's OK.  But since it will be moot as soon as
> we do the repo consolidation, maybe you should just do it by hand and not
> fiddle the script.

That's a good point, I'd just assumed that *everyone* symlinks it into the
tree as `ports', and that's all I've seen. You are right though that as a
maintainer you're expected to follow some documented practice and I've
added the assumption under "Regeneration" in the wiki.

How about something more robust like?

diff --git a/scripts/list-sources.sh b/scripts/list-sources.sh
index 53b6f7f..a7d7e34 100755
--- a/scripts/list-sources.sh
+++ b/scripts/list-sources.sh
@@ -11,8 +11,15 @@ esac

 if [ -r .git/HEAD ]; then

-  exec ${GIT:-git} ls-files
-
+  # List files for glibc core.
+  ${GIT:-git} ls-files
+  # List files for glibc ports.
+  ports="ports"
+  if [ -d "$PWD/$ports" ]; then
+    cd "$PWD/$ports"
+    ${GIT:-git} ls-files | sed -e "s,^,$ports/,g"
+  fi
+  exit 0
 fi

 echo >&2 'Cannot list sources without some version control system in use.'
---

I really hate doing this by hand and leaving no reproducible trace of
evidence showing anyone how this was done before.

Heaven forbid we don't get the merge done, but say it doesn't happen,
then I'd be happier with it just working (tm).

Joseph, as always, raised a great point on IRC, that ports shouldn't
really be contributing any translatable messages. Translations belong
at a higher level and in glibc core. Regardless of this point I don't
want to loose a translation, and the latter is a QoI issue that
should be independent of our global support for translations.

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026

  reply	other threads:[~2012-06-15 17:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15 14:27 Carlos O'Donell
2012-06-15 16:56 ` Roland McGrath
2012-06-15 17:11   ` Carlos O'Donell [this message]
2012-06-15 17:27     ` Roland McGrath
2012-06-21 15:04       ` Carlos O'Donell
     [not found]   ` <4FDB6CBE.10303__17202.5123647929$1339780358$gmane$org@mentor.com>
2012-06-15 17:36     ` Andreas Schwab

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=4FDB6CBE.10303@mentor.com \
    --to=carlos_odonell@mentor.com \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-ports@sourceware.org \
    --cc=roland@hack.frob.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).