On Fri, 07 Aug 2020 07:33:03 -0400 Julien Lepiller wrote: > Unfortunately, android-platform-core should first be fixed to accept > a hash as an argument, otherwise any other version will fail. Don't > know why we haven't done that beforeā€¦ I don't understand what the hash would be here, nor the consequences you describe. Do you have some pointers on the documentation or source code that I should read to better understand that? By the way I find it a bit strange to refer to have to manually extract android-platform-system-core to be able to refer its include path. Beside the native-input, this results in the following code: > #:make-flags (list (string-append "CFLAGS= " > "-I core/include " > [...])) > > [...] > > #:phases > (modify-phases %standard-phases > (add-after 'unpack 'unpack-core > (lambda* (#:key inputs #:allow-other-keys) > (mkdir-p "core") > (with-directory-excursion "core" > (invoke "tar" "axf" (assoc-ref inputs "android-core") > "--strip-components=1")) > #t)) > [...]) Instead of just that: > #:make-flags (list (string-append "CFLAGS= " > "-I " (assoc-ref %build-inputs "android-core") > "/include ")) > [...])) Another potential improvement would be to remove the android-platform-version argument completely and set version to it in android.mk like that: > (define-public (android-platform-system-core > [...] > (version (android-platform-version)) > [...] That would make the native-input look like that: > (native-inputs > `( > ("android-core" ,android-platform-system-core))) And if we need the version 9.0.0_r3 we could define a new package: > (define-public android-platform-system-core-9 > (package > (inherit android-platform-system-core) > (version "9.0.0_r3")))) and use it: > (native-inputs > `( > ("android-core" ,android-platform-system-core-9))) Are both proposal a good idea? Or does it have any downsides that I didn't think of? Denis.