[Buildroot] svn commit: trunk/buildroot/target/u-boot
jacmet at uclibc.org
Tue Jan 6 12:59:39 UTC 2009
>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson at atmel.com> writes:
Ulf> mån 2009-01-05 klockan 21:12 +0100 skrev Peter Korsgaard:
>> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson at atmel.com> writes:
Ulf> The "complex" file name is needed, unless you only
Ulf> work with a single board.
>> I don't get it - Isn't that why we have binaries/<project>?
Ulf> YOu copy things to binaries/PROJECT to have a single directory
Ulf> which you can compress, but if you copy the stuff to
Ulf> the tftp directory then you have a mess.
Ulf> You have to manually rename this.
tftp directory? Is that this ATMEL_COPY_TO thing? I don't recall that
ever being discussed on the list.
Lets just start by making things simple before adding all kinds of
extra stuff. Buildroot should imho just worry about building stuff and
putting it under binaries/<project>, and not install it somewhere for
>> Even so,
>> isn't that the same problem with the other files? (file system images,
Ulf> The kernel is already doing this in the "advanced" makefile.
Ulf> The rootfs should be doing it. and in this case PROJECT Is definitely
Ulf> the right one to use.
Ulf> We obviously need to find a way that does not break the build of
I don't agree. Having things under binaries/<project> is enough.
Ulf> Many targets define BR2_BOARD_NAME in their Config.in's
Ulf> and it may make sense to have a common BR2_BOARD_NAME
Ulf> Then it will be always be defined.
Ulf> Default to "uclibc" is probably OK.
>> Isn't that what we have BR2_PROJECT for?
Ulf> Yes and no,
Ulf> You can use BR2_PROJECT, but if you:
Ulf> make XXXX_config
Ulf> when building u-boot-<VERSION>, it also makes sense to name the binary
Ulf> because regardless of which project you are building,
Ulf> the binary should end up the same.
Ulf> <DATE> is there to give you some kind of revision information
Ulf> so you do not overwrite older working results.
Ulf> It is not perfect, but I think it is good enough.
Sorry, I still don't think this belongs in buildroot.
Bye, Peter Korsgaard
More information about the buildroot