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

Ulf Samuelsson ulf.samuelsson at atmel.com
Sat Aug 15 11:35:11 CEST 2009


Wolfgang Denk skrev:
> 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.

There are plenty examples of where it will work, as you know.

> 
>> The important thing is however that the solution is
> 
> Important for what?

To avoid that external build systems break if anything changes in u-boot.

> 
>> 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 mentioned yourself that Marvell want to have something different
than u-boot.bin

> 
>> 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.

I am not talking about decisions, I am talking about you not running
into problems, if anything changes, because you know it by heart.

> 
>> 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.
> 


More information about the U-Boot mailing list