Mark J. Nelson writes:
>
> Darn. I was hoping there was nothing underneath that particular rock.
> Thanks for turning it over.
Nah; thanks for keeping me honest. It was pretty lame to toss that in
without validating it.
--
James Carlson, Solaris Networking
Sun Microsystems / 35
Mark J. Nelson writes:
> > 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
gt; Subject: Re: [scm-migration-dev] several messages
>
> Mark J. Nelson writes:
>>> 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 the
Mark J. Nelson writes:
>
> Any reason for
>
> 525sed "/^domain/d" < $( $@ ;\
>
> instead of
>
> 525$(SED) "/^domain/d" < $( $@ ;\
>
> in Makefile.master? (Other than that the BUILD.po macro is already
> similarly deficient...)
I copied it from BUILD.po, and I did
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
>>
>> 525sed "/^domain/d" < $( $@ ;\
>>
>> instead of
>>
>> 525$(SED) "/^domain/d" < $( $@ ;\
>>
>> in Makefile.
Any reason for
525sed "/^domain/d" < $( $@ ;\
instead of
525$(SED) "/^domain/d" < $( $@ ;\
in Makefile.master? (Other than that the BUILD.po macro is already
similarly deficient...)
Are any of the new .py.po or .pl.po suffix rules exercised during the
curre
