Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Samuelsson <ulf@atmel.com>
To: buildroot@busybox.net
Subject: [Buildroot] BSP patch
Date: Mon, 29 Jan 2007 01:26:52 +0100	[thread overview]
Message-ID: <578301c7433c$5c2f4910$dcc4af0a@atmel.com> (raw)
In-Reply-To: 20070128221818.GY28221@aon.at

> On Thu, Jan 25, 2007 at 11:44:36PM +0100, Ulf Samuelsson wrote:
>>Author: Ulf Samuelsson
>>Date: 2007-01-25
>>

Bernard, Thanks for taking your time (on a Sunday)
I really appreciate it.

>>Log:
>> Here is my suggestion for supporting different BSP's
>> in the same buildroot structure
>> Add BINARIES_DIR directory, 
>> where resulting binaries can be stored
>> Typically this directory contains a subdirectory for each BSP.
>>
>> Add TARGET_BUILD_DIR directory, where BSP for different
>> boards can be built without destroying results of previous
>> builds. Typically each BSP would build in a subdirectory of 
>> TARGET_BUILD_DIR
>>
>>Modified:
>> Config.in
>> Makefile
>> package/Makefile.in
>>
>>Changeset
>> Config.in
>> Makefile
>> package/Makefile.in
>>
> 
>>Author: Ulf Samuelsson
>>Date: 2007-01-25
>>
>>Log:
>> Here is my suggestion for supporting different BSP's
>> in the same buildroot structure
>> Add BINARIES_DIR directory, 
>> where resulting binaries can be stored
>> Typically this directory contains a subdirectory for each BSP.
>>
>> Add TARGET_BUILD_DIR directory, where BSP for different
>> boards can be built without destroying results of previous builds.
>> Typically each BSP would build in a subdirectory of TARGET_BUILD_DIR
>>
>>Modified:
>> Config.in
>> Makefile
>> package/Makefile.in
>>
>>Changeset
>> Config.in
>> Makefile
>> package/Makefile.in
>>
>>diff -urN buildroot/Config.in buildroot-atmel/Config.in
>>--- buildroot/Config.in 2007-01-25 21:58:40.000000000 +0100
>>+++ buildroot-atmel/Config.in 2007-01-25 23:34:50.000000000 +0100
>>@@ -2,6 +2,17 @@
>> 
>> mainmenu "Buildroot2 Configuration"
>> 
>>+config BR2_BOARDNAME
>>+ string "Boardname"
>>+ default "board"
> 
> That default should be ""

I create a subdirectory under target_build named $(BR2_BOARDNAME)
so having it empty will try to create "target_build//<target_packages/"
which will be wrong.

I think it would be cool to set /etc/hostname to $(BR2_BOARDNAME)
(Part of the "local" patch)
so to be compatible, maybe it should default to "uclibc"?

