From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2Ar3GyFRMV/xOwAA0tVLHw (envelope-from ) for ; Mon, 10 Aug 2020 13:52:33 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id GIisFyFRMV/pMQAAbx9fmQ (envelope-from ) for ; Mon, 10 Aug 2020 13:52:33 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id F2E109409E0 for ; Mon, 10 Aug 2020 13:52:32 +0000 (UTC) Received: from localhost ([::1]:52738 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k58E3-0001xp-OH for larch@yhetil.org; Mon, 10 Aug 2020 09:52:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53460) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k58Da-0001c7-Ax for guix-patches@gnu.org; Mon, 10 Aug 2020 09:52:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:51688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k58Da-0003CN-1g for guix-patches@gnu.org; Mon, 10 Aug 2020 09:52:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k58DZ-0006b7-Qz for guix-patches@gnu.org; Mon, 10 Aug 2020 09:52:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#42734] Export android-platform-system-core Resent-From: Julien Lepiller Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 10 Aug 2020 13:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42734 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: Denis 'GNUtoo' Carikli Cc: 42734@debbugs.gnu.org Received: via spool by 42734-submit@debbugs.gnu.org id=B42734.159706748325316 (code B ref 42734); Mon, 10 Aug 2020 13:52:01 +0000 Received: (at 42734) by debbugs.gnu.org; 10 Aug 2020 13:51:23 +0000 Received: from localhost ([127.0.0.1]:35001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k58Cw-0006aG-RQ for submit@debbugs.gnu.org; Mon, 10 Aug 2020 09:51:23 -0400 Received: from lepiller.eu ([89.234.186.109]:36262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k58Cu-0006a5-1g for 42734@debbugs.gnu.org; Mon, 10 Aug 2020 09:51:22 -0400 Received: from lepiller.eu (localhost [127.0.0.1]) by lepiller.eu (OpenSMTPD) with ESMTP id 2715b142; Mon, 10 Aug 2020 13:51:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=lepiller.eu; h=date :in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:to:cc:from:message-id; s= dkim; bh=75oTckrrT5InNKSie03sU9+zEkPrBrA4LYwdcNwe+sc=; b=kZiXE9X IBzZACqwCyu/cDeugZjwweS9SMjfRrXn8j+LnhLuSVn612Our+bPtuq7Q5epAUr8 WuWSObVFMAr4YoMhRTj5cTvDRVwh+2xnlphqzSQt+BYk039aeWDX3iYRJorL6S4D noZwf77pKdX9PX1OfnD3Ul/eE1+cu7RZ2Gbh3hWCE59bdbmbenlGTTL/hOG0BfXx kGlHZ2l10426+4WzWxG/xS7jDGri3fXA2fcZTr13UDCvdirvasaMYV49yD+hMVEM nqNg8HBLh3MguqCaBSrTGQGvSbeOI1+m8My6Q8bRNwZV/MHXBHzJ9PXz6jAloHC+ PKpZwJqEsGJ+rkw== Received: by lepiller.eu (OpenSMTPD) with ESMTPSA id c9e5b0d6 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Mon, 10 Aug 2020 13:51:16 +0000 (UTC) Date: Mon, 10 Aug 2020 09:50:51 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <20200810051949.737d799e@primarylaptop.localdomain> References: <20200807024423.1638d242@primarylaptop.localdomain> <13A86DDA-5411-495A-B6AC-042A9F932065@lepiller.eu> <20200810051949.737d799e@primarylaptop.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----GEN9Q3A30RWOOIESVXXJQEJZHBV5H7" Content-Transfer-Encoding: 7bit From: Julien Lepiller Message-ID: X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=lepiller.eu header.s=dkim header.b=kZiXE9X ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=lepiller.eu (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: 0.09 X-TUID: 6arKl2dVbVmI ------GEN9Q3A30RWOOIESVXXJQEJZHBV5H7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think I confused a few things here=2E Currently android-platform-system-c= ore is a procedure that takes a version number and returns an origin record= (a source)=2E However, that record hard-codes a hash, so if you specify a = different version, the source can't be fetcged, as the hash mismatches=2E 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=E2=80=A6 How about this: android-platform-system-core is renamed to android-platform-system-core-so= urce and takes a version, a hash and a list patch names=2E android-platform-system-core is the result of calling this function with t= he default version, hash anl patch set=2E The other source procedures should probably be fixed in the same way=2E I also found out that android-liblog didn't install its headers=2E I'll fi= x that this evening if I remember=2E On 2020=E5=B9=B48=E6=9C=889=E6=97=A5 23:19:49 GMT-04:00, Denis 'GNUtoo' Ca= rikli wrote: >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=2E Don't >> know why we haven't done that before=E2=80=A6 > >I don't understand what the hash would be here, nor the consequences >you describe=2E 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=2E > >Beside the native-input, this results in the following code: >> #:make-flags (list (string-append "CFLAGS=3D " >> "-I core/include " >> [=2E=2E=2E])) >> >> [=2E=2E=2E] >> >> #: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=3D1")) >> #t)) >> [=2E=2E=2E]) > >Instead of just that: >> #:make-flags (list (string-append "CFLAGS=3D " >> "-I " (assoc-ref %build-inputs "android-core") >> "/include ")) >> [=2E=2E=2E])) > >Another potential improvement would be to remove the >android-platform-version argument completely and set version to it in >android=2Emk like that: >> (define-public (android-platform-system-core >> [=2E=2E=2E] >> (version (android-platform-version)) >> [=2E=2E=2E] > >That would make the native-input look like that: >> (native-inputs >> `( >> ("android-core" ,android-platform-system-core))) > >And if we need the version 9=2E0=2E0_r3 we could define a new package: >> (define-public android-platform-system-core-9 >> (package >> (inherit android-platform-system-core) >> (version "9=2E0=2E0_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=2E ------GEN9Q3A30RWOOIESVXXJQEJZHBV5H7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think I confused a few things here=2E Currently = android-platform-system-core is a procedure that takes a version number and= returns an origin record (a source)=2E However, that record hard-codes a h= ash, so if you specify a different version, the source can't be fetcged, as= the hash mismatches=2E

