Skip to content

Conversation

@jonpryor
Copy link
Contributor

Context: #162

PR #162 tries to use the mono bundle (fbfd676) to avoid rebuilding
mono on subsequent builds (when the mono commit hasn't changed), in
order to speed up the Jenkins build process (currently tracking at
~3.5 hours for a non-PR build...)

PR #162 currently fails when building src/monodroid:

Executing: /Users/builder/android-toolchain/ndk/ndk-build CONFIGURATION=Debug NDK_LIBS_OUT=./libs/Debug NDK_OUT=./obj/Debug V=1
...
[armeabi-v7a] Compile thumb  : monodroid <= nl.c
/Users/builder/android-toolchain/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o.d -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib/src -Ijni/../../../external/mono/eglib/src -Ijni/zip -Ijni -DANDROID -ggdb3 -O0 -fno-omit-frame-pointer -std=c99 -DHAVE_LINUX_NETLINK_H=1 -DHAVE_LINUX_RTNETLINK_H=1 -D_REENTRANT -DPLATFORM_ANDROID -DANDROID -DLINUX -Dlinux -D__linux_ -DHAVE_CONFIG_H -DJI_DLL_EXPORT -DMONO_DLL_EXPORT -I/libmonodroid/zip -I/include -I/include/eglib -mandroid -fno-strict-aliasing -ffunction-sections -fomit-frame-pointer -funswitch-loops -finline-limit=300 -fvisibility=hidden -fstack-protector -Wa,--noexecstack -Wformat -Werror=format-security -DDEBUG=1 -Wa,--noexecstack -Wformat -Werror=format-security    -isystem /Users/builder/android-toolchain/ndk/platforms/android-9/arch-arm/usr/include -c  jni/../../../external/mono/support/nl.c -o ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o
In file included from jni/../../../external/mono/support/nl.h:3:0,
                 from jni/../../../external/mono/support/nl.c:14:
jni/../../../external/mono/eglib/src/glib.h:18:26: fatal error: eglib-config.h: No such file or directory
 #include <eglib-config.h>
                          ^
compilation terminated.

src/monodroid fails to build because it requires build artifacts
located in
build-tools/mono-runtimes/obj/$(Configuration)/%(Identity)/eglib,
which doesn't exist when the mono bundle is being used (because we
never built mono! by design!)

Fix this issue by updating the _InstallRuntimes target in
mono-runtimes.targets to copy the generated eglib header files into
bin/$(Configuration)/include/%(Identity)/eglib, and update
bundle.targets so that the include directory is also included in
the mono bundle.

This should allow a future PR #162 fix to build, as all required
generated files will be present within the bundle.

Context: dotnet#162

