From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [RFCv1 4/4] core: implement per-package SDK and target
Date: Fri, 24 Nov 2017 15:43:23 +0100 [thread overview]
Message-ID: <20171124154323.0895cadc@windsurf.lan> (raw)
In-Reply-To: <ab34a9ea-90a0-fc39-273d-0bd08a2c72b0@mind.be>
Hello,
A few more answers/topics I wanted to discuss.
On Tue, 7 Nov 2017 23:50:52 +0100, Arnout Vandecappelle wrote:
> Given the possible host-tar and host-lzip dependencies, the rsync
> should be done here already, not in the configure step. Ouch, that's
> not good, because the dependencies are only evaluated for the
> configure step... There are PATCH_DEPENDENCIES, but those are only
> before patch. Well, I guess that's a reason to keep host-tar and
> host-lzip as DEPENDENCIES_HOST_PREREQ :-)
Here is how I'm thinking of solving the problem:
- Next to <pkg>_PATCH_DEPENDENCIES, introduce the concept of
<pkg>_EXTRACT_DEPENDENCIES.
- If there is no suitable tar in the system, then host-tar would be
added to <pkg>_EXTRACT_DEPENDENCIES of all packages, except host-tar
itself.
- If the package needs lzip and there is no lzip available on the
system, host-lzip is added to <pkg>_EXTRACT_DEPENDENCIES.
- If ccache support is enabled, host-ccache is added to
<pkg>_DEPENDENCIES of all packages, except host-tar, which is built
with HOSTCC_NOCCACHE.
- At the beginning of the extract step of a package, we rsync to its
per-package target/host directories the per-package target/host dirs
of the packages listed in its <pkg>_EXTRACT_DEPENDENCIES variable.
- At the beginning of the patch step of a package, we rsync to its
per-package target/host directories the per-package target/host dirs
of the packages listed in its <pkg>_PATCH_DEPENDENCIES variable.
Thoughts?
> > +$(2)_HOST_DIR = $$(PER_PACKAGE_DIR)/$(1)/host/
> > +$(2)_STAGING_DIR = $$(PER_PACKAGE_DIR)/$(1)/host/$(STAGING_SUBDIR)
>
> I hate adding more per-package variables. Can't you use the expanded values,
> substituting $($(PKG)_NAME) for $(1)? Or maybe even better, change the
> definition of TARGET_DIR etc:
>
> TARGET_DIR = $(if
> $(PKG),$(PER_PACKAGE_DIR)/$($(PKG)_RAWNAME)/target,$(BASE_DIR)/target)
>
> That way you also don't need to pass those variables to each individual stamp rule.
I've changed this in my new iteration. The only drawback is that since
we no longer have those shortcut variables, the foreach loops building
the per-package directories, and building the final global directories
are a bit less readable:
Per-package host/target creation:
$(foreach pkg,$($(PKG)_FINAL_DEPENDENCIES),\
rsync -a --link-dest=$(PER_PACKAGE_DIR)/$(pkg)/host/ \
$(PER_PACKAGE_DIR)/$(pkg)/host/ \
$(HOST_DIR)$(sep))
$(foreach pkg,$($(PKG)_FINAL_DEPENDENCIES),\
rsync -a --link-dest=$(PER_PACKAGE_DIR)/$(pkg)/target/ \
$(PER_PACKAGE_DIR)/$(pkg)/target/ \
$(TARGET_DIR)$(sep))
Global host/target creation in target-finalize:
$(foreach pkg,$(PACKAGES),\
rsync -a --link-dest=$(PER_PACKAGE_DIR)/$(pkg)/target/ \
$(PER_PACKAGE_DIR)/$(pkg)/target/ \
$(TARGET_DIR)$(sep))
@$(call MESSAGE,"Creating global host directory")
$(foreach pkg,$(PACKAGES),\
rsync -a --link-dest=$(PER_PACKAGE_DIR)/$(pkg)/host/ \
$(PER_PACKAGE_DIR)/$(pkg)/host/ \
$(HOST_DIR)$(sep))
But I guess that's OK. If we find that too weird, I can always
introduce some some make helpers:
per-package-target-dir = $(PER_PACKAGE_DIR)/$(1)/target
per-package-host-dir = $(PER_PACKAGE_DIR)/$(1)/host
But:
$(call per-package-target-dir,$(pkg))
is not really shorter than
$(PER_PACKAGE_DIR)/$(1)/target
It is actually longer :-)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-11-24 14:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-03 16:06 [Buildroot] [RFCv1 0/4] Per-package SDK and target directories Thomas Petazzoni
2017-11-03 16:06 ` [Buildroot] [RFCv1 1/4] pkgconf: use relative path to STAGING_DIR instead of absolute path Thomas Petazzoni
2017-11-07 21:05 ` Arnout Vandecappelle
2017-11-03 16:06 ` [Buildroot] [RFCv1 2/4] core: change host RPATH handling Thomas Petazzoni
2017-11-05 8:57 ` Yann E. MORIN
2017-11-05 14:44 ` Thomas Petazzoni
2017-11-05 14:48 ` Arnout Vandecappelle
2017-11-07 22:41 ` Thomas Petazzoni
2017-11-07 23:50 ` Arnout Vandecappelle
2017-11-08 8:55 ` Thomas Petazzoni
2017-11-08 10:55 ` Arnout Vandecappelle
2017-11-08 12:30 ` Thomas Petazzoni
2017-11-08 12:38 ` Arnout Vandecappelle
2017-11-07 21:15 ` Arnout Vandecappelle
2017-11-07 21:22 ` Thomas Petazzoni
2017-11-07 23:45 ` Arnout Vandecappelle
2017-11-03 16:06 ` [Buildroot] [RFCv1 3/4] toolchain: post-pone evaluation of TOOLCHAIN_EXTERNAL_BIN Thomas Petazzoni
2017-11-07 21:23 ` Arnout Vandecappelle
2017-11-07 21:33 ` Thomas Petazzoni
2017-11-07 23:49 ` Arnout Vandecappelle
2017-11-03 16:06 ` [Buildroot] [RFCv1 4/4] core: implement per-package SDK and target Thomas Petazzoni
2017-11-07 22:50 ` Arnout Vandecappelle
2017-11-07 23:11 ` Thomas Petazzoni
2017-11-07 23:57 ` Arnout Vandecappelle
2017-11-24 14:49 ` Thomas Petazzoni
2017-11-24 14:43 ` Thomas Petazzoni [this message]
2017-11-25 17:30 ` Arnout Vandecappelle
2017-11-25 20:01 ` Thomas Petazzoni
2017-11-27 14:23 ` Yann E. MORIN
2017-11-07 23:21 ` [Buildroot] [RFCv1 0/4] Per-package SDK and target directories Arnout Vandecappelle
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171124154323.0895cadc@windsurf.lan \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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