Parse params via a built-in, and lock msys2 version #2690
Conversation
|
Can one of the admins verify this patch? |
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
| <dependency id="jdk8" version="[8.0.102,)"/> | ||
| <dependency id="msys2" version="[20160719.1,)"/> | ||
| <dependency id="msys2" version="[20160719.1.0]"/> |
There was a problem hiding this comment.
@laszlocsomor - I'm going on trust that this is the version that you'd like to pin to. https://chocolatey.org/packages/msys2 lists the ones that are available.
There was a problem hiding this comment.
Do we have to pin to an exact version, or is it enough to pin 20160719.1.x?
There was a problem hiding this comment.
You asked me to pin it to the precise version inside #2449 (comment) on the basis that others didn't work for bazel (at the time).
I haven't tested that assertion, and also haven't seen issues reported about bazel failures against later versions (there's 20160719.1.1, and there are also later versions in the moderation queue (this is a paged link)).
There was a problem hiding this comment.
Ah :) I've seen failures with newer major versions (20170130 specifically), but I also haven't tested with 20160719's other minor/patch versions. The problem was binary incompatibility with msys-2.0.dll between the two major versions, but I believe they should be compatible within the same major one.
Aaand fortunately this will soon not matter because we're close to removing the msys dependency :) (we'll still need some msys installed in order to have a bash.exe to run, but bazel itself won't be tied to a given version).
There was a problem hiding this comment.
In that case, shall I simply back out this change (the version pin) as unnecessary?
There was a problem hiding this comment.
No, please don't. As i understand it, both 20160719.1.0 and 20160719.1.1 are good, but versions with a more recent first part (e.g. 20170130.x.y) seem to be bad. So the pin should be [20160719.1.0,20160719.1.1].
|
I signed it! |
|
Importing. Not sure why you keep getting the "cla: no" status. :( Could it be that you're using a different github account than before? |
|
...or different email? |
|
I tried to figure out why you keep getting the "cla: no" label. I could verify that Improbable signed a corporate CLA, so the question is why your account isn't associated with it. Could you try finding out please who's managing Improbable's CLA group and have them add your email to it? Also, what do you see on https://cla.developers.google.com/clas? |
|
I see this: I've had my improbable.io email account added to my github profile since probably late September at least. I'm definitely using the same github account as ever. |
|
I signed it! |
|
CLAs look good, thanks! |
|
Hurrah! Turns out I wasn't a member of the google group that we used to sign that; now I am. |
|
Hooray! Great. Thanks for following through! :) Importing now. |
@laszlocsomor - This addresses bazelbuild#2449 (comment). Note - this is _not_ in the 0.4.5 package, since I was waiting for that release to go out prior to this. Closes bazelbuild#2690. PiperOrigin-RevId: 150745085
@laszlocsomor - This addresses #2449 (comment).
Note - this is not in the 0.4.5 package, since I was waiting for that release to go out prior to this.