[U-Boot] RFC: "make DESTDIR=xxx install" ?

Wolfgang Denk wd at denx.de
Sat Aug 15 08:32:58 CEST 2009


Dear Ulf Samuelsson,

In message <4A864121.908 at 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_


More information about the U-Boot mailing list