Bump to mono/2017-04/dbb63b19 #600

jonpryor · 2017-05-22T15:38:56Z

We want to aim for ~weekly mono bumps while we prepare for release.

jonpryor · 2017-05-24T20:20:38Z

The failure is because this is the first time a full build has run on xam-mac-mini-6, which doesn't have MXE pre-built, and things fail when we build MXE. (I'll need to investigate how/why the MXE build broke...)

Rebuild, so hopefully we'll hit a different machine.

jonpryor · 2017-05-24T20:20:43Z

build

An attempt to [bump `external/mono/`][0] resulted in a [build failure on a macOS machine][1]: Executing: make MSBUILD_ARGS=/p:AutoProvision=True/ /p:AutoProvisionUsesSudo=True V=1 MXE_TARGETS="i686-w64-mingw32.static" gcc cmake zlib pt hreads dlfcn-win32 mman-win32 PREFIX="/Users/builder/android-toolchain/mxe" make[1]: *** No rule to make target `/p:AutoProvisionUsesSudo=True'. Stop. (This happens on a macOS machine that hasn't previously built+installed MXE which needs MXE in order to generate Windows binaries, so auto-builds MXE...) This error is due to the interraction of three separate choices: 1. Jenkins is running: make prepare jenkins V=1 MSBUILD_ARGS="/p:AutoProvision=True /p:AutoProvisionUsesSudo=True" 2. xbuild replaces `\` with `/`. 3. The `_CreateMxeToolchains` target uses `make $(MAKEFLAGS)`. Background: what is `$(MAKEFLAGS)`? `$(MAKEFLAGS)` is set by **make**(1) and [contains the command-line flags to `make`][2]. It's value is shown elsewhere in the log file: MAKEFLAGS = MSBUILD_ARGS=/p:AutoProvision=True\ /p:AutoProvisionUsesSudo=True V=1 Note that `$(MAKEFLAGS)` contains a backslash: this is because of the original command, which provides a space-containing value for `$(MSBUILD_ARGS)`: MSBUILD_ARGS="/p:AutoProvision=True /p:AutoProvisionUsesSudo=True" Instead of preserving the quotes, `make` instead replaces ` ` (space) with `\ ` (backslash-space), which is perfectly valid: # MAKEFLAGS set "as if" we executed: make prepare jenkins V=1 MSBUILD_ARGS=/p:AutoProvision=True\ /p:AutoProvisionUsesSudo=True The problem is when `xbuild` enters the picture: xbuild can't differentiate between paths and...anything else, so for simplicity and sanity it *always* replaces `\` with the directory-separtor-char, which is `/` on macOS/Linux. Unfortunately, this *completely* changes the semantics of the embedded `MSBUILD_ARGS` value within `$(MAKEFLAGS)`: replacing `\ ` with `/ ` causes the `/p:AutoProvisionUsesSudo=True` to be treated as target by `make`, and that target doesn't exist. In theory, `xbuild` could be fixed to address this. In practice, `xbuild` isn't getting any future work. `msbuild` *is* getting more work, but this "corner case" is likely sufficiently complicated that it might not ever get fixed. Thus, the simple fix: Don't Do That™: remove use of `$(MAKEFLAGS)`. It isn't needed in this invocation. [0]: dotnet#600 [1]: https://jenkins.mono-project.com/job/xamarin-android-pr-builder/955 [2]: https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/The-Make-Macro-MAKEFLAGS.html

jonpryor · 2017-05-24T20:45:12Z

The MXE issue mentioned above is fixed in #603.

jonpryor · 2017-05-25T00:21:37Z

build

An attempt to [bump `external/mono/`][0] resulted in a [build failure on a macOS machine][1]: Executing: make MSBUILD_ARGS=/p:AutoProvision=True/ /p:AutoProvisionUsesSudo=True V=1 MXE_TARGETS="i686-w64-mingw32.static" gcc cmake zlib pt hreads dlfcn-win32 mman-win32 PREFIX="/Users/builder/android-toolchain/mxe" make[1]: *** No rule to make target `/p:AutoProvisionUsesSudo=True'. Stop. (This happens on a macOS machine that hasn't previously built+installed MXE which needs MXE in order to generate Windows binaries, so auto-builds MXE...) This error is due to the interraction of three separate choices: 1. Jenkins is running: make prepare jenkins V=1 MSBUILD_ARGS="/p:AutoProvision=True /p:AutoProvisionUsesSudo=True" 2. xbuild replaces `\` with `/`. 3. The `_CreateMxeToolchains` target uses `make $(MAKEFLAGS)`. Background: what is `$(MAKEFLAGS)`? `$(MAKEFLAGS)` is set by **make**(1) and [contains the command-line flags to `make`][2]. It's value is shown elsewhere in the log file: MAKEFLAGS = MSBUILD_ARGS=/p:AutoProvision=True\ /p:AutoProvisionUsesSudo=True V=1 Note that `$(MAKEFLAGS)` contains a backslash: this is because of the original command, which provides a space-containing value for `$(MSBUILD_ARGS)`: MSBUILD_ARGS="/p:AutoProvision=True /p:AutoProvisionUsesSudo=True" Instead of preserving the quotes, `make` instead replaces ` ` (space) with `\ ` (backslash-space), which is perfectly valid: # MAKEFLAGS set "as if" we executed: make prepare jenkins V=1 MSBUILD_ARGS=/p:AutoProvision=True\ /p:AutoProvisionUsesSudo=True The problem is when `xbuild` enters the picture: xbuild can't differentiate between paths and...anything else, so for simplicity and sanity it *always* replaces `\` with the directory-separtor-char, which is `/` on macOS/Linux. Unfortunately, this *completely* changes the semantics of the embedded `MSBUILD_ARGS` value within `$(MAKEFLAGS)`: replacing `\ ` with `/ ` causes the `/p:AutoProvisionUsesSudo=True` to be treated as target by `make`, and that target doesn't exist. In theory, `xbuild` could be fixed to address this. In practice, `xbuild` isn't getting any future work. `msbuild` *is* getting more work, but this "corner case" is likely sufficiently complicated that it might not ever get fixed. Thus, the simple fix: Don't Do That™: remove use of `$(MAKEFLAGS)`. It isn't needed in this invocation. [0]: #600 [1]: https://jenkins.mono-project.com/job/xamarin-android-pr-builder/955 [2]: https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/The-Make-Macro-MAKEFLAGS.html

Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56240 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56493 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56567 We want to aim for ~weekly mono bumps while we prepare for release.

jonpryor · 2017-05-25T18:20:31Z

build

jonpryor · 2017-05-25T18:22:10Z

The previous build failed because autopoint wasn't in $PATH.

autopoint wasn't in $PATH because -- on that particular build machine -- it was using a "new" brew 1.2+ release, and brew install gettext wasn't placing autopoint into $PATH.

We ran brew link --force gettext on that machine, and kicked off a new build.

We'll need to document this autopoint requirement in README.md.

jonpryor · 2017-05-27T01:43:06Z

Obsoleted by PR #611.

Changes: dotnet/java-interop@27cfd45...bd7c60a * dotnet/java-interop@bd7c60a: [generator] Support //interface/@no-alternatives (#601) * dotnet/java-interop@105d544: [generator] Remove interface alternatives w/ interface-constants (#600) * dotnet/java-interop@b255981: [build] Remove extraneous `nuget restore`s (#599) * dotnet/java-interop@2a59c40: [CI] Specify our PR build trigger in YAML. (#598) * dotnet/java-interop@0a3354b: [Java.Interop.Tools.Cecil] use File.Exists instead of DirectoryGetFile (#596) Reduces the `<LinkAssembliesNoShrink/>` task time from about 711ms to 426ms for a small test Xamarin.Forms app on an initial clean build. Updates `generator --lang-features=interface-constants` output so that we stop emitting the `*Consts` classes in API-R. API Breakages: * `tests/api-compatibility/acceptable-breakages-v10.0.99.txt`: These are because we are no longer generating the `*Consts` types when for Default Interface Methods are enabled. * `tests/api-compatibility/acceptable-breakages-v10.0.txt`: These are because there was a bug where we were not generating `[Obsolete]` on fields that were turned into properties. Now the attribute is generated in API-28 (the "contract"), but they are no longer marked as deprecated by Google in API-29 (the "implementation"), so they appear as removing the attribute. * `tests/api-compatibility/acceptable-breakages-v8.0.txt`: As with v10.0, a "prop-ified" field was missing `[Obsolete]`, and Google later un-deprecated the field.

Changes: dotnet/java-interop@35f30bf...a84d19e * dotnet/java-interop@a84d19e: [generator] Support //interface/@no-alternatives (#601) * dotnet/java-interop@f34ed03: [generator] Remove interface alternatives w/ interface-constants (#600) * dotnet/java-interop@c5b8aca: [CI] Specify our PR build trigger in YAML. (#598) * dotnet/java-interop@d589f1c: [Java.Interop.Tools.Cecil] use File.Exists instead of DirectoryGetFile (#596) Reduces the `<LinkAssembliesNoShrink/>` task time from about 711ms to 426ms for a small test Xamarin.Forms app on an initial clean build. Updates `generator --lang-features=interface-constants` output so that we stop emitting the `*Consts` classes in API-R. API Breakages: * `tests/api-compatibility/acceptable-breakages-v10.0.99.txt`: These are because we are no longer generating the `*Consts` types when for Default Interface Methods are enabled. * `tests/api-compatibility/acceptable-breakages-v10.0.txt`: These are because there was a bug where we were not generating `[Obsolete]` on fields that were turned into properties. Now the attribute is generated in API-28 (the "contract"), but they are no longer marked as deprecated by Google in API-29 (the "implementation"), so they appear as removing the attribute. * `tests/api-compatibility/acceptable-breakages-v8.0.txt`: As with v10.0, a "prop-ified" field was missing `[Obsolete]`, and Google later un-deprecated the field.

jonpryor added the full-mono-integration-build For PRs; run a full build (~6-10h for mono bumps), not the faster PR subset (~2h for mono bumps) label May 22, 2017

dnfclas added the cla-already-signed label May 22, 2017

jonpryor force-pushed the jonp-bump-mono-dbb63b19 branch 2 times, most recently from 19ceb26 to d723636 Compare May 22, 2017 15:42

jonpryor changed the title ~~Bump to mono/2017-02/dbb63b19~~ Bump to mono/2017-04/dbb63b19 May 24, 2017

jonpryor mentioned this pull request May 24, 2017

[android-toolchain] Remove use of $(MAKEFLAGS) #603

Merged

jonpryor force-pushed the jonp-bump-mono-dbb63b19 branch from d723636 to dac9419 Compare May 24, 2017 21:29

Bump to mono/2017-04/dbb63b19

b3ad96d

Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56240 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56493 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56567 We want to aim for ~weekly mono bumps while we prepare for release.

jonpryor force-pushed the jonp-bump-mono-dbb63b19 branch from dac9419 to b3ad96d Compare May 25, 2017 15:28

jonpryor closed this May 27, 2017

github-actions bot locked and limited conversation to collaborators Feb 5, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Bump to mono/2017-04/dbb63b19 #600

Bump to mono/2017-04/dbb63b19 #600

Uh oh!

jonpryor commented May 22, 2017

Uh oh!

jonpryor commented May 24, 2017

Uh oh!

jonpryor commented May 24, 2017

Uh oh!

jonpryor commented May 24, 2017

Uh oh!

jonpryor commented May 25, 2017

Uh oh!

jonpryor commented May 25, 2017

Uh oh!

jonpryor commented May 25, 2017

Uh oh!

jonpryor commented May 27, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Bump to mono/2017-04/dbb63b19 #600

Bump to mono/2017-04/dbb63b19 #600

Uh oh!

Conversation

jonpryor commented May 22, 2017

Uh oh!

jonpryor commented May 24, 2017

Uh oh!

jonpryor commented May 24, 2017

Uh oh!

jonpryor commented May 24, 2017

Uh oh!

jonpryor commented May 25, 2017

Uh oh!

jonpryor commented May 25, 2017

Uh oh!

jonpryor commented May 25, 2017

Uh oh!

jonpryor commented May 27, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants