public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ulf Samuelsson <ulf.samuelsson@atmel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] RFC: "make DESTDIR=xxx install" ?
Date: Sat, 15 Aug 2009 07:01:21 +0200	[thread overview]
Message-ID: <4A864121.908@atmel.com> (raw)
In-Reply-To: <20090813210349.2084C833DBD2@gemini.denx.de>

Wolfgang Denk skrev:
> Dear Ulf Samuelsson,
> 
> In message <4A84779F.7010201@atmel.com> you wrote:
>> This still means that the external buildsystem need to
>> know the internals of u-boot.
> 
> You always have to know the interface to the U-Boot build framework,
> there is no way around that.

Yes, but today U-Boot does not provide any interface for copying
the build result to another place.
People have to dig into internals and if internals change,
then it is likely to be detected by something breaking.

> 
>> There is nothing to stop me calling u-boot with
>>
>> make DESTDIR=/tftpboot/$(MACHINE)
>> TARGET=$(MACHINE)-u-boot-$(U_BOOT_VERSION)-$(REVISION).bin install
> 
> Well, you must know that the U-Boot build framework does support these
> options (or whatever they might be called), assuming they existed.

Yes, but a "make install" is a much more stable interface.

>> If you maintain just a couple of boards, then it is inconvenient to
>> have a subdirectory.
>> If the tftp command in u-boot would fetch from that subdirectory
>> automatically, then it would be less of a pain.
> 
> Well, that's the default for many board configurations - at least for
> all where I have something to say about the implementation.

The proposal does not stop anyone from doing this.
You can do
make DESTDIR=/tftpboot TARGET=u-boot.bin install
make DESTDIR=/tftpboot/$(MACHINE) TARGET=u-boot-bin install
make DESTDIR=/tftpboot/$(MACHINE) \
	TARGET=$(MACHINE)-u-boot-$(U_VER)-$(REV).bin install

I am quite happy to let you put your binaries in the directory
of your choice.


> It's in your hands to make it the default for all your boards, too.
> 
>> I am happy with u-boot.bin as a default,
>> but there is nothing stopping you from adding more parameters
>> like FORMAT=srec or FORMAT=hex.
> 
> I'm not sure if this is the right approch. To me it seems that a small
> wrapper script, optimized for your (or my) purpose, is much more
> flexible and does not pollute the Makefile for features only very
> few people ever need.

I think the open source community has converged on the
"make DESTDIR=<dir> install" method

The important thing is however that the solution is
1) INSIDE the U-Boot tree
2) Designed to be stable, even if U-Boot evolves.
3) Documented so it is easy to use.

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.

You have a unique position as the maintainer of U-Boot.
You know immediately when your scripts needs to be updated.
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!




> Best regards,
> 
> Wolfgang Denk
> 

  reply	other threads:[~2009-08-15  5:01 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 [this message]
2009-08-15  6:32         ` Wolfgang Denk
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=4A864121.908@atmel.com \
    --to=ulf.samuelsson@atmel.com \
    --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