Ashley Zinyk wrote:
Hi,
David Bertoni <[EMAIL PROTECTED]> 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
