Mark J. Nelson writes: > > 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. > 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. > 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. > 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. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
