From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCHv4 2/5] core: allow external Config.in/makefile code to be integrated
Date: Sun, 01 Dec 2013 01:29:37 +0100 [thread overview]
Message-ID: <529A82F1.6030007@mind.be> (raw)
In-Reply-To: <1385751626-28967-3-git-send-email-thomas.petazzoni@free-electrons.com>
On 29/11/13 20:00, Thomas Petazzoni wrote:
> This commit allows the BR2_EXTERNAL directory to contain Config.in and
> Makefile code, which gets integrated into the Buildroot build logic:
>
> - Buildroot automatically includes the $BR2_EXTERNAL/Config.in in the
> top-level configuration menu.
>
> - Buildroot automatically includes the BR2_EXTERNAL/external.mk in
> the build logic, so it can for example be used to include other .mk
> files that define package recipes.
The advantage of enforcing the package dir would have been that we
could directly include $(BR2_EXTERNAL)/package/*/*.mk, instead of forcing
the user to create an external.mk that contains either
include $(BR2_EXTERNAL)/package/*/*.mk
or
include $(BR2_EXTERNAL)/*/*.mk
depending on how he structures things.
Maybe a compromise is that we source $BR2_EXTERNAL/package/Config.in
but include it at the end of the top-level Config.in instead of at the
beginning of the package/Config.in. I guess that's what Samuel meant
before...
>
> This is typically intended to be used to create target packages in the
> BR2_EXTERNAL directory, but can also be used for bootloaders, host
> packages, or other custom make logic.
>
> We also add a dummy Config.in file in support/dummy-external/ to
> ensure that the source "$BR2_EXTERNAL/Config.in" line will point to an
> existing file even when BR2_EXTERNAL is not used by the user.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> Config.in | 2 ++
> Makefile | 4 ++++
> support/dummy-external/Config.in | 0
> 3 files changed, 6 insertions(+)
> create mode 100644 support/dummy-external/Config.in
>
> diff --git a/Config.in b/Config.in
> index 98726ab..9b10693 100644
> --- a/Config.in
> +++ b/Config.in
> @@ -486,3 +486,5 @@ source "boot/Config.in"
> source "package/Config.in.host"
>
> source "Config.in.legacy"
> +
> +source "$BR2_EXTERNAL/Config.in"
> diff --git a/Makefile b/Makefile
> index 5878d44..b5a9828 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -375,6 +375,10 @@ include boot/common.mk
> include linux/linux.mk
> include system/system.mk
>
> +ifeq ($(BR2_EXTERNAL_USED),y)
> +include $(BR2_EXTERNAL)/external.mk
> +endif
Wouldn't it be simpler to put a dummy external.mk file in
dummy-external as well? Then BR2_EXTERNAL_USED can be removed (the
following patch doesn't need it: the pattern rule will just never match
because support/dummy-external/configs doesn't exist).
Regards,
Arnout
> +
> TARGETS+=target-finalize
>
> ifeq ($(BR2_ENABLE_LOCALE_PURGE),y)
> diff --git a/support/dummy-external/Config.in b/support/dummy-external/Config.in
> new file mode 100644
> index 0000000..e69de29
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
next prev parent reply other threads:[~2013-12-01 0:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-29 19:00 [Buildroot] [PATCHv4 0/5] Keeping customizations outside the Buildroot tree with BR2_EXTERNAL Thomas Petazzoni
2013-11-29 19:00 ` [Buildroot] [PATCHv4 1/5] core: introduce the BR2_EXTERNAL variable Thomas Petazzoni
2013-11-30 22:38 ` Yann E. MORIN
2013-12-01 0:17 ` Arnout Vandecappelle
2013-12-01 0:20 ` [Buildroot] [PATCH v5] " Arnout Vandecappelle
2013-11-29 19:00 ` [Buildroot] [PATCHv4 2/5] core: allow external Config.in/makefile code to be integrated Thomas Petazzoni
2013-11-30 22:39 ` Yann E. MORIN
2013-12-01 0:29 ` Arnout Vandecappelle [this message]
2013-11-29 19:00 ` [Buildroot] [PATCHv4 3/5] core: allow external defconfigs to be used Thomas Petazzoni
2013-11-30 22:42 ` Yann E. MORIN
2013-12-01 0:32 ` Arnout Vandecappelle
2013-11-29 19:00 ` [Buildroot] [PATCHv4 4/5] docs/manual: add explanations about BR2_EXTERNAL Thomas Petazzoni
2013-11-30 22:59 ` Yann E. MORIN
2013-12-01 0:43 ` Arnout Vandecappelle
2013-11-29 19:00 ` [Buildroot] [PATCHv4 5/5] manual: fix manual generation with BR2_EXTERNAL support Thomas Petazzoni
2013-11-30 23:10 ` Yann E. MORIN
2013-12-01 10:16 ` Samuel Martin
2013-12-01 0:46 ` 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=529A82F1.6030007@mind.be \
--to=arnout@mind.be \
--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