Yehoshua Sapir
2007-05-02 19:51:17 UTC
# New Ticket Created by "Yehoshua Sapir"
# Please include the string: [perl #42861]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42861 >
This has a lot to do with tickets #42558 and #34994:
(there's quite a bit to read in both)
http://rt.perl.org/rt3/Public/Bug/Display.html?id=42558
http://rt.perl.org/rt3/Public/Bug/Display.html?id=34994
To get to config.fpmc (which is in runtime/parrot/include/), config.pir gets
Parrot's runtime prefix via interpinfo .INTERPINFO_RUNTIME_PREFIX (this is
part of patch #42558) and then adds "/runtime/parrot/include/config.fpmc"
onto it.
This works for an uninstalled Parrot, as the runtime prefix returned is the
Parrot root directory, where runtime/ lives.
On my machine, an installed Parrot returns "/usr/local" for the runtime
prefix, while the installed config.fpmc lives in
/usr/local/lib/parrot/include/ . So config.pir tries to look at
/usr/local/runtime/parrot/include and fails.
That was the bug report, my conclusions from here onwards :)
If the "runtime" directory gets installed to "/usr/local/lib", (or whatever)
then I think that for an installed Parrot that should be the runtime prefix.
I'm guessing there's some reason that /usr/local is returned here instead.
As far as I can tell, the only place that the runtime prefix is used in the
Parrot code is Parrot_locate_runtime_file_str (in library.c) where it's used
to prefix the library paths from parrot_init_library_paths (same file). That
function returns both options - both runtime/ and lib/, so it works in both
situations, but it seems to me it would be better to figure it out according
to the real location of the runtime.
Also, the runtime prefix is stored in the interpreter's IGLOBALS_CONFIG_HASH
under the key "prefix". I think it would probably be better to rename that
to "runtime_prefix".
# Please include the string: [perl #42861]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42861 >
This has a lot to do with tickets #42558 and #34994:
(there's quite a bit to read in both)
http://rt.perl.org/rt3/Public/Bug/Display.html?id=42558
http://rt.perl.org/rt3/Public/Bug/Display.html?id=34994
To get to config.fpmc (which is in runtime/parrot/include/), config.pir gets
Parrot's runtime prefix via interpinfo .INTERPINFO_RUNTIME_PREFIX (this is
part of patch #42558) and then adds "/runtime/parrot/include/config.fpmc"
onto it.
This works for an uninstalled Parrot, as the runtime prefix returned is the
Parrot root directory, where runtime/ lives.
On my machine, an installed Parrot returns "/usr/local" for the runtime
prefix, while the installed config.fpmc lives in
/usr/local/lib/parrot/include/ . So config.pir tries to look at
/usr/local/runtime/parrot/include and fails.
That was the bug report, my conclusions from here onwards :)
If the "runtime" directory gets installed to "/usr/local/lib", (or whatever)
then I think that for an installed Parrot that should be the runtime prefix.
I'm guessing there's some reason that /usr/local is returned here instead.
As far as I can tell, the only place that the runtime prefix is used in the
Parrot code is Parrot_locate_runtime_file_str (in library.c) where it's used
to prefix the library paths from parrot_init_library_paths (same file). That
function returns both options - both runtime/ and lib/, so it works in both
situations, but it seems to me it would be better to figure it out according
to the real location of the runtime.
Also, the runtime prefix is stored in the interpreter's IGLOBALS_CONFIG_HASH
under the key "prefix". I think it would probably be better to rename that
to "runtime_prefix".