-
Notifications
You must be signed in to change notification settings - Fork 682
Description
Given recent developments of harfbuzz, the helpfulness of more CI bots is at least proved to me so I like to see the addition of more environments to harfbuzz CI.
In nutshell:
- Android, as the issue on PAGE_SIZE in hb-set-private.hh collides with Android NDK asm/page.h PAGE_SIZE macro #576 (done, with much more, [ci] Add CircleCI for cross-compiling #592)
- FreeBSD/OpenBSD/..., as unbreak on BSD where the major() function is defined #577 (done, [ci] Add FreeBSD #595)
- GCC 4.x, as harfbuzz 1.6.1 and later require C++11 #585 (somehow done with [ci] Add FreeBSD #595)
- arm-none-eabi, psvita, as Fails to build with arm-none-eabi Newlib toolchain #451, Fix arm-none-eabi build (fixes #451) #496, Unbreak arm-none-eabi build again #514, http://vitasdk.org,
cmake .. -DCMAKE_TOOLCHAIN_FILE=$VITASDK/share/vita.toolchain.cmake && make(done, Enable PSVita (arm-none-eabi) compile again and add it to CI #594)
Not aware of how this particular one can be useful but after #576 I thought it would be nice if we could have Android build on our CI. With cmake this command can be accomplish that easily if ndk is installed:
mkdir build && cd build && cmake -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=armeabi-v7a ..
but this is unable to reproduce the very issue reported on #576. Does this seem correct and does it worth to be added to our CI or we can do some autotools based ones instead? We are also not doing cmake build testing on Travis (but on Windows CI, Appveyor) as our Travis config is very autotools oriented, how about adding a third CI just for cmake and Android CI, like CircleCI?
Also a *bsd bot can be considered nice as #577, I've aggregated some solutions for it here, is there any better one?
Also per #585, it would be nice if we could have some old GCC environment to test also.