Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

rurban (7989)

rurban
  reversethis-{ta.yar-x} {ta} {nabrur}
http://rurban.xarch.at/

cygwin maintainer for perl, parrot, clisp, postgresql, ... and some perl modules (perl-libwin32, perl-Win32-GUI). Has also some hairy CPAN packages: B::C, B::Generate, C::DynaLib, B::Debugger ...

Journal of rurban (7989)

Sunday July 27, 2008
12:53 PM

parrot and perl6 on cygwin

[ #37023 ]

The parrot and perl6 packages had been updated for cygwin.

Packaging was a major struggle because from my limited point of view there are still some major architectural hurdles running a self-hosting rakudo perl6.exe and the languages.
The test-suite from within the source directory works just fine. And working within the source directory also.

It will get problematic when you start to try a make install, which is not yet supported. Now I know why. In parrot we have a global _config hash, just like in the perl5 module Config.pm.
But parrot is more self-containing, i.e. perl6.exe already contains this hash in a frozen state.

And there are even two different binaries: perl6.exe which only works inside the source dir, and installable_perl6.exe which accesses /usr/lib/parrot/include/... and not /runtime/parrot/include

The problem is that the runtime subdirs are mapped to /usr/lib/parrot, not all required files are installed on make reallyinstall, and the worst,
that some installable_* exe files still try to access /usr/runtime/parrot/include/config.pir (the global hash which is already linked into the binary), using a non-FHS compliant path (it should be /usr/lib/parrot/include/config.pir at least)

The build system is quite clever linking to a seperate install_config.o for those installables.
But some important functions like .include or load_bytecode still try to access /usr/lib/parrot/include/config.pir even if the hash is already loaded. And _config is only required to get the lib_path, to be able to traverse the dirs. A typical chicken-and-egg bootstrapping problem.

I wonder how to fix this the easiest way.
1. Maybe I just missed some trick and it should work ootb right now.
2. check if a a global _config hash exists and use it in load_bytecode and include and avoid loading config.pir in _config() if so.

This has a API limitation.
a. _config() is a function, not a hash, and
b. _config has no sideeffects, it just returns a hash into a local $P0 e.g. so you never know how to access the frozen hash at install_config.o.

If _config would be a global hash, you could just check for it, and avoid loading the file with the definition of _config. Since _config() is a global function I see no major problem changing the API from a global function to a global hash.
Maybe that's what interpinfo .INTERPINFO_RUNTIME_PREFIX is for. Haven't found the idea behind that yet.

Note: All this is just needed so that frozen states don't do unnecessary file accesses to files in wrong lib_paths (/usr/runtime/parrot). Once _config is initialized, the lib_path is correct and no wrong stats are done.
And runtime/parrot/include is also gone.
But this patch is still hardcoded into some libs. BAD!

A basic module system, like require would also help. Then I would just say .require 'config'

The idea to remove to formerly interpreter global config hash was re-entrancy (as explained by particle on irc). At least it worked before.
The current idea is to freeze the sub _config() and not the hash. So when the frozen _config is linked it is already available and find_sub('_config') can be used to check its existance and avoid unnecessary attempts to find 'include/config.pir' in a non-existing lib_path.

Tickets: http://rt.perl.org/rt3/Ticket/Display.html?id=56996
http://rt.perl.org/rt3/Ticket/Display.html?id=57236

There are more major hurdles for installable parrot languages.
make install e.g. is missing for the languages also, and make test-installable to test against a installable_$lang.exe without accessing the build_dir, only accessing an already installed parrot.

http://rt.perl.org/rt3/Ticket/Display.html?id=56554 contains some info, but most info is in the cygwin parrot source package, the cygport file and the patches. The source is now online at http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.