use Perl

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