From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] RFC: "make DESTDIR=xxx install" ?
Date: Sat, 15 Aug 2009 08:32:58 +0200 [thread overview]
Message-ID: <20090815063258.6D0BC833DBD2@gemini.denx.de> (raw)
In-Reply-To: <4A864121.908@atmel.com>
Dear Ulf Samuelsson,
In message <4A864121.908@atmel.com> you wrote:
>
> I think the open source community has converged on the
> "make DESTDIR=<dir> install" method
$ cd linux
$ make at91rm9200dk_defconfig
$ make uImage
$ mkdir /tmp/foo
$ mkdir DESTDIR=/tmp/foo install
...
CHK include/linux/compile.h
Kernel: arch/arm/boot/Image is ready
/bin/sh /home/wd/git/linux/work/arch/arm/boot/install.sh 2.6.30-rc8-01295-g06b727a \
arch/arm/boot/Image System.map "/boot"
Installing normal kernel
/home/wd/git/linux/work/arch/arm/boot/install.sh: line 40: /boot/vmlinux-2.6.30-rc8-01295-g06b727a: Permission denied
cp: cannot create regular file `/boot/System.map-2.6.30-rc8-01295-g06b727a': Permission denied
You have to install it yourself
Hmmm... doesn't seem to ork for me.
> The important thing is however that the solution is
Important for what?
> 1) INSIDE the U-Boot tree
> 2) Designed to be stable, even if U-Boot evolves.
> 3) Documented so it is easy to use.
So far you seem to be the only person who needs this.
> If your proposal is that the "wrapper" script is outside u-boot,
> then this is nothing new. This is how it is done today,
> Having wrapper scripts to an unstable interface is an
> accident waiting to happen.
Could you please explain which part of this has been an unstable
interface? As far as I can tell PPCBoot / ARMBoot / U-Boot have
always created the "final binary image" as you called it in the top
level directory, and also it's name has never changed. So what
exactly is unstable here?
> You have a unique position as the maintainer of U-Boot.
I don't. The U-Boot project is driven by a community. If a clear
majority of voices requests something I would have hard times to make
my way.
> You know immediately when your scripts needs to be updated.
Fact is that I am using some scripts that are 10 years old now, and
there has never been need to change them because of changes in the
PPCBoot/ARMBoot/U-Boot "interface" - not even when ARMBoot was forked
from PPCBoot, nor when PPCBoot and ARMBoot were merged back into
U-Boot.
> People working on a build environment does not neccessarily
> have that knowledge, and if not, will run into trouble,
> or rather their customers might.
>
> Maybe I misunderstand you and you propose that the build-script
> should be inside the tree.
> Please clarify!
I still fail to understand which sort of trouble you are talking about.
BTW: the usual way to suggest code changes is to submit a patch as
RFC. If your code looks clean and works fine across architectures,
with and without out-of-tree builds, and if it includes some
documentation I see little reason to reject it. Our general policy
has always been to accept stuff that is technically clean, when it is
useful to at least some, as long as it doesn't hurt all the others.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If programming was easy, they wouldn't need something as complicated
as a human being to do it, now would they?
- L. Wall & R. L. Schwartz, _Programming Perl_
next prev parent reply other threads:[~2009-08-15 6:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-13 15:38 [U-Boot] RFC: "make DESTDIR=xxx install" ? Ulf Samuelsson
2009-08-13 18:06 ` Wolfgang Denk
2009-08-13 20:29 ` Ulf Samuelsson
2009-08-13 21:03 ` Wolfgang Denk
2009-08-15 5:01 ` Ulf Samuelsson
2009-08-15 6:32 ` Wolfgang Denk [this message]
2009-08-15 9:35 ` Ulf Samuelsson
2009-08-15 10:42 ` Wolfgang Denk
2009-08-13 18:06 ` ksi at koi8.net
2009-08-13 20:29 ` Ulf Samuelsson
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=20090815063258.6D0BC833DBD2@gemini.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.de \
/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