From: Michal Sojka <sojka@merica.cz>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] Rebuild busybox when an external config is updated
Date: Fri, 02 May 2014 15:07:40 +0200 [thread overview]
Message-ID: <87ha58corn.fsf@steelpick.2x.cz> (raw)
In-Reply-To: <20140501203103.GA3231@free.fr>
Hi,
thanks for the response.
On Thu, May 01 2014, Yann E. MORIN wrote:
> Thomas, Michal, All,
>
> On 2014-05-01 21:46 +0200, Thomas De Schampheleire spake thusly:
[...]
> We've already talked about it with Thomas P on IRC a while back. Here's
> the transcript of our discussion:
>
> --- Log opened Sun Apr 20 10:52:25 2014
> [--SNIP--]
> 12:02 < kos_tom> opinions about http://patchwork.ozlabs.org/patch/336465/ ?
> 12:04 < y_morin> kos_tom: http://patchwork.ozlabs.org/patch/336465/ <--
> we have PKG-clean-for-reconfigure for this, no?
> 12:05 < y_morin> kos_tom: But most importantly: if we do that for
> busybox, we need to do that for: linux, uClibc and any
> other package for which the user can provide a .config
> 12:06 < y_morin> kos_tom: So, I'd suggest we mark is as "Rejected" and
> ask to modify the manual about his situation.
> 12:09 < kos_tom> y_morin: to me, it's part of the "we don't try to be
> smart and to detect what needs to be rebuilt"
> 12:11 < kos_tom> clean-for-* are internal targets, they are not really
> meant to be used, and they are not documented
> 12:12 < y_morin> kos_tom: Well, we do have rebuild and reconfigure.
>
>
> So, it looks like both Thomas and me thinks this is not really something
> we want. I especially like kos_tom's comment:
>
> it's part of the "we don't try to be smart and to detect what needs
> to be rebuilt"
>
> I still stand by this position.
I could definitely live with this conclusion, but on the other hand I
don't think that adding one more dependency is being "too smart". What
are the drawbacks of adding this functionality? If it is just adding the
same to other packages, I'm willing to do that. Quick grep suggests that
only the following packages have custom config files: at91bootstrap3.mk,
barebox.mk, ubi.mk, linux.mk, busybox.mk, freetype.mk, luarocks.mk,
qt.mk, uclibc.mk.
Or, is there other easy way how to achieve the following? I want to have
all files that influence my root filesystem in a separate repository.
Currently my repo contains the following files:
output/.config # buildroot config
output/.gitignore
output/GNUmakefile # See below
output/busybox.config
output/perm_table.txt
output/postbuild
output/ubinize.cfg
buildroot # Git submodule with buildroot
Cloning this repo and running make in output/ reproducibly rebuilds the
root filesystem. The GNUmakefile is a modified version of automatically
generated Makefile from 'make menuconfig O=../output'. The modification
include changing the -C parameter of make to relative path, setting
environment variables such as BUSYBOX_CONFIG_FILE and updating "my"
busybox config after buildroot innovation. See the full listing below.
This setup allows me the easily track what has been changed in my project
and I don't have to remember running XXX-update-config after every
busybox-menuconfig.
export BUSYBOX_CONFIG_FILE=$(CURDIR)/busybox.config
#export BR2_EXTERNAL=$(CURDIR)/../XXX
lastword = $(word $(words $(1)),$(1))
makedir := $(dir $(call lastword,$(MAKEFILE_LIST)))
MAKEARGS := -C ../buildroot
MAKEARGS += O=$(if $(patsubst /%,,$(makedir)),$(CURDIR)/)$(patsubst %/,%,$(makedir))
MAKEFLAGS += --no-print-directory
.PHONY: all $(MAKECMDGOALS)
all := $(filter-out Makefile,$(MAKECMDGOALS))
_all:
$(MAKE) $(MAKEARGS) $(all)
-$(MAKE) $(MAKEARGS) busybox-update-config
Makefile:;
$(all): _all
@:
%/: _all
@:
Best regards,
-Michal
next prev parent reply other threads:[~2014-05-02 13:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 20:05 [Buildroot] [PATCH] Rebuild busybox when an external config is updated Michal Sojka
2014-05-01 19:46 ` Thomas De Schampheleire
2014-05-01 20:31 ` Yann E. MORIN
2014-05-02 13:07 ` Michal Sojka [this message]
2014-05-02 13:21 ` Gustavo Zacarias
2014-05-02 14:59 ` Danomi Manchego
2014-05-02 15:37 ` Michal Sojka
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=87ha58corn.fsf@steelpick.2x.cz \
--to=sojka@merica.cz \
--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