unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
To: help-guix@gnu.org, Julien Lepiller <julien@lepiller.eu>
Subject: Re: Android.mk build system limitations
Date: Mon, 11 Jul 2022 09:22:48 +0200	[thread overview]
Message-ID: <20220711092248.3bf46a2d@primarylaptop.localdomain> (raw)
In-Reply-To: <20220709211727.3e823f9a@primarylaptop.localdomain>

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

On Sat, 9 Jul 2022 21:17:27 +0200
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:
> Apparently the issue doesn't seems to be in Guix but in
> android-make-stub: android-make-stub seems to be made for only one
> target at a time.
With all my modifications for my tests, I forgot that by default it
compiled all the HOST targets it founds.

So if I use the defaults, and make all the include $(BUILD_*) become
include $(BUILD_HOST_*), it would try to build all local modules.

It builds them in the order in which they are declared inside the
Android.mk.

The android-make-stub current design prevents it from being able to
parse dependencies correctly:
- It will not build the local modules dependencies before the local
  module(s) that use them unless they are in that order in the
  Android.mk.
- It can link the local module(s) executable(s) against the local
  modules libraries but if the local modules libraries also need to be
  linked to other libraries, it won't try to link the local module
  executable(s) to these other libraries, and the build will fail.

The advantage of the current design is that the android-make-stub code
is relatively simple to understand and contribute to.

android-make-stub also had an issue with includes but that was a bug
and not a limitation of the current design.

So I've sent a patch serie to android-make-stub[1] to address theses
issues, however it won't be able to fix the design limitations.

So once that serie is merged, and android-make-stub is updated in Guix,
we'd still need to workaround the design limitations in guix by:
- Passing some extra libraries to LDFLAGS
- When multiple LOCAL_MODULE are in the Android.mk, and that the build
  order doesn't match the declaration order, we'd need to run make with
  LOCAL_MODULE=<module> for each module to build. The guix.scm I
  mentioned earlier has some example of how to do that.

I'll send patches or open bug reports to update android-make-stub when
that merge is done. And I'll then use the workarounds mentioned above
in my guix.scm to workaround the limitations of android-make-stub.

References:
-----------
[1]https://github.com/daym/android-make-stub/pull/1

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2022-07-11  7:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-06 15:20 Android.mk build system limitations Denis 'GNUtoo' Carikli
2022-07-09 12:57 ` Denis 'GNUtoo' Carikli
2022-07-09 19:17   ` Denis 'GNUtoo' Carikli
2022-07-11  7:22     ` Denis 'GNUtoo' Carikli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220711092248.3bf46a2d@primarylaptop.localdomain \
    --to=gnutoo@cyberdimension.org \
    --cc=help-guix@gnu.org \
    --cc=julien@lepiller.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).