This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Changes to libc.pot for glibc core and ports.
- From: Carlos O'Donell <carlos_odonell at mentor dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>, <libc-ports at sourceware dot org>
- Date: Fri, 15 Jun 2012 13:11:26 -0400
- Subject: Re: [PATCH] Changes to libc.pot for glibc core and ports.
- References: <4FDB4635.7060306@mentor.com> <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