You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-users@xalan.apache.org by Ashley Zinyk <az...@ca.ibm.com> on 2008/02/13 01:37:53 UTC
MsgCreator incompatible with ICU 3.8
Hi,
David Bertoni <db...@apache.org> wrote on 02/01/2008 12:37:36 PM:
> In newer versions of the ICU, the _entire_ path becomes the name of the
> resource. You can see that if you take a look at the messages shared
> library using a hex editor.
>
> I think we need to modify the build process so we no longer use the full
> relative path in XalanMessages_1_10_en_US.lst, although I'm not sure of
> that. At any rate, it needs some investigation, but I just don't have
time
> to do it right now.
>
> If you really need to get this fixed, I suggest you read the ICU user
guide
> to see if there's more information about naming resources.
I took your advice and I have it working on all my platforms now, although
there were some stumbling blocks along the way. The first thing I tried
was to just generate all the resources in my local directory (
c/src/xalanc/Utils instead of c/nls/icu), but when I did that, it
complained that xalanMsg_en_US.res depends on the missing resource
xalanMsg_en.res.
If you look at this documentation (
http://icu-project.org/userguide/ResourceManagement.html), it says that ICU
tries to find the most specific available locale, like en_US, and then
proceeds to try more general locales if it fails. In this case, if it
can't find American English, it would try general English (en) and
eventually the "root" locale. Given that, it seems completely sensible to
me that the build system would complain that we don't provide it with the
general English or root .res files. I wasn't able to figure out why it
complained when I tried to build in c/src/xalanc/Utils (which I think is
proper behavior), but mysteriously succeeded when I built in c/nls/icu. If
anyone can understand why this might be path-sensitive, please let me know.
To fix these problems, I altered MsgCreator.cpp so that, in addition to
accepting locales of the form <language>_<country> and <language>, it now
also accepts the locale "root". Then, I changed
c/src/xalanc/Utils/Makefile.in so that it would build root.res from
XalanMsg_en_US.xlf (I thought US English would be an adequate default,
considering it's the only message catalog I had, and considering that we
didn't have any default before).
I also removed the leading "xalanMsg_", since
http://source.icu-project.org/repos/icu/icu/tags/release-3-6/readme.html#News
seems to forbid it. Again, I'm not sure how my builds managed to succeed
without that change.
If these changes sound reasonable, I can put a patch with my changes on
JIRA for review.
Ashley Zinyk
XSLT Development
Re: MsgCreator incompatible with ICU 3.8
Posted by David Bertoni <db...@apache.org>.
Ashley Zinyk wrote:
> Hi,
>
> David Bertoni <db...@apache.org> wrote on 02/01/2008 12:37:36 PM:
>> In newer versions of the ICU, the _entire_ path becomes the name of the
>> resource. You can see that if you take a look at the messages shared
>> library using a hex editor.
>>
>> I think we need to modify the build process so we no longer use the full
>> relative path in XalanMessages_1_10_en_US.lst, although I'm not sure of
>> that. At any rate, it needs some investigation, but I just don't have
> time
>> to do it right now.
>>
>> If you really need to get this fixed, I suggest you read the ICU user
> guide
>> to see if there's more information about naming resources.
>
> I took your advice and I have it working on all my platforms now, although
> there were some stumbling blocks along the way. The first thing I tried
> was to just generate all the resources in my local directory (
> c/src/xalanc/Utils instead of c/nls/icu), but when I did that, it
> complained that xalanMsg_en_US.res depends on the missing resource
> xalanMsg_en.res.
Yes, the dependencies probably use a full path, rather than just assuming
the current directory.
>
> If you look at this documentation (
> http://icu-project.org/userguide/ResourceManagement.html), it says that ICU
> tries to find the most specific available locale, like en_US, and then
> proceeds to try more general locales if it fails. In this case, if it
> can't find American English, it would try general English (en) and
> eventually the "root" locale. Given that, it seems completely sensible to
> me that the build system would complain that we don't provide it with the
> general English or root .res files. I wasn't able to figure out why it
> complained when I tried to build in c/src/xalanc/Utils (which I think is
> proper behavior), but mysteriously succeeded when I built in c/nls/icu. If
> anyone can understand why this might be path-sensitive, please let me know.
I'm not sure I understand why we have to provide a root locale since we
supply the locale explicitly when we load the messages. It's not a problem
if we _do_ provide the root locale, but we don't want it to be the reason
why things are working now.
>
> To fix these problems, I altered MsgCreator.cpp so that, in addition to
> accepting locales of the form <language>_<country> and <language>, it now
> also accepts the locale "root". Then, I changed
> c/src/xalanc/Utils/Makefile.in so that it would build root.res from
> XalanMsg_en_US.xlf (I thought US English would be an adequate default,
> considering it's the only message catalog I had, and considering that we
> didn't have any default before).
As I said, this shouldn't be necessary. I think there's still something
wrong with the way we're building the .res file, because we shouldn't have
to fall back to US English messages, even though it's fine if they are the
root once we get things working again.
>
> I also removed the leading "xalanMsg_", since
> http://source.icu-project.org/repos/icu/icu/tags/release-3-6/readme.html#News
> seems to forbid it. Again, I'm not sure how my builds managed to succeed
> without that change.
OK, so that explains it. I believe the ICU is interpreting the relative
path we put in res-file-list.txt as the path to the resources within the
ICU messages bundle. I think we need to figure out a way to put just a
file name in that file, and not a path. That might be as simple as
tweaking src/xalanc/Utils/Makefile.in:
$ svn diff Makefile.in
Index: Makefile.in
===================================================================
--- Makefile.in (revision 619123)
+++ Makefile.in (working copy)
@@ -100,7 +100,7 @@
$(MESSAGELIB) : $(XSL_NLS_DIR)/icu/$(LOCALE).txt
$(GENRB) -p $(LOC_PROJECT_NAME) -d $(XSL_NLS_DIR)/icu -i
$(XSL_NLS_DIR)/icu $(XSL_NLS_DIR)/icu/$(LOCALE).txt
- echo $(XSL_NLS_DIR)/icu/$(LOC_PROJECT_NAME)_$(LOCALE).res >
$(XSL_NLS_DIR)/icu/res-file-list.txt
+ echo $(LOC_PROJECT_NAME)_$(LOCALE).res >
$(XSL_NLS_DIR)/icu/res-file-list.txt
$(PKGDATA) --name $(LOC_PROJECT_NAME) -T $(XSL_NLS_DIR)/icu -v -O
$(ICUROOT)/lib/icu/Makefile.inc --mode dll -d $(XSL_LIB_DIR)
$(XSL_NLS_DIR)/icu/res-file-list.txt -M "prefix=$(ICUROOT) TARGET=$(LOC_LIB)"
$(LN) -fs $(LOC_LIB) $(XSL_LIB_DIR)/$(LOC_LIBNAME)$(SHLIBSUFFIX)
ifeq ($(PLATFORM), AIX)
Dave