The problem is that perl6-m is a generated file. So if you copy perl6-m to perl6, and then generate a new perl6-m runner, your version of perl6 is not the up to date version.
The runner isn't something that changes on a regular basis, but the dependency still need to be there. On Fri, Jan 2, 2015 at 5:00 AM, Christian Bartolomaeus via RT <perl6-bugs-follo...@perl.org> wrote: > On Thu Oct 02 14:03:42 2014, jn...@jnthn.net wrote: >> On Fri Aug 29 06:29:33 2014, coke wrote: >> > $ touch src/core/IO.pm >> > $ make -j3 >> > /Users/williamcoleda/perl6/bin/nqp-m tools/build/gen-cat.nqp moar -f >> > tools/build/moar_core_sources > src/gen/m-CORE.setting >> > /opt/local/bin/perl5.16 -MExtUtils::Command -e rm_f perl6 >> > /opt/local/bin/perl5.16 -MExtUtils::Command -e cp perl6-m perl6 >> > /opt/local/bin/perl5.16 -MExtUtils::Command -e chmod 755 perl6 >> > The following step can take a long time, please be patient. >> > /Users/williamcoleda/perl6/bin/moar >> > --libpath="/Users/williamcoleda/perl6/languages/nqp/lib" perl6.moarvm >> > --setting=NULL --ll-exception --optimize=3 --target=mbc --stagestats >> > --output=CORE.setting.moarvm src/gen/m-CORE.setting >> > Stage start : 0.000 >> > Stage parse : 29.488 >> > Stage syntaxcheck: 0.000 >> > Stage ast : 0.000 >> > Stage optimize : 2.504 >> > Stage mast : 9.085 >> > Stage mbc : 0.178 >> > /Users/williamcoleda/perl6/bin/moar >> > --libpath="/Users/williamcoleda/perl6/languages/nqp/lib" perl6.moarvm >> > --target=mbc --output=RESTRICTED.setting.moarvm >> > src/RESTRICTED.setting >> > ./perl6-m --target=mbc --output=lib/Test.pm.moarvm lib/Test.pm >> > ./perl6-m --target=mbc --output=lib/lib.pm6.moarvm lib/lib.pm6 >> > ./perl6-m --target=mbc --output=lib/Pod/To/Text.pm.moarvm >> > lib/Pod/To/Text.pm >> > >> > >> > Note that with a || build, the task for creating ./perl6 is run >> > immediately, even though the sources are out of date. >> > >> I don't immediately see the problem. The perl6 executable does not >> have CORE.setting bundled into it; the setting is "just" a library >> that it loads. Therefore, there's no reason it can't be produced in >> parallel with, or before, CORE.setting, so long as we don't try to run >> it until after the setting is also built. And so far as I can see, all >> the ./perl6-m come after that. >> >> Or am I tired and missing the point? :-) >> >> /jnthn > > I also think, this is fine as it is. Since the (very short) shell script > "perl6-m" is unchanged, there is no problem in copying it to "perl6". As > jnthn pointed out, the actual execution of ./perl6-m happens only after > building the settings. > > I'm closing this ticket now. Please reopen if I overlooked something. > -- Will "Coke" Coleda
