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?
- INSIDE the U-Boot tree
- Designed to be stable, even if U-Boot evolves.
- 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