On Wed May 02 12:51:17 2007, [email protected] wrote: > 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".
I'm hoping this issue was fixed before 1.0; Can someone verify? -- Will "Coke" Coleda _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
