search

Raku / nqp-configure

Configuration and build modules for NQP
Artistic License 2.0
4 stars 8 forks source link

Cannot determine the brand of your nmake utility #19

Closed ugexe closed 4 years ago

ugexe commented 4 years ago

I'm seeing the error below for about 50% of my appveyor builds. Appears to be incomplete stdout... can this potentially be fixed or is this just appveyor being weird?

+++ Compiling blib\CORE.d.setting.moarvm
The following step can take a long time, please be patient.
Stage start      :   0.000
Stage parse      :   0.552
Stage syntaxcheck:   0.001
Stage ast        :   0.001
Stage optimize   :   0.042
Stage mast       :   0.079
Stage mbc        :   0.003
+++ Generating gen\moar\BOOTSTRAP\v6e.nqp
+++ Compiling blib\Perl6\BOOTSTRAP\v6e.moarvm
+++ Compiling blib\CORE.e.setting.moarvm
===SORRY!===
  Cannot determine the brand of your nmake utility.
  It is reporting itself as:

  Microsoft (R) Program Mai at C:/projects/rakudo/3rdparty/nqp-configure/lib/NQP/Config.pm line 192.
 at C:/projects/rakudo/3rdparty/nqp-configure/lib/NQP/Config.pm line 34.
    NQP::Config::__ANON__("===SORRY!===\x{a}  Cannot determine the brand of your nmake utili"...) called at C:/projects/rakudo/3rdparty/nqp-configure/lib/NQP/Config.pm line 192
    NQP::Config::sorry(NQP::Config::Rakudo=HASH(0x1643e8), "Cannot determine the brand of your nmake utility.\x{a}It is repor"...) called at C:/projects/rakudo/3rdparty/nqp-configure/lib/NQP/Config.pm line 537
    NQP::Config::configure_commands(NQP::Config::Rakudo=HASH(0x1643e8)) called at C:\projects\rakudo\Configure.pl line 91
NMAKE : fatal error U1077: 'C:\strawberry\perl\bin\perl.exe' : return code '0xff'
Stop.
Command exited with code 2
vrurg commented 4 years ago

Unreproducible under a Win7 VM. I have done a couple of runs (didn't have much time today) but none ended up like this.

The version about appveyor weirdness looks reasonable unless we have a bug in IPC::Cmd module. Neither case means we can ignore it.

When I get a few spare minutes I'll try to setup appveyor for my repo fork and see what happens.

vrurg commented 4 years ago

I have tried several builds in a row over rakudo/rakudo@ef90599e2b6fde85385633b373b706b89d546763 on appveyor. None failed. Do you use the standard appveyor.yml?

Altai-man commented 4 years ago

I think it is about rakudo builds, no? The bug happens from time to time, e.g. https://ci.appveyor.com/project/rakudo/rakudo/builds/32748843/job/7saapt6h27c4ihkr (not so old commit).

vrurg commented 4 years ago

I have googled out an interesting note: https://gitlab.inria.fr/simgrid/simgrid/blob/bc0a801f43c2f629b14e3e6153924fecf6ee9ec5/appveyor.yml#L37

@ugexe can you try perl 5.18 in your setup?

patrickbkr commented 4 years ago

A very simiar problem occurred on HPUX some years ago. This was the bugreport: bugreport This was the fix: fix

The fix was then changed to only apply to HPUX. Also it seems run() on Windows takes a different code path, so the fix would not have worked here. Still I suspect the underlying cause to be the same.

Going back to Perl 5.18 will be difficult as we'll have to rework tools/build/update-submodules.pl to not depend on Perl >= 5.22 on Windows.

I hate our CI to block on a problem like this. Are there any ideas to work around this?

ugexe commented 4 years ago

Are there any ideas to work around this?

Maybe nmake detection needs to try more than once.

vrurg commented 4 years ago

@patrickbkr Can you try @ugexe suggestion? Since I never seen the problem it'll be nearly impossible for me to test.

patrickbkr commented 4 years ago

Not pushed and proven in CI yet. Reopening.

vrurg commented 4 years ago

@patrickbkr I have updated the submodule version on Rakudo to fix NQP and roast repo URLs. You can give it a try now.

patrickbkr commented 4 years ago

Nmake failures haven't shown up since that merge (I did a lot of test builds on AzureCI while I worked on AzureCI integration). So I think this can be closed.