Windows: updated instructions

[perlun]

Details about changes:

• MSYS2: Removed the reference to the update-core script, which has been removed in MSYS2: Alexpux/MSYS2-pacman#26.
• Added more details about strange prompts that might appear. :)
• Added more details on how to install Python correctly.

With these changes in place, I am successfully able to at least get the build starting. (getting non-Python related errors, but will file a separate issue about that)

---

This change is

[perlun]

r? @metajack

[aneeshusa]

Partial upgrades are unsupported by pacman (at least natively on Arch, not sure about on MSYS). We should combine these two lines into pacman -Syu git mingw-w64-x86_64-toolchain ....

[metajack]

This looks good, but have you verified this works on a fresh install? I seem to recall that deep withing some configure script it relied on mingw python not the system python. this seems to remove the instructions to install mingw python (and then let native python through for python2.7). I'm very happy if this is actually possible, but skeptical considering how much fighting @larsbergstrom and @vvuk did with this.

If it does work, this is r=me with the nit from @aneeshusa fixed.

Previously, perlun (Per Lundberg) wrote…

r? @metajack

---

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

---

README.md, line 84 [r1] (raw file):

Previously, aneeshusa (Aneesh Agrawal) wrote…

Partial upgrades are unsupported by pacman (at least natively on Arch, not sure about on MSYS). We should combine these two lines into pacman -Syu git mingw-w64-x86_64-toolchain ....

👍 x

---

Comments from Reviewable

[vvuk]

Oops, sorry; it's late and I didn't see the change to msys2 to have pacman natively understand system updates. Carry on :p

[aneeshusa]

@vvuk Actually, I looked into a bit more after your comment and I think my earlier comment may not be correct. It seems that after a pacman -Syu, it may be required to restart MSYS (and maybe run pacman -Syu again? not sure) before installing packages.

See commonquail/pa#2 and the warnings in the image from Alexpux/MSYS2-pacman#26.

[perlun]

Thanks for the feedback. Will retry with these instructions on a fresh MSYS2 install just to ensure that they are fully followable. 😄

[vvuk]

@aneeshusa Yeah, I'm guessing the "native support" just does an update to the core packages first, and then prompts you to restart.. after that, a second update would be required to take care of the rest of the packages. It's better than before, where doing a full update that picked up core packages would cause a lot of stuff after it to fail, leaving the system in an inconsistent state.

[highfive]

New code was committed to pull request.

[highfive]

New code was committed to pull request.

[perlun]

I'm very happy if this is actually possible, but skeptical considering how much fighting @larsbergstrom and @vvuk did with this.

You're right, it seems to not fully work; I am getting errors in mozjs_sys which seems to have some of its own magic going on. I will try to see if that's easily solvable upstream. Relying on a single Python would, like you say, be a more natural approach to the build tooling.

[metajack]

@perlun Any new info on this?

[perlun]

@perlun Any new info on this?

Ah, sorry for lack of feedback on my behalf.

I tried to get `mozjs_sysz to compile using a native Python; managed to get some stuff working but ended up banging my head into the wall because of lack of enough Python-fu skills. 😇 So, I couldn't get it working and kind of gave up; haven't tried anything more the last few days.

So, it wasn't completed.

I wonder if we should try it the other way around instead? I.e. make it work with the MSYS/MINGW-provided Python instead, to remove the need to require a native Python. The text indicates that this doesn't work "out of the box" but does anyone (you or others) have an idea of how much work it would take? I would be willing to experiment a bit there I think.

I'm also kind of wondering: since you are doing a bit of work on the "other" Windows-based toolchain support (i..e MSVC/Visual Studio), which one is going to be "the way" going forward? Do we intend to support both of them (like rustc does) or is the plan to pick the one we feel is best and drop support for the other one? To put it bluntly: would it make more sense that I help out in getting the MSVC-based port more complete? What do you think?

[metajack]

The best scenario would be to support both with msvc builds requiring normal python, and msys builds requiring msys python, but not having both.

I'd also probably be fine supporting only msvc builds since that is probably what people will want given the debugging situation. I'll ask others.

In the meantime, should we close this?

[perlun]

The best scenario would be to support both with msvc builds requiring normal python, and msys builds requiring msys python, but not having both.

Alright, that sounds reasonable. I'll see how hard it would be to get the msys build working with msys python.

In the meantime, should we close this?

Yes. I opened a new one with the update-core change, since that should be a no-brainer to merge. Thanks for taking some time to ensure we get things closed & moving forward! Good for everybody.