[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