Nicholas Clark <[EMAIL PROTECTED]> wrote: > 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. Yep. That's how it is working now and what I've documented above. > I think that the stat needs to be on the ICU data file (or at least its > directory) Basically yes. But testing for the ICU data file needs more config support (there are at least two flavors of data files: big & little endian). Testing the data directory moved the (un)logic just a bit down the tree. What we really need is a means to express that Parrot is installed and should use the --prefix directory tree or just not. > Currently, if you want to install to /usr/local and /usr/local already exists > then make test will fail. You don't want to use --prefix=/usr/local - that clutters up /usr/local itself. Another TODO item. > Secondly, the ICU data shouldn't be down .../blib/lib once installed, should > it? Probably not. The current installer basically just duplicates the source directory structure. > ... 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. Well, that is the default: /usr/local/parrot-0.1.1/ >> 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. Ok. > Can ICU be told to find its data files elsewhere via an environment variable > override? Should we provide one? ICU itself seems to have a getenv() override, Parrot checks PARROT_ICU_DATA_DIR. But I don't want to have separate settings for ICU. One environment variable ought to be enough. > Nicholas Clark leo
