From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/4] core/pkg-kconfig: ensure kconfig file and fragments exist
Date: Fri, 12 Jun 2015 23:24:22 +0200 [thread overview]
Message-ID: <20150612232422.4a12fc2b@free-electrons.com> (raw)
In-Reply-To: <22cb4293142894b08d3103f39ceaa2351b0e357b.1433591404.git.yann.morin.1998@free.fr>
Yann,
On Sat, 6 Jun 2015 13:54:23 +0200, Yann E. MORIN wrote:
> Because the base kconfig file has a dependency but no rule, make will
> always try to rebuild targets that depend on it:
>
> https://www.gnu.org/software/make/manual/make.html#Force-Targets
>
> To complexify things yet a little bit more, missing kconfig fragments
> are properly caught,
What do you mean by "are properly caught" ? Also, I don't see the
interaction between this and the previous paragraph, and hence the "To
complexity things yet a little bit more"
> but since they could be bundled in the package,
> they should depend on it being extracted. And then we'd have the same
> issue as with the base kconfig file, above.
"then" what ?
> Furthermore, merge-config.sh does not check for the existence of the
> fragments, not even the existence of the base file.
How is this related to the previous paragraph ?
> So, this patch does more than one single thing, but they are clearly all
> pretty much inter-woven each with the others, and thus are done together:
>
> - make kconfig fragments depend on the package being patched, like the
> base kconfig file,
>
> - manualy check that the base and fragments do exist.
manually
> -# The config file could be in-tree, so before depending on it the package should
> -# be extracted (and patched) first
> -$$($(2)_KCONFIG_FILE): | $(1)-patch
> +# The config file as well as the fragments could be in-tree, so before
> +# depending on them the package should be extracted (and patched) first
> +$$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch
This part makes complete sense.
> # The specified source configuration file and any additional configuration file
> # fragments are merged together to .config, after the package has been patched.
> # Since the file could be a defconfig file it needs to be expanded to a
> # full .config first. We use 'make oldconfig' because this can be safely
> # done even when the package does not support defconfigs.
> +#
> +# merge-config.sh does not check for the existence of the fragments, not even
> +# the existence of the base file, so we do it manually.
> +#
> $$($(2)_DIR)/.config: $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES)
> + for f in $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES); do \
> + if [ ! -f "$$$${f}" ]; then \
> + printf "Kconfig fragment '%s' for '%s' does not exist\n" "$$$${f}" "$(1)"; \
> + exit 1; \
> + fi; \
> + done
And this one as well.
So basically, I understand the code, but absolutely not the commit
log :-)
And also, I don't understand why those two things are so much
"inter-woven" that they cannot be done in two separate patches. It's
actually two very separate things: 1/ support kconfig fragments bundled
in the package source code (chunk 1) and 2/ check that they exist
(chunk 2).
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-06-12 21:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-06 11:54 [Buildroot] [PATCH 0/4] core/pkg-kconfig: fix saving back the configuration (branch yem/pr8156) Yann E. MORIN
2015-06-06 11:54 ` [Buildroot] [PATCH 1/4] core/pkg-kconfig: ensure kconfig file and fragments exist Yann E. MORIN
2015-06-12 21:24 ` Thomas Petazzoni [this message]
2015-06-12 22:12 ` Yann E. MORIN
2015-06-06 11:54 ` [Buildroot] [PATCH 2/4] core/pkg-kconfig: move the kconfig fixups to a macro Yann E. MORIN
2015-06-12 21:33 ` Thomas Petazzoni
2015-06-12 22:17 ` Yann E. MORIN
2015-06-13 16:41 ` Arnout Vandecappelle
2015-06-06 11:54 ` [Buildroot] [PATCH 3/4] core/pkg-kconfig: run the kconfig fixups after exiting configurators Yann E. MORIN
2015-06-12 21:36 ` Thomas Petazzoni
2015-06-12 22:38 ` Yann E. MORIN
2015-06-13 16:25 ` Arnout Vandecappelle
2015-06-14 21:42 ` Yann E. MORIN
2015-07-21 19:38 ` Yann E. MORIN
2015-06-06 11:54 ` [Buildroot] [PATCH 4/4] core/pkg-kconfig: allow saving config to a non-existing custom config file Yann E. MORIN
2015-06-12 21:39 ` Thomas Petazzoni
2015-06-12 23:19 ` Yann E. MORIN
2015-06-12 21:46 ` [Buildroot] [PATCH 0/4] core/pkg-kconfig: fix saving back the configuration (branch yem/pr8156) Thomas Petazzoni
2015-06-12 23:23 ` Yann E. MORIN
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=20150612232422.4a12fc2b@free-electrons.com \
--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