Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 1/1] Rebuild packages when their external config is updated
Date: Fri, 16 May 2014 23:18:58 +0200	[thread overview]
Message-ID: <20140516211858.GD3466@free.fr> (raw)
In-Reply-To: <1400253776-21759-2-git-send-email-sojka@merica.cz>

Michal, All,

On 2014-05-16 17:22 +0200, Michal Sojka spake thusly:
> Packages like busybox, Linux kernel or uclibc can "import" their
> configuration files from external location specified either in
> buildroot's .config or in an environment variable. Currently, this
> import happens only when the package is built for the first time. When
> the external config changes later, the package is not rebuilt with the
> updated configuration until the corresponding .stamp_configured file
> is manually deleted. This patch changes this to automatically rebuild
> the package, when its external configuration files is newer than
> .stamp_configured.

I think this is still too far-reaching.

If you were to change a source file of your package, then you are
supposed to tell Buildroot that it has to rebiuild the package with
either of:
    make PKG-reconfigure
    make PKG-rebuild

The same goes if you modify the package's .mk file in Buildroot, or
changing an option of the package in Buildroot's own .config.

I don't see how different changing a .config is from changing a source
file, changing the .mk of the package, or changing an option in the
Buildroot's menuconfig.

Changing the .config is like if you were changing the package source
tree, and telling Buildroot to use that with _OVERRIDE_SRCDIR, and we
explicitly state that this should be handled with either 'reconfigure'
or 'rebuild'.

Really, the .config is part of the sources of a package.

If we were to automatically rebuild a package because its .config did
change, then I don.t see why we would not do it when a source file, its
.mk or an option did change as well. And surely we do not want to go
that route, or it would be a mess, and pratically impossible to detect
correctly.

And as Gustavo pointed out, this would even break a system in the case
of uClibc anyway, since reconfiguring uClibc is most probably an ABI
breakage, and would require much more than only rebuilding uClibc alone.

So, I'm still not convinced by this change.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  parent reply	other threads:[~2014-05-16 21:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-16 15:22 [Buildroot] [PATCH v2 0/1] Rebuild packages when their external config is updated Michal Sojka
2014-05-16 15:22 ` [Buildroot] [PATCH v2 1/1] " Michal Sojka
2014-05-16 16:26   ` Gustavo Zacarias
2014-05-16 21:18   ` Yann E. MORIN [this message]
2014-07-29 19:38   ` Thomas Petazzoni
2014-07-29 20:39     ` Thomas De Schampheleire

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=20140516211858.GD3466@free.fr \
    --to=yann.morin.1998@free.fr \
    --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