[CVS ci] runtime prefix
Leopold Toetsch
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.
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.
Comments welcome,
leo
PS I've stripped down installed files, e.g. no languages are installed.
AFAIK these more or less are using "../../parrot" or such. We finally
need some setting, if a language executable is able to run with an
installed Parrot executable and a way to specify that for "make
install". But that's probably for the next release.
Nicholas Clark
> 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
Leopold Toetsch
> 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
Leopold Toetsch
> 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
Parrot now checks the env var PARROT_TEST. If it's defined, the runtime
--prefix is ignored.
leo