customizability #1869
customizability #1869
Conversation
|
Thanks, it does look very interesting and the options seem reasonably named! Please don't be discouraged but looking at it I still have to ask: I'm wondering, how common is it to use additional Java libraries? For me Cython, C or pyjnius always seemed like the obvious options. I'm asking because it does appear to add a medium amount of complexity to the gradle file and some options that aren't immediately obvious to someone not familiar with the ecosystem like me (and I imagine other people helping out with p4a) and I think there is some benefit in keeping things simple Also related to that, what does the app theme do other than change the title bar? Or is that only relevant if using Java libraries for UI? (If yes, then again I'm wondering if that is actually a thing many p4a users actually do and if that is worth adding) Edit: an additional question just came to mind: what is with kotlin compatibility levels, would they need separate options? (Since that seems to be the thing Google recommends over java now) |
|
Thanks for your answer! as you mentioned pyjnius is the obvious way to call into java, that is right. These options help to integrate java/kotlin libraries that can be called via jnius. We tried different ways to do that, one was a service_only bootstrap which worked out fine but involves installation of two different apk's and twice acquiring permissions (for frontend and backend). These requirements involved the integration of a set of java dependencies (that is already provided by the p4a-option --depend and others). The integration of the Kotlin-based Activity made it necessary to set a different AppTheme (the one from the native activity) in the AndroidManifest, otherwise the gradle build fails with a clash in merging the manifest of the .aar and the one of the p4a toolchain. To the question "what is with kotlin compatibility levels": I have not found any seperate option for this, I have written the native activity in kotlin and it was sufficient to provide the kotlin runtime dependencies. The bottom line is that these additions help out in projects where p4a is used as a backend for a native UI. I hope I could point out the use of these additional options fitting to the options already implemented for integration of java/kotlin dependencies. I you are interested I can provide an example that showcases the native UI with a p4a backend. As I have seen this could also be seen as an answer to this old question on reddit |
At least it gives the p4a user the option to do it, thus yes, it's worth it. If it's then used by many p4a users is not really predictable. The Approach of including native UI parts as aar (or any other lib) has some going for it and the changes are not immersive, the "keep it simple" argument feels a little misplaced. |
|
Edit: to put this up front: I'm not opposed to a merge, so please don't be angry 😱 but I just found it worth considering this particular point explained below. Please feel free to ignore this @ anyone who wants to go ahead and just merge this
I feel like we spend a lot of time on removing options, like pygame bootstrap, at some point soon we might deprecate python 2, and maybe the launcher will at some point become an external thing (at least I suggested that.) This doesn't seem like a huge addition so forgive me that I go on so much about this, if the others feel like this is worth merging I won't stand in the way for sure, but it is a road to hell paved with good intentions to just put in all options just because 1-2 users would use it
Well I hoped there were some known other users asking for it. I have never seen any, hence my question. And it doesn't seem that obvious to me to do, since if you want to get that deep into java APIs, you're bound to get into a painful clashing area at some point - wouldn't most just write a Java app then? (I don't know the answer, I'm just posing the question)
Maybe. It is a simple addition after all. But I asked it (and would do so again) because this did strike me as a particular addition that seems quite niche and possibly outside of what most p4a users would do. Maybe I am wrong, but that was just my impression so hence the question. It wasn't my intention to block this, but just to bring up something worth considering if anyone else possibly felt the same way |
Pygame bootstrap is legacy, python2 is EOL, both have full featured replacements. These can safely be deprecated/removed without regression. Removing options would be something different.
Your're right. But i don't get the mood about keeping a simple change out just because it might be used only by a minority of users. With the same argument probably most of the addon recipes would be obsolete. Isn't the goal of a library/framework to be a tool and serve a broad spectrum of usecases? |
no worries, nobody is angry ! I think p4a is more than just a compatibility layer for Kivy. It brings the strength of Python which is not just the language per se, but also parts of it's ecosystem through recipes. As I have already stated above there are situations where I need a native UI and can now have the best of two worlds. I have put together a simple demonstrator that shows how to integrate a kotlin based activity into a kivy/p4a app and let it communicate via websockets with the python service. |
For me personally the reason is in part because the gradle part has given me some headaches in particular, so I don't think the cost of making it more complex for the future is zero. So I'm not a fan of increasing the complexity of it "just to have more options", personally, unless these are also useful for at least a somewhat significant amount of people and this change here just seems particularly niche to me. But maybe let's hear the opinions of someone else like @AndreMiras or @inclement ?
I suppose you could argue that, but the recipes are outside of the core source and don't impact anything else, e.g. they also don't complicate debugging the gradle part or things like that so for me that is not the same thing
Yes! But IMHO it's still worth being careful, because there is always a trade-off |
|
First of all thanks for spending time investigating and contributing with that PR @zworkb. I'm usually very cautious/fearful when touching the core specially when dealing with a niche use-case indeed. So yes I'm a bit like @Jonast here, but of course it doesn't mean that I don't want to review/merge. Thanks again, I'll try to make some time reviewing it this week |
There was a problem hiding this comment.
Overall, my thoughts that I strongly support merging something to make this possible, because it all seems like very reasonable stuff to do even if it's niche, and for the most part there isn't any simple alternative.
The main issue raised is how niche this is. For the most part that doesn't worry me too much here, because the templating is so simple, and actually I think that's what we should focus on - if we simply support a simple but consistent set of user template changes, I believe that's okay for maintainability (since users mostly bear the burden of making their template additions work) but great for flexibility (since anything can be added by user template).
There's more than one way to draw the line. For instance, we could simply have an option to pass in a build.gradle that overrides the built in one, thereby putting all the burden of compatibility on the p4a user.
I think a good middle ground here is to have some slightly more generic templating options than currently in the PR:
--add-gradle-repositoryseems okay, this is a pretty generic option with a nice simple implementation--packaging-optionsseems okay, again it's a straightforward list with a clear translation into the gradle file. It could be made even simpler by just having a generic 'extra gradle stuff' template where the user can provide it all themselves, but the use of packagingOptions seems clear enough to me.--java-source-compatand--java-taget-compat: I think these would be better as another list--compile-optionswhere the user provides the full text of every option. This would be simple and more consistent with the other arguments.
With those minor comments, I think all of these are good additions that don't add a significant burden.
For AndroidManifest it's a little more complex since there isn't a central template, but again I think the additions are straightforward enough. Importantly, I don't think there's any real alternative that wouldn't be much more complicated. I'd like to improve the implementation by bringing the defaults out as constants rather than just appearing in the argument definitions, but that's a minor tweak.
This is probably a bit rambling because I wrote it all at once while taking an overview of the code. t;dr: I believe we should add these features (with minor tweaks) because 1) they're reasonable things to do with no good alternative, 2) I think the implementations are straightforward and will easily make sense even to people not actually using the feature.
|
|
||
| ap.add_argument('--android-entrypoint', dest='android_entrypoint', | ||
| default='org.kivy.android.PythonActivity', | ||
| help='defines which java class sill be used for startup, usually a subclass of PythonActivity') |
There was a problem hiding this comment.
Minor: typo "sill" for "will"
There was a problem hiding this comment.
Also the help strings should start with a capital letter for consistency.
| @@ -665,6 +665,30 @@ def parse_args(args=None): | |||
| 'https://developer.android.com/guide/' | |||
| 'topics/manifest/' | |||
| 'activity-element.html')) | |||
|
|
|||
| ap.add_argument('--android-entrypoint', dest='android_entrypoint', | |||
There was a problem hiding this comment.
This one seems fine, I don't think we could support the same thing any other way with such a simple api.
Minor: I'd probably pull out the 'org.kivy.android.PythonActivity' to a constant declaration somewhere.
| ap.add_argument('--android-entrypoint', dest='android_entrypoint', | ||
| default='org.kivy.android.PythonActivity', | ||
| help='defines which java class sill be used for startup, usually a subclass of PythonActivity') | ||
| ap.add_argument('--android-apptheme', dest='android_apptheme', |
There was a problem hiding this comment.
As with the android entrypoint, this seems okay (albeit even more niche), it's a very simple option and there's no simple alternative.
| ap.add_argument('--android-apptheme', dest='android_apptheme', | ||
| default='@android:style/Theme.NoTitleBar', | ||
| help='defines which app theme should be selected for the main activity') | ||
| ap.add_argument('--add-java-source-compat', dest='java_source_compat', |
There was a problem hiding this comment.
I don't like source compat and target compat options so much, see main comment.
There was a problem hiding this comment.
as suggested I introduced --add-compile-option
| @@ -54,7 +54,7 @@ | |||
| <application android:label="@string/app_name" | |||
| android:icon="@drawable/icon" | |||
| android:allowBackup="{{ args.allow_backup }}" | |||
| android:theme="@android:style/Theme.NoTitleBar{% if not args.window %}.Fullscreen{% endif %}" | |||
| android:theme="{{args.android_apptheme}}{% if not args.window %}.Fullscreen{% endif %}" | |||
There was a problem hiding this comment.
Mildly awkward here that only the sdl2 AndroidManifest is changed - I guess this should be implemented in every bootstrap?
There was a problem hiding this comment.
i did that now also for the other bootstraps
| @@ -13,68 +13,85 @@ allprojects { | |||
| repositories { | |||
There was a problem hiding this comment.
The changes here are much more minimal than I thought at first glance, due to the indentation changes.
|
And further to that, thanks very much @zworkb for raising these thoughtful additions, I'm glad p4a was flexible enough to let you get this working. |
|
thanks @inclement for your comment and suggestions. |
@inclement I have now implemented all your suggestions, so the PR should be ready for merging. Again thanks for your support! |
| ap.add_argument('--android-apptheme', dest='android_apptheme', | ||
| default='@android:style/Theme.NoTitleBar', | ||
| help='Defines which app theme should be selected for the main activity') | ||
| ap.add_argument('--add-compile-option', dest='compile_options', default=[], |
There was a problem hiding this comment.
no, its no typo, its a parameter thats adds a single option to a list of options (action='append')
* customizability options - added compile-options * apptheme option for all bootstraps
* [recipes] Fix compilation for regex recipe The error was: build/other_builds/hostpython3/desktop/hostpython3/Include/Python.h:39:19: fatal error: crypt.h: No such file or directory * [recipes] Update regex's recipe * put the sdk manager command in a code block (#1956) to avoid quotes being replaced by fancy ones * Updated version number for develop branch following 2019.08.09 release (#1960) * Fix build for case-insensitive FS and add CI test for OSX (#1951) * [python] Fix build for case-insensitive FS 🍎 It turns out that the generated python binary for some builds are named `python.exe` instead of `python`. This depends on the File System where the build happens. It will be named `python.exe` when the FS is case-insensitive (Mac OSX and Cygwin), but it will be named `python` when the FS is case-sensitive (most GNU Linux distributions). The proposed solution consists in make a copy of the generated python binary with a given name (python3 or python2) so this way To achieve this goal we refactor a little our `HostPythonRecipe`: - add private property `HostPythonRecipe._exe_name` (the name of the python executable based on major version) - add public property `HostPythonRecipe.python_exe` (the full path of the python executable) - implement `HostPythonRecipe.should_build` And also it's affected the `GuestPythonRecipe`, because we need to use the generated python executable by `HostPythonRecipe`: - add private property `GuestPythonRecipe._libpython` (python's library name with extension...hardcoded for now...) - implement `GuestPythonRecipe.should_build`... to check the library instead of the executable so we avoid conflicts with case-insensitive FS We also need: - fix `PythonRecipe.real_hostpython_location` because the name of our host python executable will depend on major version - fix python2 interpreter (fix-interpreter-version.patch) Note: the variation of the name of the python's executable is mentioned at python's build docs (https://github.com/python/cpython/blob/3.7/README.rst#build-instructions) Note: @TheSin- , ¡¡¡thanks for your debugging sessions!!! * [ci] Add Mac OSX CI's test & refactor android's NDK/SDK installation To do so we: - create a makefile to install the necessary dependencies for Mac OS X: `ci/makefiles/osx.mk` - create a makefile to install android's SDK/NDK: `ci/makefiles/android.mk` - refactor docker files: make use of android's makefile - change OS, from `linux` to `osx`, for CI test `Python 3 armeabi-v7a`, so we don't increase the overall build time and jobs - rename the `Python 2` test to `Python 2 armeabi-v7a (with numpy)` to reflect the build arch and numpy's build. * customizability (#1869) * customizability options - added compile-options * apptheme option for all bootstraps * Initial migration to NDK r19 (Part I - The core) (#1722) * [ndk19] Rework of the arch environment to work with ndk r19+ Things done here: - Modifies target so we can use the toolchains `in-place` (as if we were using a standalone toolchain) - Removes some cflags that we don't need anymore - Move `macros` and `includes` from `CFLAGS` to `CPPFLAGS` (because this is the way it's supposed to be) - Move libraries from `LDFLAGS` to `LDLIBS` (again, the same as above) - Refactor `Arch`'s variables into class attributes, to make `get_env` smaller and to be more readable/maintainable: + class attributes for flags: * common_cflags * common_cppflags * common_ldflags * common_ldlibs * common_ldshared * arch_cflags + class attributes for compiler: * clang_path * clang_exe * clang_exe_cxx - Remove hardcoded cpu count in `MAKE` - Remove `gcc` of environment (because it has been partially removed in ndk r18) - Shorten long line to be pep8 friendly (line where we define env['BUILDLIB_PATH']) - Commented lines for `ArchAarch_64` that it seems tha we don't need anymore (not removed because I'm not sure if we need them) Note: This will force us to use a minimal ndk version of 19 See also: https://developer.android.com/ndk/guides/other_build_systems * [ndk19] Update `test_archs` to ndk's r19+ build system Also add some more tests. Now we check if some of the functions we mock, `glob` and `find_executable`, are called with the expected arguments * [ndk19] Update `test_bootstrap` to ndk's r19+ build system Because `clang` is the new default compiler and the affected tests were made thinking in `gcc` compiler * [ndk19] Remove `clang` of `get_recipe_env` Because as per ndk r19 the default compiler is clang and gcc has been partially removed * [ndk19] Adapt python recipes to ndk's r19+ build system We move python recipe to use a minimal ndk version of 19 because it will simplify the python's cross compilation (this way we can remove some environment variables that we don't need anymore). The only side effect detected is that the python's `zlib` module isn't built anymore. This is caused because python3 and python2 build systems contains libz's hardcoded version, which does not match the version used in ndk 19 (may be this the cause of some `zip/unzip` errors reported in python-for-android's issues?). We will take care later of this zlib problem, or we will get a runtime crash...so it seems that zlib is an `essential module` to successfully run a python-for-android app * [ndk19] Update libffi to version post `v3.3RC0` and adapt it to be ndk r19+ compatible * [ndk19] Fix build of python's zlib module Because python has a hardcoded zlib version which does not match android's ndk r19, and that prevents the build of zlib's module Note: it seems that we have to point to the right lib and headers, otherwise we won't succeed in building python's zlib module * [ndk19] Fix build of python2's _ctypes module for ndk r19+ * [ndk19] Fix numpy for ndk r19+ Note: because of the new build system recently introduced, we can safely remove some of the patches that we needed because it seems that it builds and runs fine without them * [ndk19] Update docs with the new ndk requirements * [ndk19] Set min/max/recommended android's NDK * [ndk19] Make CI tests with android's NDK `r19b` Because it's our minimum supported android NDK * [ndk19] Fix png recipe for NDK r19+ We remove `get_recipe_env` because we don't need anymore to specify the flags set in there. Note: As per new NDK r19+ build system implemented in p4a, the removed `flags` should be automatically set by the android's NDK * [ndk19] Add `-fPIC` to `armeabi-v7a`'s arch cflags... ...force `Position-Independent Code` To solve the kivy's build error detected in travis `OSX` test (https://travis-ci.org/kivy/python-for-android/jobs/576204088#L1105). But also detected the same error in my local tests (linux os in this case) for `freetype` and `harfbuzz` recipes...so I have the feeling that this is better to set as global 🤞..is it? * [LIBS - PART I] Initial refactor of library recipes (#1944) This commit will introduce a new cls attribute: `built_libraries`. This `built_libraries` attribute must be a dictionary. The keys are the full library name, e.g.: `libffi.so`. And the values must be the relative path of the library, e.g: `.libs`. So the this cls attribute for libffi recipe it would look like: ```built_libraries = {'libffi.so': '.libs'}``` This new cls attribute will allow us to detect library recipes and to refactor common operations that we do for those kind of recipes: - copy library into right location - implement `should_build` for library recipes Those two things will make that our rebuilds to be more consistent and I hope that it will be easier to maintain. **So, once explained a little this PR, in here we do:** - [x] Add attribute `built_libraries` - [x] Add methods to refactor common library operations: - [x] install_libraries - [x] get_libraries - [x] implement `should_build` for library recipes - [x] implement basic tests for the newly introduced `Recipe` methods - [x] Make use of those Library attributes/methods for some basic set of recipes: - [x] libffi - [x] openssl - [x] png - [x] jpeg - [x] freetype - [x] harfbuzz - [x] libcurl - [x] libzbar - [x] libiconv - [x] libexpat - [x] libogg - [x] libxml2 - [x] libxslt - [x] libshine - [x] libx264 - [x] libglob - [x] libsodium - [x] libsecp256k1 **Things to do in separate PRs**, to be easy to review and because those points will start to conflict with the `NDK r19 migration` thing just merged: - Make use of Library attributes/methods introduced in this PR for un covered library recipes in here. Here we have two situations: - library recipes that depends on android's STL library (almost all the work done in here will depend of the `NDK r19 migration` thing) - all remaining library recipes, which are not STL lib dependent and that are not implemented in here (because I was unable to perform a successful build with them using arch `arm64-v8a`...so I think it would be better to deal with those recipes in separate PRs and later...with the `NDK r19 migration` thing merged) **Notes about changed recipes:** all the recipes touched in here almost have the same changes: - remove `should_build` method (to make use of the one implemented in base class for library recipes) - remove the copy of the library (because that will be done automatically by the method `install_libraries` implemented in base class) - fixed the imports due to refactoring * [recipe-lib] Add attribute Recipe.built_libraries so we can refactor some essential operations performed for library recipes (like copy the library into the right location, or decide if we should build the library recipe again) * [recipe-lib] Add method Recipe.get_libraries This function will allows us to get a list of the built/context libraries. This will be useful to check if we have to built a library recipe or which library should be rebuild * [recipe-lib] Make `Recipe.should_build` decide the library build In case that the attribute built_libraries has been set, we will check the need of the recipe build, otherwise we will act as usual, forcing the build unless overwrote in subclass * [recipe-lib] Add method `Recipe.install_libraries` So we can: - control the copy of the library recipe - refactor the install of the lib for all library recipes * [recipe-lib] Make libffi a library recipe * [recipe-lib] Make openssl a library recipe and ... also make the imports from the right module * [recipe-lib] Make png a library recipe * [recipe-lib] Make jpeg a library recipe * [recipe-lib] Make freetype a library recipe and ... also make the imports from the right module * [recipe-lib] Make harfbuzz a library recipe and ... also make the imports from the right module * [recipe-lib] Make libcurl a library recipe and ... also make the imports from the right module * [recipe-lib] Make libzbar a library recipe and ... also make the imports from the right module * [recipe-lib] Make libiconv a library recipe and ... also make the imports from the right module * [recipe-lib] Make libexpat a library recipe and ... also: - make the imports from the right module - remove hardcoded arch * [recipe-lib] Make libogg a library recipe * [recipe-lib] Make libxml2 a library recipe and ... also make the imports from the right module * [recipe-lib] Make libxslt a library recipe and ... also make the imports from the right module * [recipe-lib] Make libshine a library recipe and ... also: - make the imports from the right module - remove the hardcoded cpu count when compiling * [recipe-lib] Make libx264 a library recipe and ... also: - make the imports from the right module - remove the hardcoded cpu count when compiling * [recipe-lib] Make libglob a library recipe * [recipe-lib] Make libsodium a library recipe and ... also: - make the imports from the right module - fix hardcoded arch - enable cpu count when compiling * [recipe-lib] Make libsecp256k1 a library recipe and ... also make the imports from the right module * [tests] Add tests for library recipe * [NDK19] Fix libglob for android NDK r19 - change the `ARG_MAX` define, because it's already defined at `sysroot/usr/include/linux/limits.h` - Replaced `size_t` by Including the <stddef.h> header. Because found the solution at stackoverflow: As per C99, §7.17, size_t is not a builtin type but defined in <stddef.h> See also: - https://travis-ci.org/kivy/python-for-android/jobs/576392711#L5992-L6013 - https://stackoverflow.com/questions/26410466/gcc-linaro-compiler-throws-error-unknown-type-name-size-t * [NDK19] Remove `--sysroot` from LDFLAGS for cffi and pymunk (#1965) Because `--sysroot` flag is not needed anymore and make it fails the build since we migrated to new android's build system (implemented in NDK r19) See also: - https://developer.android.com/ndk/guides/other_build_systems * Added libffi headers troubleshooting note to doc (#1972) * [LIBS - PART II] Part II of NDK r19 migration - Initial STL lib migration (#1947) * [recipe-stl] Add android's STL lib support to `Recipe` To allow us to refactor some common operations that we use in our recipes that depends on android's STL library. Note: This commit will allow us to begin the migration to `c++_shared`. This is a must when we move to android's NDK r19+, because as for android NDK >= 18 is the only one supported STL library. * [recipe-stl] Make CppCompiledComponentsPythonRecipe use Recipe's STL support * [recipe-stl] Make icu a library recipe with STL support (rework) Also done here: - Remove hardcoded version in url - Disable versioned shared libraries - Make it to be build as a shared libraries (instead of static) - Disable the build of static libraries (because we build them as shared ones, so we avoid to link with them without our consents) - Shorten long lines to be pep8's friendly - Remove icu from ci/constants - Remove `RuntimeError` about the need to use NDK api <= 19 (because that is not the case anymore) - consider host's number of cpu to perform the build * [recipe-stl] Rework pyicu recipe to match latest icu changes Also done here: - Remove icu.patch because now we don't have the version in our icu libraries - Shorten long lines to be pep8's friendly * [tests] Add tests for recipe with STL support * [tests] Add tests for icu recipe * [tests] Add tests for pyicu recipe * [WIP][LIBS - PART III] Rework of pyleveldb, leveldb and snappy (#1966) * [recipe-lib] Make snappy a library recipe * [recipe-stl] Make leveldb a library recipe and... make it work with the reworked snappy recipe * [recipe-stl] Fix pyleveldb for reworked leveldb/snappy * [WIP][LIBS - PART IV] Rework of shapely and libgeos (#1967) * [recipe-stl] Make libgeos a library recipe * [recipe-stl] Fix shapely for reworked libgeos * [recipe-stl] Make libzmq a library recipe (#1968) * [recipe-stl] Rework of libtorrent and boost (#1971) which: - fix build for android's NDK r19+ - allow us to build `boost+libtorrent` for any arch - Update boost to version `1.69.0` - update libtorrent to version `1.2.1` The build method needs to be changed because one of the scripts used in `boost+libtorrent` build (make-standalone-toolchain.sh), has been removed from android's NDK. [This is because](https://developer.android.com/ndk/guides/standalone_toolchain): `As of r19, the NDK's default toolchains are standalone toolchains, which renders this process unnecessary.` Note: since 3887d2b, `python-for-android` uses android's NDK r19 as the minimum supported and also changed the build method used by p4a as [described in here](https://developer.android.com/ndk/guides/other_build_systems) * Also copy the service/main.py when building with setup.py (#1936) * [recipe-stl] Rework of protobuf_cpp recipe (#1969) In here we do: - inherit from CppCompiledComponentsPythonRecipe Because depends on android's STL library - make use of the base class methods for library recipes - Split build_arch into proper methods - Shorten some long lines (to be PEP8 friendly) - make generated library shared - remove recipe from CI/constants * [CI] Fix CI's test for `arm64-v8a` (#1977) * Updated README.md to clarify NDK versions (#1981) * 📚 Updated README.dm to clarify NDK versions * 🔧 Change back to r19b * A bunch of tests for library recipes (#1982) The main idea is to test as many recipes as we can with the less code possible and without creating any file/directory so our tests can be performed as fast as possible (all this tests will only add between 2 and 3 seconds to our CI tests and will cover almost 100% of the code for each tested recipe) To do so, we create a couple of modules: tests.recipe_ctx: allow us to create a proper Context to test our recipes tests.recipe_lib_test: which holds some base classes to be used to test a recipe depending on the build method used. For starters we introduce two kind of base classes: BaseTestForMakeRecipe: To test an standard library build (this will iinclude the recipes which requires the classical build commandsconfigure/make) BaseTestForCmakeRecipe: To test an library recipe which is compiled with cmake We also refactor the existing recipes tests, so we can remove some lines in there...the ones that creates a Context. * [test] Add module `tests.recipe_ctx` A helper module to test recipes. Here we will initialize a `Context` to test recipes. * [test] Refactor `setUp/tearDown` for `test_icu` * [test] Refactor `setUp/tearDown` for `test_pyicu` * [test] Refactor `setUp` for `test_reportlab` * [test] Refactor `setUp` for `test_gevent` * [test] Add module `tests.recipe_lib_test` A helper module to test recipes which will allow to test any recipe using `configure/make` commands. * [test] Add test for `libffi` * [test] Add test for `libexpat` * [test] Add test for `libcurl` * [test] Add test for `libiconv` * [test] Add test for `libogg` * [test] Add test for `libpq` * [test] Add test for `libsecp256k1` * [test] Add test for `libshine` * [test] Add test for `libvorbis` * [test] Add test for `libx264` * [test] Add test for `libxml2` * [test] Add test for `libxslt` * [test] Add test for `png` * [test] Add test for `freetype` * [test] Add test for `harfbuzz` * [test] Add test for `openssl` * [test] Add `BaseTestForCmakeRecipe` * [test] Add test for `jpeg` and clean code We can remove the `get_recipe_env` because the environment that we use is already using a clang as default compiler (not the case when we migrated the jpeg recipe to use `cmake`)...so we can do a little refactor :) * [test] Add test for `snappy` * [test] Add test for `leveldb` * [test] Add test for `libgeos` * [test] Add test for `libmysqlclient` * [test] Add test for `openal` * [test] Make the `super` calls Python3 style * [test] Move mock tests outside context manager... Because there is no need to do it there. Also rewrote the inline comments. * Recipes tests enhancements (#1984) This is a follow up of #1982 In here we do: - Move from `__new__` to `__init__` for `BaseTestForMakeRecipe` ([discussed at here](#1982 (comment))) - Convert cls attributes to instance attributes ([discussed at here](#1982 (comment))) - Remove `mock` dependency for py3 tests (Because, as per Python 3.3+, `mock` it's a built-in-module). (Unfortunately we still will have a couple of `import mock` entries that we cannot remove until we completely remove python2 from our tests) * [test] From `__new__` to `__init__` for `BaseTestForMakeRecipe` * [test] Remove mock dependency for py3 tests Because, as per Python 3.3+, `mock` it's a built-in-module * [test] Convert cls attributes to instance attributes Because we may have some side effects without willing, considering that cls attributes are shared between instances. * Fixes test_virtualenv and test_venv failing, closes #1994 (#1995) Recent pep517 release seems to break tests. * Made p4a use per-arch dist build dirs (#1986) * Made p4a use per-arch dist build dirs * Fixed up check on existing folder when overwriting distributions * Improved Distribution.get_distribution api * Fixed test_archs.py * Fixed test_bootstrap.py * Fixed test_distribution.py * Fixed recipes tests * Fixed formatting * Made sure whole build process accesses dist_dir correctly * Fixed apk output name formatting by moving version to end of string * Further test fixes following dist_dir changes * Removed unnecessary variable * Fixes libiconv & libzbar configure host Having `--host=x86` was making the configure script fail at enabling shared library build on `x86`. This was resulting in failing to copy `libiconv.so` and `libzbar.so` on `x86` arch. * Updates Java version troubleshooting (#1991) Adds the NoClassDefFoundError XmlSchema case and groups related cases together. Gives instructions for both Ubuntu and macOS to fix. * Made on-device unit tests app use the develop branch by default (#1985) * Updated version to 2019.10.06 Co-authored-by: Pol Canelles <canellestudi@gmail.com> Co-authored-by: Gabriel Pettier <gabriel.pettier@gmail.com> Co-authored-by: Philipp Auersperg-Castell <phil@bluedynamics.com> Co-authored-by: Richard Larkin <zenkey.zencode@gmail.com> Co-authored-by: Andre Miras <AndreMiras@users.noreply.github.com>
* Release 2019.10.06 (#1998) * [recipes] Fix compilation for regex recipe The error was: build/other_builds/hostpython3/desktop/hostpython3/Include/Python.h:39:19: fatal error: crypt.h: No such file or directory * [recipes] Update regex's recipe * put the sdk manager command in a code block (#1956) to avoid quotes being replaced by fancy ones * Updated version number for develop branch following 2019.08.09 release (#1960) * Fix build for case-insensitive FS and add CI test for OSX (#1951) * [python] Fix build for case-insensitive FS 🍎 It turns out that the generated python binary for some builds are named `python.exe` instead of `python`. This depends on the File System where the build happens. It will be named `python.exe` when the FS is case-insensitive (Mac OSX and Cygwin), but it will be named `python` when the FS is case-sensitive (most GNU Linux distributions). The proposed solution consists in make a copy of the generated python binary with a given name (python3 or python2) so this way To achieve this goal we refactor a little our `HostPythonRecipe`: - add private property `HostPythonRecipe._exe_name` (the name of the python executable based on major version) - add public property `HostPythonRecipe.python_exe` (the full path of the python executable) - implement `HostPythonRecipe.should_build` And also it's affected the `GuestPythonRecipe`, because we need to use the generated python executable by `HostPythonRecipe`: - add private property `GuestPythonRecipe._libpython` (python's library name with extension...hardcoded for now...) - implement `GuestPythonRecipe.should_build`... to check the library instead of the executable so we avoid conflicts with case-insensitive FS We also need: - fix `PythonRecipe.real_hostpython_location` because the name of our host python executable will depend on major version - fix python2 interpreter (fix-interpreter-version.patch) Note: the variation of the name of the python's executable is mentioned at python's build docs (https://github.com/python/cpython/blob/3.7/README.rst#build-instructions) Note: @TheSin- , ¡¡¡thanks for your debugging sessions!!! * [ci] Add Mac OSX CI's test & refactor android's NDK/SDK installation To do so we: - create a makefile to install the necessary dependencies for Mac OS X: `ci/makefiles/osx.mk` - create a makefile to install android's SDK/NDK: `ci/makefiles/android.mk` - refactor docker files: make use of android's makefile - change OS, from `linux` to `osx`, for CI test `Python 3 armeabi-v7a`, so we don't increase the overall build time and jobs - rename the `Python 2` test to `Python 2 armeabi-v7a (with numpy)` to reflect the build arch and numpy's build. * customizability (#1869) * customizability options - added compile-options * apptheme option for all bootstraps * Initial migration to NDK r19 (Part I - The core) (#1722) * [ndk19] Rework of the arch environment to work with ndk r19+ Things done here: - Modifies target so we can use the toolchains `in-place` (as if we were using a standalone toolchain) - Removes some cflags that we don't need anymore - Move `macros` and `includes` from `CFLAGS` to `CPPFLAGS` (because this is the way it's supposed to be) - Move libraries from `LDFLAGS` to `LDLIBS` (again, the same as above) - Refactor `Arch`'s variables into class attributes, to make `get_env` smaller and to be more readable/maintainable: + class attributes for flags: * common_cflags * common_cppflags * common_ldflags * common_ldlibs * common_ldshared * arch_cflags + class attributes for compiler: * clang_path * clang_exe * clang_exe_cxx - Remove hardcoded cpu count in `MAKE` - Remove `gcc` of environment (because it has been partially removed in ndk r18) - Shorten long line to be pep8 friendly (line where we define env['BUILDLIB_PATH']) - Commented lines for `ArchAarch_64` that it seems tha we don't need anymore (not removed because I'm not sure if we need them) Note: This will force us to use a minimal ndk version of 19 See also: https://developer.android.com/ndk/guides/other_build_systems * [ndk19] Update `test_archs` to ndk's r19+ build system Also add some more tests. Now we check if some of the functions we mock, `glob` and `find_executable`, are called with the expected arguments * [ndk19] Update `test_bootstrap` to ndk's r19+ build system Because `clang` is the new default compiler and the affected tests were made thinking in `gcc` compiler * [ndk19] Remove `clang` of `get_recipe_env` Because as per ndk r19 the default compiler is clang and gcc has been partially removed * [ndk19] Adapt python recipes to ndk's r19+ build system We move python recipe to use a minimal ndk version of 19 because it will simplify the python's cross compilation (this way we can remove some environment variables that we don't need anymore). The only side effect detected is that the python's `zlib` module isn't built anymore. This is caused because python3 and python2 build systems contains libz's hardcoded version, which does not match the version used in ndk 19 (may be this the cause of some `zip/unzip` errors reported in python-for-android's issues?). We will take care later of this zlib problem, or we will get a runtime crash...so it seems that zlib is an `essential module` to successfully run a python-for-android app * [ndk19] Update libffi to version post `v3.3RC0` and adapt it to be ndk r19+ compatible * [ndk19] Fix build of python's zlib module Because python has a hardcoded zlib version which does not match android's ndk r19, and that prevents the build of zlib's module Note: it seems that we have to point to the right lib and headers, otherwise we won't succeed in building python's zlib module * [ndk19] Fix build of python2's _ctypes module for ndk r19+ * [ndk19] Fix numpy for ndk r19+ Note: because of the new build system recently introduced, we can safely remove some of the patches that we needed because it seems that it builds and runs fine without them * [ndk19] Update docs with the new ndk requirements * [ndk19] Set min/max/recommended android's NDK * [ndk19] Make CI tests with android's NDK `r19b` Because it's our minimum supported android NDK * [ndk19] Fix png recipe for NDK r19+ We remove `get_recipe_env` because we don't need anymore to specify the flags set in there. Note: As per new NDK r19+ build system implemented in p4a, the removed `flags` should be automatically set by the android's NDK * [ndk19] Add `-fPIC` to `armeabi-v7a`'s arch cflags... ...force `Position-Independent Code` To solve the kivy's build error detected in travis `OSX` test (https://travis-ci.org/kivy/python-for-android/jobs/576204088#L1105). But also detected the same error in my local tests (linux os in this case) for `freetype` and `harfbuzz` recipes...so I have the feeling that this is better to set as global 🤞..is it? * [LIBS - PART I] Initial refactor of library recipes (#1944) This commit will introduce a new cls attribute: `built_libraries`. This `built_libraries` attribute must be a dictionary. The keys are the full library name, e.g.: `libffi.so`. And the values must be the relative path of the library, e.g: `.libs`. So the this cls attribute for libffi recipe it would look like: ```built_libraries = {'libffi.so': '.libs'}``` This new cls attribute will allow us to detect library recipes and to refactor common operations that we do for those kind of recipes: - copy library into right location - implement `should_build` for library recipes Those two things will make that our rebuilds to be more consistent and I hope that it will be easier to maintain. **So, once explained a little this PR, in here we do:** - [x] Add attribute `built_libraries` - [x] Add methods to refactor common library operations: - [x] install_libraries - [x] get_libraries - [x] implement `should_build` for library recipes - [x] implement basic tests for the newly introduced `Recipe` methods - [x] Make use of those Library attributes/methods for some basic set of recipes: - [x] libffi - [x] openssl - [x] png - [x] jpeg - [x] freetype - [x] harfbuzz - [x] libcurl - [x] libzbar - [x] libiconv - [x] libexpat - [x] libogg - [x] libxml2 - [x] libxslt - [x] libshine - [x] libx264 - [x] libglob - [x] libsodium - [x] libsecp256k1 **Things to do in separate PRs**, to be easy to review and because those points will start to conflict with the `NDK r19 migration` thing just merged: - Make use of Library attributes/methods introduced in this PR for un covered library recipes in here. Here we have two situations: - library recipes that depends on android's STL library (almost all the work done in here will depend of the `NDK r19 migration` thing) - all remaining library recipes, which are not STL lib dependent and that are not implemented in here (because I was unable to perform a successful build with them using arch `arm64-v8a`...so I think it would be better to deal with those recipes in separate PRs and later...with the `NDK r19 migration` thing merged) **Notes about changed recipes:** all the recipes touched in here almost have the same changes: - remove `should_build` method (to make use of the one implemented in base class for library recipes) - remove the copy of the library (because that will be done automatically by the method `install_libraries` implemented in base class) - fixed the imports due to refactoring * [recipe-lib] Add attribute Recipe.built_libraries so we can refactor some essential operations performed for library recipes (like copy the library into the right location, or decide if we should build the library recipe again) * [recipe-lib] Add method Recipe.get_libraries This function will allows us to get a list of the built/context libraries. This will be useful to check if we have to built a library recipe or which library should be rebuild * [recipe-lib] Make `Recipe.should_build` decide the library build In case that the attribute built_libraries has been set, we will check the need of the recipe build, otherwise we will act as usual, forcing the build unless overwrote in subclass * [recipe-lib] Add method `Recipe.install_libraries` So we can: - control the copy of the library recipe - refactor the install of the lib for all library recipes * [recipe-lib] Make libffi a library recipe * [recipe-lib] Make openssl a library recipe and ... also make the imports from the right module * [recipe-lib] Make png a library recipe * [recipe-lib] Make jpeg a library recipe * [recipe-lib] Make freetype a library recipe and ... also make the imports from the right module * [recipe-lib] Make harfbuzz a library recipe and ... also make the imports from the right module * [recipe-lib] Make libcurl a library recipe and ... also make the imports from the right module * [recipe-lib] Make libzbar a library recipe and ... also make the imports from the right module * [recipe-lib] Make libiconv a library recipe and ... also make the imports from the right module * [recipe-lib] Make libexpat a library recipe and ... also: - make the imports from the right module - remove hardcoded arch * [recipe-lib] Make libogg a library recipe * [recipe-lib] Make libxml2 a library recipe and ... also make the imports from the right module * [recipe-lib] Make libxslt a library recipe and ... also make the imports from the right module * [recipe-lib] Make libshine a library recipe and ... also: - make the imports from the right module - remove the hardcoded cpu count when compiling * [recipe-lib] Make libx264 a library recipe and ... also: - make the imports from the right module - remove the hardcoded cpu count when compiling * [recipe-lib] Make libglob a library recipe * [recipe-lib] Make libsodium a library recipe and ... also: - make the imports from the right module - fix hardcoded arch - enable cpu count when compiling * [recipe-lib] Make libsecp256k1 a library recipe and ... also make the imports from the right module * [tests] Add tests for library recipe * [NDK19] Fix libglob for android NDK r19 - change the `ARG_MAX` define, because it's already defined at `sysroot/usr/include/linux/limits.h` - Replaced `size_t` by Including the <stddef.h> header. Because found the solution at stackoverflow: As per C99, §7.17, size_t is not a builtin type but defined in <stddef.h> See also: - https://travis-ci.org/kivy/python-for-android/jobs/576392711#L5992-L6013 - https://stackoverflow.com/questions/26410466/gcc-linaro-compiler-throws-error-unknown-type-name-size-t * [NDK19] Remove `--sysroot` from LDFLAGS for cffi and pymunk (#1965) Because `--sysroot` flag is not needed anymore and make it fails the build since we migrated to new android's build system (implemented in NDK r19) See also: - https://developer.android.com/ndk/guides/other_build_systems * Added libffi headers troubleshooting note to doc (#1972) * [LIBS - PART II] Part II of NDK r19 migration - Initial STL lib migration (#1947) * [recipe-stl] Add android's STL lib support to `Recipe` To allow us to refactor some common operations that we use in our recipes that depends on android's STL library. Note: This commit will allow us to begin the migration to `c++_shared`. This is a must when we move to android's NDK r19+, because as for android NDK >= 18 is the only one supported STL library. * [recipe-stl] Make CppCompiledComponentsPythonRecipe use Recipe's STL support * [recipe-stl] Make icu a library recipe with STL support (rework) Also done here: - Remove hardcoded version in url - Disable versioned shared libraries - Make it to be build as a shared libraries (instead of static) - Disable the build of static libraries (because we build them as shared ones, so we avoid to link with them without our consents) - Shorten long lines to be pep8's friendly - Remove icu from ci/constants - Remove `RuntimeError` about the need to use NDK api <= 19 (because that is not the case anymore) - consider host's number of cpu to perform the build * [recipe-stl] Rework pyicu recipe to match latest icu changes Also done here: - Remove icu.patch because now we don't have the version in our icu libraries - Shorten long lines to be pep8's friendly * [tests] Add tests for recipe with STL support * [tests] Add tests for icu recipe * [tests] Add tests for pyicu recipe * [WIP][LIBS - PART III] Rework of pyleveldb, leveldb and snappy (#1966) * [recipe-lib] Make snappy a library recipe * [recipe-stl] Make leveldb a library recipe and... make it work with the reworked snappy recipe * [recipe-stl] Fix pyleveldb for reworked leveldb/snappy * [WIP][LIBS - PART IV] Rework of shapely and libgeos (#1967) * [recipe-stl] Make libgeos a library recipe * [recipe-stl] Fix shapely for reworked libgeos * [recipe-stl] Make libzmq a library recipe (#1968) * [recipe-stl] Rework of libtorrent and boost (#1971) which: - fix build for android's NDK r19+ - allow us to build `boost+libtorrent` for any arch - Update boost to version `1.69.0` - update libtorrent to version `1.2.1` The build method needs to be changed because one of the scripts used in `boost+libtorrent` build (make-standalone-toolchain.sh), has been removed from android's NDK. [This is because](https://developer.android.com/ndk/guides/standalone_toolchain): `As of r19, the NDK's default toolchains are standalone toolchains, which renders this process unnecessary.` Note: since 3887d2b, `python-for-android` uses android's NDK r19 as the minimum supported and also changed the build method used by p4a as [described in here](https://developer.android.com/ndk/guides/other_build_systems) * Also copy the service/main.py when building with setup.py (#1936) * [recipe-stl] Rework of protobuf_cpp recipe (#1969) In here we do: - inherit from CppCompiledComponentsPythonRecipe Because depends on android's STL library - make use of the base class methods for library recipes - Split build_arch into proper methods - Shorten some long lines (to be PEP8 friendly) - make generated library shared - remove recipe from CI/constants * [CI] Fix CI's test for `arm64-v8a` (#1977) * Updated README.md to clarify NDK versions (#1981) * 📚 Updated README.dm to clarify NDK versions * 🔧 Change back to r19b * A bunch of tests for library recipes (#1982) The main idea is to test as many recipes as we can with the less code possible and without creating any file/directory so our tests can be performed as fast as possible (all this tests will only add between 2 and 3 seconds to our CI tests and will cover almost 100% of the code for each tested recipe) To do so, we create a couple of modules: tests.recipe_ctx: allow us to create a proper Context to test our recipes tests.recipe_lib_test: which holds some base classes to be used to test a recipe depending on the build method used. For starters we introduce two kind of base classes: BaseTestForMakeRecipe: To test an standard library build (this will iinclude the recipes which requires the classical build commandsconfigure/make) BaseTestForCmakeRecipe: To test an library recipe which is compiled with cmake We also refactor the existing recipes tests, so we can remove some lines in there...the ones that creates a Context. * [test] Add module `tests.recipe_ctx` A helper module to test recipes. Here we will initialize a `Context` to test recipes. * [test] Refactor `setUp/tearDown` for `test_icu` * [test] Refactor `setUp/tearDown` for `test_pyicu` * [test] Refactor `setUp` for `test_reportlab` * [test] Refactor `setUp` for `test_gevent` * [test] Add module `tests.recipe_lib_test` A helper module to test recipes which will allow to test any recipe using `configure/make` commands. * [test] Add test for `libffi` * [test] Add test for `libexpat` * [test] Add test for `libcurl` * [test] Add test for `libiconv` * [test] Add test for `libogg` * [test] Add test for `libpq` * [test] Add test for `libsecp256k1` * [test] Add test for `libshine` * [test] Add test for `libvorbis` * [test] Add test for `libx264` * [test] Add test for `libxml2` * [test] Add test for `libxslt` * [test] Add test for `png` * [test] Add test for `freetype` * [test] Add test for `harfbuzz` * [test] Add test for `openssl` * [test] Add `BaseTestForCmakeRecipe` * [test] Add test for `jpeg` and clean code We can remove the `get_recipe_env` because the environment that we use is already using a clang as default compiler (not the case when we migrated the jpeg recipe to use `cmake`)...so we can do a little refactor :) * [test] Add test for `snappy` * [test] Add test for `leveldb` * [test] Add test for `libgeos` * [test] Add test for `libmysqlclient` * [test] Add test for `openal` * [test] Make the `super` calls Python3 style * [test] Move mock tests outside context manager... Because there is no need to do it there. Also rewrote the inline comments. * Recipes tests enhancements (#1984) This is a follow up of #1982 In here we do: - Move from `__new__` to `__init__` for `BaseTestForMakeRecipe` ([discussed at here](#1982 (comment))) - Convert cls attributes to instance attributes ([discussed at here](#1982 (comment))) - Remove `mock` dependency for py3 tests (Because, as per Python 3.3+, `mock` it's a built-in-module). (Unfortunately we still will have a couple of `import mock` entries that we cannot remove until we completely remove python2 from our tests) * [test] From `__new__` to `__init__` for `BaseTestForMakeRecipe` * [test] Remove mock dependency for py3 tests Because, as per Python 3.3+, `mock` it's a built-in-module * [test] Convert cls attributes to instance attributes Because we may have some side effects without willing, considering that cls attributes are shared between instances. * Fixes test_virtualenv and test_venv failing, closes #1994 (#1995) Recent pep517 release seems to break tests. * Made p4a use per-arch dist build dirs (#1986) * Made p4a use per-arch dist build dirs * Fixed up check on existing folder when overwriting distributions * Improved Distribution.get_distribution api * Fixed test_archs.py * Fixed test_bootstrap.py * Fixed test_distribution.py * Fixed recipes tests * Fixed formatting * Made sure whole build process accesses dist_dir correctly * Fixed apk output name formatting by moving version to end of string * Further test fixes following dist_dir changes * Removed unnecessary variable * Fixes libiconv & libzbar configure host Having `--host=x86` was making the configure script fail at enabling shared library build on `x86`. This was resulting in failing to copy `libiconv.so` and `libzbar.so` on `x86` arch. * Updates Java version troubleshooting (#1991) Adds the NoClassDefFoundError XmlSchema case and groups related cases together. Gives instructions for both Ubuntu and macOS to fix. * Made on-device unit tests app use the develop branch by default (#1985) * Updated version to 2019.10.06 Co-authored-by: Pol Canelles <canellestudi@gmail.com> Co-authored-by: Gabriel Pettier <gabriel.pettier@gmail.com> Co-authored-by: Philipp Auersperg-Castell <phil@bluedynamics.com> Co-authored-by: Richard Larkin <zenkey.zencode@gmail.com> Co-authored-by: Andre Miras <AndreMiras@users.noreply.github.com> * Bumps openssl to 1.1.1f * Updated version to 2019.10.06.post0 Co-authored-by: Pol Canelles <canellestudi@gmail.com> Co-authored-by: Gabriel Pettier <gabriel.pettier@gmail.com> Co-authored-by: Philipp Auersperg-Castell <phil@bluedynamics.com> Co-authored-by: Richard Larkin <zenkey.zencode@gmail.com> Co-authored-by: Andre Miras <AndreMiras@users.noreply.github.com> Co-authored-by: Andre Miras <andre.miras@gmail.com>
customizability options for p4a
This PR introduces a set of options which deal with integration of java/kotlin libraries
this allows to specify a custom class inherited class from org.kivy.android.PythonActivity as entrypoint