On Thu, Oct 07, 2004 at 11:25:49AM +0200, Leopold Toetsch wrote: > Short version: an installed Parrot is now able to locate its ICU data. > > The longer story: During "make" a new file src/parrot_config.c is > created holding currently just one entry: the install --prefix directory. > During string_init that directory is stat()ed and when the *directory* > exists, ICU data are set to $prefix/blib/lib/icu/2.6.1/foo.
I don't think that this logic as currently implemented is correct. If I build parrot as: perl Configure.pl --prefix=`echo ~/test/foo` && make all test then all the tests pass (because ~/test/foo doesn't exist) If I touch ~/test/foo then many many tests fail. I think that the stat needs to be on the ICU data file (or at least its directory) Currently, if you want to install to /usr/local and /usr/local already exists then make test will fail. Secondly, the ICU data shouldn't be down .../blib/lib once installed, should it? The 'blib' directory is used on perl5 for MakeMaker to put the architecture dependant files during building, but they get installed in some other location with a name built from perl's architecture string, so that multiple architectures' files can co-exist on one filesystem. > Using the same strategy for Parrot libs and includes (from > runtime/parrot) could be a bit problematic: if Parrot got installed > once, these files would always come from the installed directory, even > when a newer version is in the build directory as long as the Parrot > version is the same. The convention for perl5's tests isn't quite settled yet, but it seems to be evolving to PERL_CORE being in the environment for the test scripts, and the scripts setting @INC explicity. I think that it would be best (if possible) for parrot to be built to expect to find all its files (including ICU data files) in the installed location, and then all the build and test scripts knowing to manually override the include path/search location/whatever. Can ICU be told to find its data files elsewhere via an environment variable override? Should we provide one? Nicholas Clark
