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 RESEND] core: enhance printvars for variables with newlines
Date: Sun, 16 Dec 2018 16:14:30 +0100	[thread overview]
Message-ID: <20181216161430.1752d2f0@windsurf.home> (raw)
In-Reply-To: <CAOJ2eMcWOj2gvGWHNoZm3ofz2O=LjGj7F02Gy73RyiYP7Pvcmg@mail.gmail.com>

Hello Stefan,

Thanks for the feedback.

On Sun, 16 Dec 2018 16:57:02 +0200, Stefan Becker wrote:

> > I'm jumping back to this very old thread. Could you explain (perhaps
> > re-explain) what you're trying to do ?  
> 
> Modular builds to enable usable CI builds, i.e. any change a developer
> pushes to one of the internal components will be available as a
> flash-able image in less than 5 minutes. CI builds are not possible
> with a monolithic mega meta build system approach like buildroot.

Yes, this I understand.

> > If you need to just re-run a specific step of a specific package, why
> > don't you use "make foo-build", "make foo-rebuild", etc. ?  
> 
> buildroot meta build system assumes that the *whole* source code &
> build tree is available. In a modular build approach that is not the
> case for the "combining" build, e.g. the flash image build, as it only
> receives the build artefacts from the module builds.

I'm not sure to follow you on this last sentence.

But yes, Buildroot assumes that the whole source code and build tree is
available.

> > It seems very hackish to extract the commands that Buildroot executes
> > to execute them outside the context of Buildroot. This doesn't really
> > help to make a case for accepting a patch like you're proposing. Could
> > you first convince us that there is a valid and reasonable use-case,
> > and then we can discuss how to support this use-case with Buildroot.  
> 
> Understandable from the PoV of monolithic meta build system advocates
> like buildroot, yocto, Android, ...
> 
> But I live in the real world and simply can''t ignore Amdahl's law.
> Furthermore I can't, or management doesn't allow me, to spend huge
> amounts of money on build machines that can run monolithic mega meta
> build systems within time spans acceptable for CI (which in the end is
> futile anyway due to Amdahl's law as SW only ever grows in size. Trust
> me, I've been there...). Hence I've chosen a modular build approach to
> address the issue.
> 
> As it became clear that this patch would not be accepted any time
> soon, I reverted it and implemented a different approach based on
> quoted var printout and sed post-processing. While not 100%
> fool-proof, it does work for the few build variables that are required
> for the modular build approach.

You did not answer my question: why didn't you use features of
Buildroot such as "make <pkg>-build" or "make <pkg>-rebuild" ?

How in practice you were using those commands extracted from Buildroot
variables to achieve "modular builds" ?

Best regards,

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

  reply	other threads:[~2018-12-16 15:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAOJ2eMdEHvZeJ6rECyRkzMZN0UYJ2CYK4yMgR9d89P%2B-tWYJYw@mail.gmail.com>
2018-04-16 11:58 ` [Buildroot] [PATCH RESEND] core: enhance printvars for variables with newlines Stefan Becker
2018-04-16 12:28   ` Yann E. MORIN
2018-04-18 22:27   ` Arnout Vandecappelle
2018-04-19  7:14     ` Stefan Becker
2018-04-19  7:40       ` [Buildroot] [PATCH v2] " Stefan Becker
2018-04-19  8:08         ` Yann E. MORIN
2018-12-16 13:54       ` [Buildroot] [PATCH RESEND] " Thomas Petazzoni
2018-12-16 14:57         ` Stefan Becker
2018-12-16 15:14           ` Thomas Petazzoni [this message]
2018-12-16 15:33             ` Stefan Becker
2018-12-16 16:19               ` Stefan Becker
2018-12-17 20:08             ` Trent Piepho
2018-12-18  0:24               ` Carlos Santos
2018-12-18  1:19                 ` Trent Piepho
2018-04-19  7:47     ` Yann E. MORIN
2018-04-19  7:58       ` Stefan Becker

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=20181216161430.1752d2f0@windsurf.home \
    --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