On Apr 11, 2004, at 4:52 PM, Jonathan Worthington wrote:
On Apr 9, 2004, at 3:26 PM, Jonathan Worthington wrote:Here's the next step. Now we actually get through the build process,
I'm having a crack at getting the ICU changes building on Win32.
Great--thanks!
building ICU along the way and linking the .lib files into the final Parrot
executable.
Awesome!
Unfortunately, nmake test shows that I've screwed something up...
--
Failed Test Status Wstat Total Fail Failed List of Failed
----------------------------------------------------------------------- -----
t\op\integer.t 1 256 39 1 2.56% 4
t\op\number.t 32 8192 38 32 84.21% 1-24, 27, 29, 31,
34-38
--
I don't have time to dig into this right now, but if anyone can spot an
obvious pattern in these failures or point me at what I did wrong, that'd be
great. One thing that does stand out to me is that icudata.lib is only 2
KB, and another is that I didn't get an icuuc.lib, but rather an icuucd.lib.
I'm guessing that as it linked properly it contains the appropriate symbols,
though.
Yep, the pattern I think I see is that tests which involve floats (except for 0.0) are failing, which is what would happen if ICU can't find it's data. (Because, it either ends up thinking that nothing is a digit character, or that they all have digit value zero.) I'll have to add a quick test inside string_init to detect this case, so that we can blow up instead of misbehaving.
As for your libraries, I'm not sure about the naming of icuucd.lib, but it's probably okay--ICU has a bunch of different options for naming libraries, and it's possible that the "d" is for "dynamic", or something. (As long as they are being found at runtime, it's probably okay.) The icudata.lib is tiny because it's just a stub--the data can be built into that lib, but my config parameters have it building a separate archive (".dat") file (in part because it builds much faster, but also because that let you add/remove encodings and locales without a rebuild).**
See if you have a ".dat" file (or a bunch of individual files) in blib/lib/icu/2.6.1 (relative to your parrot source root). If not, then that's what's going on. Right now, I have that path hard-coded--of course I need to pull that out into a config--but it probably means that either the data files aren't getting created, or just that they are in a different location. Glancing at your icu.pl patch, it may just be missing moving the .dat file (or, maybe creating it too).
Now for the patch. I've attached my changes to icu.pl. Basically it's just
more stuff in the MS VC++ specific section of icu.pl. There are also some
files missing in CVS that we need (they were moved into the attic after
being considered unrequired, but it turns out they are for Win32 building).
I've attached a patch to put them back in. Note that as some parts of ICU
in the parrot tree have been removed, I had to modify the .dsw file so it
didn't contain references to the related project files. So, to be totally
clear, the .dsw file is different from what would be in the standard ICU
package.
I hope this is a move in the right direction. I guess building and failing
some tests is better than not building at all. ;-)
Definitely!
JEff
[**] There are 4 or so options for how to package the ICU data--into a dynamic library, into an archive library, as a bunch of separate files, or as a single file. Any should work, but the last two are faster to build, and a bit more flexible.
