Ah; sorry I missed this reply earlier (it got filed to scm), and reiterated a question on the other thread.
Comments inline below. --Mark >> Any reason for >> >> 525 sed "/^domain/d" < $(<F).po > $@ ;\ >> >> instead of >> >> 525 $(SED) "/^domain/d" < $(<F).po > $@ ;\ >> >> in Makefile.master? (Other than that the BUILD.po macro is already >> similarly deficient...) > > I copied it from BUILD.po, and I didn't notice at the time. ;-} > > I'll fix both of them. Thank you. >> Are any of the new .py.po or .pl.po suffix rules exercised during the >> current build? > > .pl.po is exercised by cmd/psrinfo, cmd/projadd, cmd/lgrpinfo, > cmd/kstat, and cmd/abi/appcert/scripts. > > .py.po isn't exercised yet, but it seemed odd to leave it out while > I'm there. It would be nice to get some validation that this works; see below. >> Is it appropriate to use $(XGETTEXT) on them, instead of >> the script rules that already exist (and should really be similarly >> combined) for .sh.po and .ksh.po? > > The previous (several) users of "%.po: %.pl" rules used XGETTEXT. > This makes a bit more sense to me than the hand-crafted sed/sort/awk > rule used for .sh.po and .ksh.po. > > Plus, if we went that way, we'd have to rewrite those rules, because > the way gettext works with Perl/Python is quite a bit different from > the way it works in a shell script. Those languages are much more > lisp-like than are line-oriented shell interpreters. > > But if what you're leaving unsaid is that xgettext is explicitly > documented to work on "C" programs, and Perl isn't C, you do have a > point there. > > Given that I'd have to rewrite those ugly sed hacks to use them, I'm > somewhat inclined to stay with xgettext, and then complain if that > ever stops working with these no-so-shellish languages. My underlying point was twofold: first, that it's documented for C source. Second: that if the source is sufficiently C-like, it will likely work, but if "gettext" is changed to something more like "GetText," or otherwise manipulated, it could fail. So it would be nice to validate that the .py.po suffix rule actually works correctly, as you already have with the .pl.po one. >> Should the comment on line 995 be updated (to stop enumerating the >> suffixes, rather than to augment the enumeration)? > > Yes; it does look out of place now. I'll update that. Thanks. --Mark