PR dotnet#162 tries to use the mono bundle (fbfd676) to avoid rebuilding
mono on subsequent builds (when the mono commit hasn't changed), in
order to speed up the Jenkins build process (currently tracking at
~3.5 *hours* for a non-PR build...)

[PR dotnet#162 currently fails][0] when building `src/monodroid`:

	Executing: /Users/builder/android-toolchain/ndk/ndk-build CONFIGURATION=Debug NDK_LIBS_OUT=./libs/Debug NDK_OUT=./obj/Debug V=1
	...
	[armeabi-v7a] Compile thumb  : monodroid <= nl.c
	/Users/builder/android-toolchain/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o.d -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib/src -Ijni/../../../external/mono/eglib/src -Ijni/zip -Ijni -DANDROID -ggdb3 -O0 -fno-omit-frame-pointer -std=c99 -DHAVE_LINUX_NETLINK_H=1 -DHAVE_LINUX_RTNETLINK_H=1 -D_REENTRANT -DPLATFORM_ANDROID -DANDROID -DLINUX -Dlinux -D__linux_ -DHAVE_CONFIG_H -DJI_DLL_EXPORT -DMONO_DLL_EXPORT -I/libmonodroid/zip -I/include -I/include/eglib -mandroid -fno-strict-aliasing -ffunction-sections -fomit-frame-pointer -funswitch-loops -finline-limit=300 -fvisibility=hidden -fstack-protector -Wa,--noexecstack -Wformat -Werror=format-security -DDEBUG=1 -Wa,--noexecstack -Wformat -Werror=format-security    -isystem /Users/builder/android-toolchain/ndk/platforms/android-9/arch-arm/usr/include -c  jni/../../../external/mono/support/nl.c -o ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o
	In file included from jni/../../../external/mono/support/nl.h:3:0,
	                 from jni/../../../external/mono/support/nl.c:14:
	jni/../../../external/mono/eglib/src/glib.h:18:26: fatal error: eglib-config.h: No such file or directory
	 #include <eglib-config.h>
	                          ^
	compilation terminated.

`src/monodroid` fails to build because it requires build artifacts
located in
`build-tools/mono-runtimes/obj/$(Configuration)/%(Identity)/eglib`,
which doesn't exist when the mono bundle is being used (because we
never built mono!)

Fix this issue by updating the `_InstallRuntimes` target in
`mono-runtimes.targets` to copy the generated eglib header files into
`bin/$(Configuration)/include/%(Identity)/eglib`, and update
`bundle.targets` so that the `include` directory is also included in
the mono bundle.

This should allow a future PR dotnet#162 fix to build, as all required
generated files will be present within the bundle.

Additionally, add the `$(HostOS)` and a version number to the bundle
filename, now `-v1`, to note that the structure of the bundle has
changed, *without* a corresponding mono, llvm, or libzip commit bump.

[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/61/
@jonpryor jonpryor force-pushed the jonp-install-include branch from a7ea726 to 3118e83 Compare August 14, 2016 12:28
@jonpryor jonpryor merged commit 73b7e8e into dotnet:master Aug 14, 2016
radekdoulik pushed a commit to radekdoulik/xamarin-android that referenced this pull request Aug 18, 2016
)

Context: dotnet#162

PR dotnet#162 tries to use the mono bundle (fbfd676) to avoid rebuilding
mono on subsequent builds (when the mono commit hasn't changed), in
order to speed up the Jenkins build process (currently tracking at
~3.5 *hours* for a non-PR build...)

[PR dotnet#162 currently fails][0] when building `src/monodroid`:

	Executing: /Users/builder/android-toolchain/ndk/ndk-build CONFIGURATION=Debug NDK_LIBS_OUT=./libs/Debug NDK_OUT=./obj/Debug V=1
	...
	[armeabi-v7a] Compile thumb  : monodroid <= nl.c
	/Users/builder/android-toolchain/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o.d -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib/src -Ijni/../../../external/mono/eglib/src -Ijni/zip -Ijni -DANDROID -ggdb3 -O0 -fno-omit-frame-pointer -std=c99 -DHAVE_LINUX_NETLINK_H=1 -DHAVE_LINUX_RTNETLINK_H=1 -D_REENTRANT -DPLATFORM_ANDROID -DANDROID -DLINUX -Dlinux -D__linux_ -DHAVE_CONFIG_H -DJI_DLL_EXPORT -DMONO_DLL_EXPORT -I/libmonodroid/zip -I/include -I/include/eglib -mandroid -fno-strict-aliasing -ffunction-sections -fomit-frame-pointer -funswitch-loops -finline-limit=300 -fvisibility=hidden -fstack-protector -Wa,--noexecstack -Wformat -Werror=format-security -DDEBUG=1 -Wa,--noexecstack -Wformat -Werror=format-security    -isystem /Users/builder/android-toolchain/ndk/platforms/android-9/arch-arm/usr/include -c  jni/../../../external/mono/support/nl.c -o ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o
	In file included from jni/../../../external/mono/support/nl.h:3:0,
	                 from jni/../../../external/mono/support/nl.c:14:
	jni/../../../external/mono/eglib/src/glib.h:18:26: fatal error: eglib-config.h: No such file or directory
	 #include <eglib-config.h>
	                          ^
	compilation terminated.

`src/monodroid` fails to build because it requires build artifacts
located in
`build-tools/mono-runtimes/obj/$(Configuration)/%(Identity)/eglib`,
which doesn't exist when the mono bundle is being used (because we
never built mono!)

Fix this issue by updating the `_InstallRuntimes` target in
`mono-runtimes.targets` to copy the generated eglib header files into
`bin/$(Configuration)/include/%(Identity)/eglib`, and update
`bundle.targets` so that the `include` directory is also included in
the mono bundle.

This should allow a future PR dotnet#162 fix to build, as all required
generated files will be present within the bundle.

Additionally, add the `$(HostOS)` and a version number to the bundle
filename, now `-v1`, to note that the structure of the bundle has
changed, *without* a corresponding mono, llvm, or libzip commit bump.

[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/61/
radical pushed a commit that referenced this pull request May 8, 2018
Until now, we (well, I) had been patient to deal with methodmap enumification
which *requires* distinction between class and interface by adding
"[Interface]" mark on interfaces. It was just to distinguish "class" and
"interface" elements under "package" element.

But... why do we need that? Performance? The impact should be actually
trivial. It can be just anything, we identify an element by @name.

On the other hand, it is very annoying to exactly specify "class" or
"interface" very carefully, because if I make a mistake then the mapping
results in a warning that then I have to carefully check.

Just reduce such chances for errors by requiring less-error-prone XPath.
It should save everyone.
@github-actions github-actions bot locked and limited conversation to collaborators Feb 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants