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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.