Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH next v4 6/6] core: implement per-package SDK and target
Date: Fri, 16 Nov 2018 14:47:35 +0100	[thread overview]
Message-ID: <20181116144735.19585727@windsurf> (raw)
In-Reply-To: <de9da9af-71f4-cfe2-f691-5aae17e3ca0a@andin.de>

Hello,

Yann was already in Cc, I've added Thomas De Schampheleire as well.
Yann, Thomas, there is some kconfig related discussion below, we
need you :-)

On Thu, 15 Nov 2018 17:41:35 +0100, Andreas Naumann wrote:

> This is much clearer to me than v3, however there is a problem with 
> kconfig packages. Unfortunately, the kconfig infrastructure is running 
> the 'make xxx_defconfig' step before the configure-step is "officially" 
> started. This is due to the kconfig_fixup target being a dependency of 
> -configure. This in turn requires availability of the toolchain and 
> other prerequisites that are part of _FINAL_DEPENDENCIES earlier as 
> prepared in your above patch.
> 
> I made a patch which moves the _FINAL_DEPENDENCIES preparation to an 
> additional .stamp-configure-prepare step just before .stamp_configured. 
> That works but is not particularly beautiful.

That is not too bad actually. Semantically speaking, preparing the
per-package folders is not really part of the configuration step. It
could be logical to do it in a "prepare" step.

The only thing that I dislike a bit with this is that it would no
longer be consistent with what we do for download and extract
dependencies: we prepare the per-package folders with download and
extract dependencies respectively in the download and extract steps. So
it would be quite logical to also do the same for the "configuration
dependencies" (which we name just "dependencies" in Buildroot).

So, this leaves us with 3 options:

 - Keep the dependency preparation within the download, extract and
   configure step, as proposed in this v4. This will require changing
   the kconfig logic to prepare the configuration file inside the
   "configure" step and not as a additional step injected before the
   "configure" step.

 - Keep the dependency preparation within the download and extract
   steps, and make an exception for the configure step, with a separate
   "prepare" step that comes before. Not nice in terms of consistency,
   as explained above.

 - Introduce "prepare download", "prepare extract" and "prepare
   configure" steps that would do the dependency preparation.

> I guess a more proper solution would be to somehow move the 
> kconfig_fixup code into the configure-step. Maybe use the 
> pre-configure-hook, any suggestions?

I don't recall why they need to be done before the configuration step,
but I'm pretty sure there is a reason for that.

Yann, Thomas, do you remember ?

Thanks a lot,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2018-11-16 13:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-14 10:55 [Buildroot] [PATCH next v4 0/6] Per-package host/target directory support Thomas Petazzoni
2018-11-14 10:55 ` [Buildroot] [PATCH next v4 1/6] Makefile: evaluate CCACHE and HOST{CC, CXX} at time of use Thomas Petazzoni
2018-11-15 20:49   ` Yann E. MORIN
2018-11-14 10:55 ` [Buildroot] [PATCH next v4 2/6] support/scripts/check-host-rpath: split condition on two statements Thomas Petazzoni
2018-11-15 20:58   ` Yann E. MORIN
2018-11-14 10:55 ` [Buildroot] [PATCH next v4 3/6] Makefile: rework main directory creation logic Thomas Petazzoni
2018-11-15 21:09   ` Yann E. MORIN
2018-11-16 14:08     ` Thomas Petazzoni
2018-11-16  1:21   ` Matthew Weber
2018-11-16 14:15     ` Thomas Petazzoni
2018-11-16 15:14       ` Thomas Petazzoni
2018-11-20 22:08         ` Matthew Weber
2018-11-27  6:24           ` Christian Stewart
2018-11-14 10:55 ` [Buildroot] [PATCH next v4 4/6] Makefile: move .NOTPARALLEL statement after including .config file Thomas Petazzoni
2018-11-15 21:37   ` Yann E. MORIN
2018-11-16  8:53     ` Thomas Petazzoni
2018-11-14 10:55 ` [Buildroot] [PATCH next v4 5/6] Makefile: define TARGET_DIR_WARNING_FILE relative to TARGET_DIR Thomas Petazzoni
2018-11-14 10:55 ` [Buildroot] [PATCH next v4 6/6] core: implement per-package SDK and target Thomas Petazzoni
2018-11-15 16:41   ` Andreas Naumann
2018-11-16 13:47     ` Thomas Petazzoni [this message]
2018-11-16 15:22       ` Thomas De Schampheleire
2018-11-16 19:57         ` Yann E. MORIN
2018-11-18 21:55           ` Arnout Vandecappelle
2018-11-19 10:48             ` Thomas Petazzoni
2018-11-19 14:27               ` Andreas Naumann
2018-11-19 19:49               ` Yann E. MORIN
2018-11-20 10:22                 ` Arnout Vandecappelle
2018-11-20 10:29                   ` Thomas Petazzoni
2018-11-20 16:18                     ` Thomas Petazzoni
2018-11-20 16:19               ` Thomas Petazzoni
2018-11-15 14:37 ` [Buildroot] [PATCH next v4 0/6] Per-package host/target directory support Thomas Petazzoni
2018-11-15 16:41 ` Andreas Naumann
2018-11-16 14:43   ` Thomas Petazzoni
2018-11-19 14:17     ` Andreas Naumann
2018-11-19 13:30 ` 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=20181116144735.19585727@windsurf \
    --to=thomas.petazzoni@bootlin.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