Bump to llvm/master/bdb3a116 #1211
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jonpryor
added
the
full-mono-integration-build
|
The macOS+xbuild PR Build is failing because something is seriously b0rked: we're only partially building the Debug configuration. For example, the log file contains: Compare to Release binaries: Similarly weird, we're building We're not adding the Debug versions, because they don't exist. The question is, why?! |
From the log file (newlines added for readability): This is where we build Oops. So now we have a better On the one hand, we dearly need better error handling in our build process. We basically have errors being ignored, resulting in more obscure build errors later on. :-/ On the other hand...WTF is going on in the mono build that Searching backwards...it gets weirder. The build for We sign it without error: We build But the Somehow, between the build of WTF? |
|
A rebuild, with no PR changes, resulted in a successful build. |
|
@pjcollins: Do you want to test the built |
|
@jonpryor yes sounds good, I will take a look today. |
|
@jonpryor the OSS vsix you've linked above works for my failing case, I am happy to merge this. |
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jan 23, 2018
Context: dotnet#1211 (comment) Context: dotnet#1211 (comment) What *should* happen when a portion of a build fails? That's not entirely rhetorical: the *entire* build should fail. What *does* happen when a portion of a build fails? Unfortunately that's also not rhetorical: the build continues! (Say what?!) Case in point: [PR dotnet#1211 build 2373][pr-2373], which experienced a failure in the mono build: [pr-2373]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/2373/ MONO_PATH="./../../class/lib/build:$MONO_PATH" ... -R ../../../class/lib/monodroid/nunitlite.dll ... error CS0009: Metadata file '/Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/external/mono/mcs/class/lib/monodroid/nunitlite.dll' could not be opened -- PE image doesn't contain managed metadata. *But the error was ignored*, and the build continued, resulting in the "final" errors (among others) System.Net/NetworkChangeTest.cs(5,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? **This is *madness*.** The first error *should* have stopped the build. The build *wasn't* stopped, meaning that it continued -- with an "unstable" tree state -- resulting in "bizarre" build errors *later*. In particular, `Xamarin.Android.NUniteLite.dll` wasn't built in the *Debug* configuration because the *mono* build failed for the Debug configuration, but everything "worked" in Release. The fundamental cause of this madness? Makefile rules such as `make leeroy-all`, which *effectively* are: tools/scripts/xabuild Xamarin.Android.sln /p:Configuration=Debug ; \ tools/scripts/xabuild Xamarin.Android.sln /p:Configuration=Release; \ *Because* of the `;` separating the commands, any errors from the first command are *ignored*, resulting in the tearing out of my hair when everything goes "weird". Review the Makefile targets in `Makefile` and `build-tools/scripts/BuildEverything.mk` and replace `;` with `|| exit 1` when the command should have fatal errors. This *should* cause the build to fail the *first* time an error is encountered, instead of continuing on its merry way to die horribly later.
jonpryor
added a commit
that referenced
this pull request
Jan 24, 2018
Context: #1211 (comment) Context: #1211 (comment) What *should* happen when a portion of a build fails? That's not entirely rhetorical: the *entire* build should fail. What *does* happen when a portion of a build fails? Unfortunately that's also not rhetorical: the build continues! (Say what?!) Case in point: [PR #1211 build 2373][pr-2373], which experienced a failure in the mono build: [pr-2373]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/2373/ MONO_PATH="./../../class/lib/build:$MONO_PATH" ... -R ../../../class/lib/monodroid/nunitlite.dll ... error CS0009: Metadata file '/Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/external/mono/mcs/class/lib/monodroid/nunitlite.dll' could not be opened -- PE image doesn't contain managed metadata. *But the error was ignored*, and the build continued, resulting in the "final" errors (among others) System.Net/NetworkChangeTest.cs(5,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? **This is *madness*.** The first error *should* have stopped the build. The build *wasn't* stopped, meaning that it continued -- with an "unstable" tree state -- resulting in "bizarre" build errors *later*. In particular, `Xamarin.Android.NUniteLite.dll` wasn't built in the *Debug* configuration because the *mono* build failed for the Debug configuration, but everything "worked" in Release. The fundamental cause of this madness? Makefile rules such as `make leeroy-all`, which *effectively* are: tools/scripts/xabuild Xamarin.Android.sln /p:Configuration=Debug ; \ tools/scripts/xabuild Xamarin.Android.sln /p:Configuration=Release; \ *Because* of the `;` separating the commands, any errors from the first command are *ignored*, resulting in the tearing out of my hair when everything goes "weird". Review the Makefile targets in `Makefile` and `build-tools/scripts/BuildEverything.mk` and replace `;` with `|| exit 1` when the command should have fatal errors. This *should* cause the build to fail the *first* time an error is encountered, instead of continuing on its merry way to die horribly later.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: #1182