It also includes patches that may not work w= ith other versions, so I'm not sure why we allow to pass a version number i= n tge first place=E2=80=A6

How about this:

android-platform-s= ystem-core is renamed to android-platform-system-core-source and takes a ve= rsion, a hash and a list patch names=2E

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

The other source procedures should probably be fixed in= the same way=2E

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

On 2020=E5=B9=B48=E6=9C=889=E6=97=A5 23:19:49 GMT-04:00,= Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension=2Eorg> wrote: 
On Fri, 07 Aug 2020 07:33:03 -0400
Julien Lepille=
r <julien@lepiller=2Eeu> wrote:

Unfortunately, android-platform-core should first be fix=
ed to accept
a hash as an argument, otherwise any other version will fai=
l=2E Don't
know why we haven't done that before=E2=80=A6

I don't understand what the hash would be here, nor the consequencesyou describe=2E Do you have some pointers on the documentation or source<=
br>code that I should read to better understand that?

By the way I f=
ind it a bit strange to refer to have to manually extract 
android-platf=
orm-system-core to be able to refer its include path=2E

Beside the n=
ative-input, this results in the following code:
 #:make-flags (list (string-append "CFLAGS=3D "                                   "-I core/include "
 [=2E=2E=2E]))
 [=2E=2E=2E]

 #: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=3D1"))
   #t))
 [=2E=2E=2E])

Ins=
tead of just that:
#:ma=
ke-flags (list (string-append "CFLAGS=3D "
                   "-I " (ass=
oc-ref %build-inputs "android-core")
                   "/include "))[=2E=2E=2E]))

Another potential improvement would be t=
o remove the
android-platform-version argument completely and set versio=
n to it in
android=2Emk like that:
(define-public (android-platform-system-core
[=2E=2E=2E]<=
br> (version (android-platform-version))
[=2E=2E=2E]
That would make the native-input look like that:
(native-inputs
 `(
   ("android-core" ,and=
roid-platform-system-core)))

And if we need the version=
 9=2E0=2E0_r3 we could define a new package:
(define-public android-platform-system-core-9
  (p=
ackage
   (inherit android-platform-system-core)
    (version "9=2E0=
=2E0_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=2E<=
br>
------GEN9Q3A30RWOOIESVXXJQEJZHBV5H7--