> and specific target/*/* should set this, no?

Other way around, you define your board at the beginning
and target/$(BR2_BOARDNAME)/* is set.

This way, you can have two targets of the same type
for different customers.
I.E: you can build 

TARGET_BUILD_ARM/customer1/...
TARGET_BUILD_ARM/customer2/...

They are both using the same target information,
but you use the .config to select different options.
(maybe different Linux Kernels)

> 
> Also, please move below HAVE_DOT_CONFIG.
> 

OK.

>>+ help
>>+   Name is used to define subdirectories
>>+   * where the Board Support Packages are built
>>+     (Linux,Root fs Bootmonitor,Utilities etc.)
>>+   * where the resulting binaries are stored.
>>+   Older target may still build in the build_<arch>
>>+   and store binaries in the top directory.
>>+
>> config BR2_HAVE_DOT_CONFIG
>> bool
>> default y
>>@@ -266,6 +277,7 @@
>> depends BR2_arm
>> string "Atmel AT91 Linux Patch download site"
>> default "http://maxim.org.za/AT91RM9200/2.6/"
>>+ help
>>     Patches for the AT91 generated by the Linux community
>>     usually ends up here, courtesy of Andrew Victor
>>     
> hunk not needed anymore.
> 
>>diff -urN buildroot/Makefile buildroot-atmel/Makefile
>>--- buildroot/Makefile 2007-01-25 21:05:25.000000000 +0100
>>+++ buildroot-atmel/Makefile 2007-01-25 23:36:12.000000000 +0100
>>@@ -76,12 +76,16 @@
>> TARGETS_SOURCE:=$(patsubst %,%-source,$(TARGETS))
>> TARGETS_DIRCLEAN:=$(patsubst %,%-dirclean,$(TARGETS))
>> 
>>-world: $(DL_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) $(TARGETS)
>>+world: $(DL_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
>>+ $(TARGET_BUILD_DIR) $(BINARIES_DIR) \
>>+ $(TARGETS)
>>+
>> dirs: $(DL_DIR) $(BUILD_DIR) $(STAGING_DIR)
>> 
>> .PHONY: all world dirs clean dirclean distclean source $(TARGETS) \
>> $(TARGETS_CLEAN) $(TARGETS_DIRCLEAN) $(TARGETS_SOURCE) \
>>- $(DL_DIR) $(BUILD_DIR) $(TOOL_BUILD_DIR) $(STAGING_DIR)
>>+ $(DL_DIR) $(BUILD_DIR) $(TOOL_BUILD_DIR) $(STAGING_DIR) \
>>+ $(TARGET_BUILD_DIR) $(BINARIES_DIR)
>> 
>> #############################################################
>> #
>>@@ -115,6 +119,12 @@
>> -find $(TARGET_DIR) -type d -name CVS | xargs rm -rf
>> -find $(TARGET_DIR) -type d -name .svn | xargs rm -rf
>> 
>>+$(TARGET_BUILD_DIR):
>>+ mkdir -p $(TARGET_BUILD_DIR)
>>+
>>+$(BINARIES_DIR):
>>+ mkdir -p $(BINARIES_DIR)
>>+
> 
> an
> $(DL_DIR) $(BUILD_DIR) $(TOOL_BUILD_DIR) $(STAGING_DIR) \
> $(TARGET_BUILD_DIR) $(BINARIES_DIR):
> mkdir -p $@
> 
> should do, too, i'd say. We could delete the other superfluous rules
> then.

Yes, that makes sense!

> 
>> source: $(TARGETS_SOURCE)
>> 
>> #############################################################
>>diff -urN buildroot/package/Makefile.in buildroot-atmel/package/Makefile.in
>>--- buildroot/package/Makefile.in 2007-01-25 21:05:25.000000000 +0100
>>+++ buildroot-atmel/package/Makefile.in 2007-01-25 23:19:11.000000000 +0100
>>@@ -42,6 +42,8 @@
>> BUILD_DIR:=$(BASE_DIR)/$(TOPDIR_PREFIX)build_$(ARCH)$(ARCH_FPU_SUFFIX)$(TOPDIR_SUFFIX)
>> TARGET_DIR:=$(BUILD_DIR)/root
>> TOOL_BUILD_DIR=$(BASE_DIR)/$(TOPDIR_PREFIX)toolchain_build_$(ARCH)$(ARCH_FPU_SUFFIX)$(TOPDIR_SUFFIX)
>>+TARGET_BUILD_DIR:=$(BASE_DIR)/$(TOPDIR_PREFIX)target_build_$(ARCH)$(ARCH_FPU_SUFFIX)$(TOPDIR_SUFFIX)/$(BR2_BOARDNAME)
>>+BINARIES_DIR:=$(BASE_DIR)/binaries/$(BR2_BOARDNAME)
> 
> shouldn't the BINARIES_DIR rather be only visible in targets/Makefile.in
> and below?  Just curious..
>

BINARIES_DIR will store
linux        - built by target
u-boot     - built by target
utilities     - built by target
rootfs      - built by target

so you are right, but then I dont understand how the Makefile system works
I thought the makefile includes everything and sets all the variables
before the rules are applied.

I put in the package/Makefile.in directory , because there is where the 
other similar stuff is, and it gives you a better overview but
If you want it in the target/Makefile.in, that is no big problem.

Best Regards
Ulf Samuelsson

  reply	other threads:[~2007-01-29  0:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25 22:44 [Buildroot] (no subject) Ulf Samuelsson
2007-01-28 22:18 ` Bernhard Fischer
2007-01-29  0:26   ` Ulf Samuelsson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-02-16  0:25 [Buildroot] difference between this list and gmane? Daniel Ng
2007-02-16  9:36 ` Bernhard Fischer
2007-02-16 10:18   ` [Buildroot] BSP patch Ulf Samuelsson
2007-03-21 22:24 Ulf Samuelsson
2007-03-21 22:43 ` Bernhard Fischer
2007-03-21 23:13   ` Ulf Samuelsson
2007-03-22 13:26     ` Bernhard Fischer
2007-03-22 13:53       ` Ulf Samuelsson
2007-03-22 16:40         ` Erik Andersen
2007-03-22 17:24           ` Ulf Samuelsson
2007-04-30 13:37           ` Ulf Samuelsson
2007-03-29 10:30       ` Ulf Samuelsson
2007-04-10 12:18         ` Bernhard Fischer
2007-04-10 13:22           ` Ulf Samuelsson
2007-04-12 11:02             ` Haavard Skinnemoen
2007-03-21 23:16   ` Ulf Samuelsson
2007-03-22 16:30     ` Erik Andersen
2007-04-16 13:57 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='578301c7433c$5c2f4910$dcc4af0a@atmel.com' \
    --to=ulf@atmel.com \
    --cc=buildroot@busybox.net \
    /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