I have been following the development of Raku. (My first Perl build was version 4.19.) Even though my ‘C’ skills are ancient and creaky I’ve decided to attempt a Cygwin port of Rakudo as a skills refresher and then attempt a first time Raku (in lieu of the Perl5 I would otherwise use) project for personal use. I have perl5 and both the gcc and clang/LLVM toolchains installed install in my Cygwin environment and ideally will get Rakudo to build with both C compiler suites as an exercise in portability improvement I might contribute upstream.
My strategy is to step-wise achieve compile and such tests as there are for MoarVM then NQP then Rakudo using the gcc toolchain then attempt the clang toolchain. As a start I have acquired both the tarball from https://www.moarvm.org/ and the git clone from github.com/MoarVM/MoarVM.git.
“If you use the automatically generated release tarballs or zip files please note that they don't contain the third party libraries needed to successfully build MoarVM.”
Immediately this seems the exact opposite of what I observe – the MoarVM tarball tree has a fully populated 3rdparty directory tree whereas the git clone tree does not. What?
End side note.
Well, the MoarVM tarball tree should be more self-contained and depend less on the Cygwin installation and that is fine because, conveniently, the git clone tree with its unpopulated 3rdparty tree will depend on Cygwin, which goes to improving portability as I resolve the dependencies as much as possible from Cygwin. I am starting with the tarball tree to defer as many external dependencies as possible.
I have arranged for gcc to run with -std=c18 as a first portability exercise. A multitude of gnu-isms showed up but I have been fixing them to C18 compile easily enough. Until…
There are some C code files that are generated using scripts in tools/*. I will likely have to tweak some of those scripts to get them emitting C18 compliant code. Yes, I have noticed src/core/opslist computed goto gnu-ism dependent tangle. OK, fine, except some of those scripts are .p6 scripts. Perl6/Raku scripts.
Oops. Fatal meta-recursion. Can’t do a scratch port and build of MoarVM without having… a working Rakudo. This is a noticeable portability block to environments where Rakudo does not already exist even though they already have a C complier and perl5. Steps to reproduce:
On a host system that has a Posix-y utilities environment plus perl5 and C compiler but DOES NOT already have a working Raku interpreter:
1. Download and unpack the source tarball from https://www.moarvm.org/
2. perl5 Configure.pl of course
3. Touch src/core/opslist or otherwise arrange a make dependency condition that forces the perl6 C-code generation scripts in tools/* to be invoked.
4. make
5. The ‘make’ should fail for lack of a perl6.
In an automated CI release environment the above would seem an easy portability quality assurance test to implement on the end release artifacts (tarballs and git clones).
Possible solutions are:
1. Re-writing the tools/* perl6 scripts as perl5 scripts (or something more generally portable in Posix-y environments).
2. Write perl5 scripts to post-process the perl6 script generated C code that arrives with the tarball or git clone trees in to C99 compliant code.
3. Attempt to complete a “dirty” Cygwin build as is then use the Rakudo result to run modified .p6 C-code generation scripts to improve C18 compliance. Re-build.
4. Cheat and install (Windows) Rakudo Star then basically option 3.
From a portability POV option 1 results in tools/ artifacts that are candidates for contribution to upstream as portability improvement for Rakudo as a whole. However, before I proceed I am requesting community guidance regards the reasoning for using perl6 scripts for C code generation in the first place. Is there a blocking reason those tools/ perl6 code generation scripts can’t be (re-)implemented in a more portable way? That is, other than in Raku code?
I suspect it was just drift at the time without developers noticing the fatal meta-recursion problem because they already had some working version of perl6 available on their development hosts.
I have been following the development of Raku. (My first Perl build was version 4.19.) Even though my ‘C’ skills are ancient and creaky I’ve decided to attempt a Cygwin port of Rakudo as a skills refresher and then attempt a first time Raku (in lieu of the Perl5 I would otherwise use) project for personal use. I have perl5 and both the gcc and clang/LLVM toolchains installed install in my Cygwin environment and ideally will get Rakudo to build with both C compiler suites as an exercise in portability improvement I might contribute upstream.
My strategy is to step-wise achieve compile and such tests as there are for MoarVM then NQP then Rakudo using the gcc toolchain then attempt the clang toolchain. As a start I have acquired both the tarball from https://www.moarvm.org/ and the git clone from github.com/MoarVM/MoarVM.git.
Side note - The instructions at https://github.com/MoarVM/MoarVM indicate
“If you use the automatically generated release tarballs or zip files please note that they don't contain the third party libraries needed to successfully build MoarVM.”
Immediately this seems the exact opposite of what I observe – the MoarVM tarball tree has a fully populated 3rdparty directory tree whereas the git clone tree does not. What?
End side note.
Well, the MoarVM tarball tree should be more self-contained and depend less on the Cygwin installation and that is fine because, conveniently, the git clone tree with its unpopulated 3rdparty tree will depend on Cygwin, which goes to improving portability as I resolve the dependencies as much as possible from Cygwin. I am starting with the tarball tree to defer as many external dependencies as possible.
I have arranged for gcc to run with -std=c18 as a first portability exercise. A multitude of gnu-isms showed up but I have been fixing them to C18 compile easily enough. Until…
There are some C code files that are generated using scripts in tools/*. I will likely have to tweak some of those scripts to get them emitting C18 compliant code. Yes, I have noticed src/core/opslist computed goto gnu-ism dependent tangle. OK, fine, except some of those scripts are .p6 scripts. Perl6/Raku scripts.
Oops. Fatal meta-recursion. Can’t do a scratch port and build of MoarVM without having… a working Rakudo. This is a noticeable portability block to environments where Rakudo does not already exist even though they already have a C complier and perl5. Steps to reproduce:
On a host system that has a Posix-y utilities environment plus perl5 and C compiler but DOES NOT already have a working Raku interpreter:
In an automated CI release environment the above would seem an easy portability quality assurance test to implement on the end release artifacts (tarballs and git clones).
Possible solutions are:
From a portability POV option 1 results in tools/ artifacts that are candidates for contribution to upstream as portability improvement for Rakudo as a whole. However, before I proceed I am requesting community guidance regards the reasoning for using perl6 scripts for C code generation in the first place. Is there a blocking reason those tools/ perl6 code generation scripts can’t be (re-)implemented in a more portable way? That is, other than in Raku code?
I suspect it was just drift at the time without developers noticing the fatal meta-recursion problem because they already had some working version of perl6 available on their development hosts.
Regards.