ability to create dynoplibs and dynpmclibs from installed parrot (rescheduled from 0.9.0)

[particle]

make sure pmc2c and ops2c tools are available on an installed parrot, for hll developers.

[rurban]

Where should our lib/Parrot/* perl5 support libs being installed to?

1. /usr/lib/parrot/perl5/ (awful)
2. $(perl -V::installsitelib:)
3. Or seperate the libs into a CPAN support package?

We could add such a target into the makefile

[pmichaud]

Followup with some specifics for Rakudo based on early testing...

In order for Rakudo to build from an installed Parrot, we need to have working copies of dynpmc.pl and dynopslib.pl somewhere in the installation.

Pm

[rurban]

particle: I can help you there.

I've added install_files.pl --devel for a make install-devel target.

[devel] will be installed into /usr/lib/parrot/tools/{lib,examples,editor,build,src,dev,install,util}

[rurban]

Some more requirements for this target:

• $PConfig{installed} must be present for the tools to choose the right linker paths
  • this requires a Parrot::Config::Generated fixup in the installer
  • I had a patch in my pdd30install branch to add the 'installed' config hash key to the frozen config for the parrot runtime, and for src/library.c

• the tools with linker steps must use $PConfig{installed} to fixup libparrot_ldflags

• tt312-win32-linking.patch must be used to sanify static and shared conflicts

[allison]

This was resolved by adding an 'install-dev' target that installs necessary build tools, and by creating tools/dev/gen_makefile.pl to generate makefiles independent of Parrot's configuration process. Each language with dynamic PMCs or ops creates a makefile template, which is then processed by gen_makefile.pl.

To demonstrate that the solution was adequate, I submitted patches to Rakudo and Tcl that allow them to build and test entirely from an installed parrot.