[bug#42734] Export android-platform-system-core

[Julien Lepiller <julien@lepiller.eu>]

[-- Attachment #1: Type: text/plain, Size: 3155 bytes --]

I think I confused a few things here. Currently android-platform-system-core is a procedure that takes a version number and returns an origin record (a source). However, that record hard-codes a hash, so if you specify a different version, the source can't be fetcged, as the hash mismatches.

It also includes patches that may not work with other versions, so I'm not sure why we allow to pass a version number in tge first place…

How about this:

android-platform-system-core is renamed to android-platform-system-core-source and takes a version, a hash and a list patch names.

android-platform-system-core is the result of calling this function with the default version, hash anl patch set.

The other source procedures should probably be fixed in the same way.

I also found out that android-liblog didn't install its headers. I'll fix that this evening if I remember.

On 2020年8月9日 23:19:49 GMT-04:00, Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:
>On Fri, 07 Aug 2020 07:33:03 -0400
>Julien Lepiller <julien@lepiller.eu> 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.

[-- Attachment #2: Type: text/html, Size: 4356 bytes --]