* [Buildroot] svn commit: trunk/buildroot/docs
@ 2006-11-05 11:21 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2006-11-05 11:21 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2006-11-05 03:21:34 -0800 (Sun, 05 Nov 2006)
New Revision: 16514
Log:
- point to the buildroot ML instead of the uclibc one.
Thanks to Thomas Lundquist for pointing this out.
Modified:
trunk/buildroot/docs/docs.html
trunk/buildroot/docs/subversion.html
Changeset:
Modified: trunk/buildroot/docs/docs.html
===================================================================
--- trunk/buildroot/docs/docs.html 2006-11-05 00:47:38 UTC (rev 16513)
+++ trunk/buildroot/docs/docs.html 2006-11-05 11:21:34 UTC (rev 16514)
@@ -20,7 +20,7 @@
<li>
If you find that you need help with buildroot, you can ask for help on the
- <a href= "lists/uClibc/">uClibc mailing list</a> at uclibc at mail.uclibc.org.
+ <a href= "lists/uClibc/">buildroot mailing list</a> at buildroot at mail.uclibc.org.
In addition the BusyBox, uClibc, and buildroot developers are also known to
hang out on the uClibc IRC channel: #uclibc on irc.freenode.net.
</li>
Modified: trunk/buildroot/docs/subversion.html
===================================================================
--- trunk/buildroot/docs/subversion.html 2006-11-05 00:47:38 UTC (rev 16513)
+++ trunk/buildroot/docs/subversion.html 2006-11-05 11:21:34 UTC (rev 16514)
@@ -31,8 +31,9 @@
Because you've only been granted anonymous access to the tree, you won't be
able to commit any changes. Changes can be submitted for inclusion by posting
-them to the uClibc mailing list or to the <a href="http://bugs.uclibc.org/">Bug
-and Patch Tracking System</a>. For those that are actively contributing <a
+them to the buildroot mailing list or to the <a
+href="http://bugs.uclibc.org/">Bug and Patch Tracking System</a>.
+For those that are actively contributing <a
href="developer.html">Subversion commit access</a> can be made available.
<!--#include file="footer.html" -->
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2006-12-22 12:11 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2006-12-22 12:11 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2006-12-22 04:11:06 -0800 (Fri, 22 Dec 2006)
New Revision: 17048
Log:
- add some more useful hints
Modified:
trunk/buildroot/docs/README
Changeset:
Modified: trunk/buildroot/docs/README
===================================================================
--- trunk/buildroot/docs/README 2006-12-22 11:47:19 UTC (rev 17047)
+++ trunk/buildroot/docs/README 2006-12-22 12:11:06 UTC (rev 17048)
@@ -13,5 +13,23 @@
-Erik
+More finegrained configuration:
+===============================
+
+You can specify a config-file for uClibc:
+$ make UCLIBC_CONFIG_FILE=/my/uClibc.config
+
+To use a non-standart host-compiler (if you do not have 'gcc'),
+make sure that the compiler is in your PATH and that the library paths are
+setup properly, if your compiler is built dynamically:
+$ make HOSTCC=gcc-4.3.orig HOSTCXX=gcc-4.3-mine
+
+Depending on your configuration, there are some targets you can use to
+use menuconfig of certain packages. This includes:
+$ make HOSTCC=gcc-4.3 linux26-menuconfig
+$ make HOSTCC=gcc-4.3 uclibc-menuconfig
+$ make HOSTCC=gcc-4.3 busybox-menuconfig
+
Please feed suggestions, bug reports, insults, and bribes back to:
Erik Andersen <andersen@codepoet.org>
+or the buildroot mailing list.
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-17 10:07 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-17 10:07 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-17 02:07:01 -0800 (Wed, 17 Jan 2007)
New Revision: 17333
Log:
- add short section about offline-builds
Modified:
trunk/buildroot/docs/README
Changeset:
Modified: trunk/buildroot/docs/README
===================================================================
--- trunk/buildroot/docs/README 2007-01-17 00:48:32 UTC (rev 17332)
+++ trunk/buildroot/docs/README 2007-01-17 10:07:01 UTC (rev 17333)
@@ -13,6 +13,19 @@
-Erik
+Offline build:
+==============
+
+In order to do an offline-build (not connected to the net), fetch all
+selected source by issuing a
+$ make source
+
+before you disconnect.
+If your build-host is never connected, then you have to copy buildroot
+and your toplevel .config to a machine that has an internet-connection
+and issue "make source" there, then copy the content of your dl/ dir to
+the build-host.
+
More finegrained configuration:
===============================
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-19 9:24 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-19 9:24 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-19 01:24:39 -0800 (Fri, 19 Jan 2007)
New Revision: 17373
Log:
- make sure that URLs are standard conforming
Let's see if the date property works..
Modified:
trunk/buildroot/docs/buildroot.html
trunk/buildroot/docs/header.html
trunk/buildroot/docs/lists.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-01-19 02:04:09 UTC (rev 17372)
+++ trunk/buildroot/docs/buildroot.html 2007-01-19 09:24:39 UTC (rev 17373)
@@ -18,7 +18,7 @@
<p>Usage and documentation by Thomas Petazzoni. Contributions from
Karsten Kruse, Ned Ludd, Martin Herren.</p>
- <p><small>Last modification : $Id: buildroot-documentation.html,v 1.2 2004/12/28 19:15:20 andersen Exp $</small></p>
+ <p><small>$LastChangedDate$</small></p>
<ul>
<li><a href="#about">About Buildroot</a></li>
@@ -57,7 +57,7 @@
case, <code>gcc</code>), binary utils like assembler and linker
(in our case, <code>binutils</code>) and a C standard library (for
example <a href="http://www.gnu.org/software/libc/libc.html">GNU
- Libc</a>, <a href="http://www.uclibc.org">uClibc</a> or <a
+ Libc</a>, <a href="http://www.uclibc.org/">uClibc</a> or <a
href="http://www.fefe.de/dietlibc/">dietlibc</a>). The system
installed on your development station certainly already has a
compilation toolchain that you can use to compile application that
@@ -226,7 +226,7 @@
configuration</h2>
<p>Just like <a href="#custom_busybox">BusyBox</a>, <a
- href="http://www.uclibc.org">uClibc</a> offers a lot of
+ href="http://www.uclibc.org/">uClibc</a> offers a lot of
configuration options. They allow to select various
functionalities, depending on your needs and limitations.</p>
Property changes on: trunk/buildroot/docs/buildroot.html
___________________________________________________________________
Name: svn:keywords
+ Date
Modified: trunk/buildroot/docs/header.html
===================================================================
--- trunk/buildroot/docs/header.html 2007-01-19 02:04:09 UTC (rev 17372)
+++ trunk/buildroot/docs/header.html 2007-01-19 09:24:39 UTC (rev 17373)
@@ -60,7 +60,7 @@
<br><a href="http://www.scratchbox.org/">Scratchbox</a>
<br><a href="http://openembedded.org/">OpenEmbedded</a>
<br><a href="http://www.ucdot.org/">uCdot</a>
- <br><a href="http://www.linuxdevices.com">LinuxDevices</a>
+ <br><a href="http://www.linuxdevices.com/">LinuxDevices</a>
<br><a href="http://slashdot.org/">Slashdot</a>
<br><a href="http://freshmeat.net/">Freshmeat</a>
<br><a href="http://linuxtoday.com/">Linux Today</a>
Modified: trunk/buildroot/docs/lists.html
===================================================================
--- trunk/buildroot/docs/lists.html 2007-01-19 02:04:09 UTC (rev 17372)
+++ trunk/buildroot/docs/lists.html 2007-01-19 09:24:39 UTC (rev 17373)
@@ -26,7 +26,7 @@
<br>
<input type="submit" name="sa" value="search the mailing list archives">
<br>
-<a href="http://www.google.com"><img src="http://www.google.com/logos/Logo_25wht.gif" border="0" alt="Google" height="32" width="75" align="middle"></a>
+<a href="http://www.google.com/"><img src="http://www.google.com/logos/Logo_25wht.gif" border="0" alt="Google" height="32" width="75" align="middle"></a>
<br>
</form>
</center>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-19 9:47 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-19 9:47 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-19 01:47:29 -0800 (Fri, 19 Jan 2007)
New Revision: 17374
Log:
- Correct some typos
- Add some more explanation to the -clean and -dirclean targets
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-01-19 09:24:39 UTC (rev 17373)
+++ trunk/buildroot/docs/buildroot.html 2007-01-19 09:47:29 UTC (rev 17374)
@@ -36,7 +36,7 @@
<li><a href="#downloaded_packages">Location of downloaded packages</a></li>
<li><a href="#add_software">Extending Buildroot with more
Software</a></li>
- <li><a href="#links">Ressources</a></li>
+ <li><a href="#links">Resources</a></li>
</ul>
<h2><a name="about" id="about"></a>About Buildroot</h2>
@@ -455,9 +455,9 @@
4 #
5 #############################################################
6 FOO_VERSION:=1.0
- 7 FOO_SOURCE:=less-$(FOO_VERSION).tar.gz
+ 7 FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
8 FOO_SITE:=http://www.foosoftware.org/downloads
- 9 FOO_DIR:=$(BUILD_DIR)/less-$(FOO_VERSION)
+ 9 FOO_DIR:=$(BUILD_DIR)/foo-$(FOO_VERSION)
10 FOO_BINARY:=foo
11 FOO_TARGET_BINARY:=usr/bin/foo
12
@@ -466,10 +466,10 @@
15
16 $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
17 $(ZCAT) $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
- 18 touch $(FOO_DIR)/.source
+ 18 touch $@
19
20 $(FOO_DIR)/.configured: $(FOO_DIR)/.source
- 21 (cd $(FOO_DIR); \
+ 21 (cd $(FOO_DIR); rm -rf config.cache ; \
22 $(TARGET_CONFIGURE_OPTS) \
23 CFLAGS="$(TARGET_CFLAGS)" \
24 ./configure \
@@ -479,7 +479,7 @@
28 --prefix=/usr \
29 --sysconfdir=/etc \
30 );
- 31 touch $(FOO_DIR)/.configured;
+ 31 touch $@
32
33 $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
34 $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
@@ -600,14 +600,21 @@
<p>Line 42 defines a simple target that only downloads the code
source. This is not used during normal operation of Buildroot, but
- might be useful.</p>
+ is needed if you intend to download all required sources at once
+ for later offline build. Note that if you add a new package providing
+ a <code>foo-source</code> target is <i>mandatory</i> to support
+ users that wish to do offline-builds. Furthermore it eases checking
+ if all package-sources are downloadable.</p>
- <p>Lignes 44-46 define a simple target to clean the software build
- by calling the <i>Makefiles</i> with the appropriate option.</p>
+ <p>Lines 44-46 define a simple target to clean the software build
+ by calling the <i>Makefiles</i> with the appropriate option.<br>
+ The <code>clean</code> target should run <code>make clean</code>
+ on $(BUILD_DIR)/package-version and MUST uninstall all files of the
+ package from $(STAGING_DIR) and from $(TARGET_DIR).</p>
<p>Lines 48-49 define a simple target to completely remove the
directory in which the software was uncompressed, configured and
- compiled.</p>
+ compiled. This target MUST completely rm $(BUILD_DIR)/package-version.</p>
<p>Lines 51-58 adds the target <code>foo</code> to the list
of targets to be compiled by Buildroot by first checking if
@@ -630,7 +637,7 @@
<p>If you package software that might be useful for other persons,
don't forget to send a patch to Buildroot developers !</p>
- <h2><a name="links" id="links"></a>Ressources</h2>
+ <h2><a name="links" id="links"></a>Resources</h2>
<p>To learn more about Buildroot you can visit these
websites:</p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-19 10:57 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-19 10:57 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-19 02:57:03 -0800 (Fri, 19 Jan 2007)
New Revision: 17375
Log:
- add some anchors to the sample makefile to make ease navigation
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-01-19 09:47:29 UTC (rev 17374)
+++ trunk/buildroot/docs/buildroot.html 2007-01-19 10:57:03 UTC (rev 17375)
@@ -449,64 +449,64 @@
afterwards.</p>
<pre>
- 1 #############################################################
- 2 #
- 3 # foo
- 4 #
- 5 #############################################################
- 6 FOO_VERSION:=1.0
- 7 FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
- 8 FOO_SITE:=http://www.foosoftware.org/downloads
- 9 FOO_DIR:=$(BUILD_DIR)/foo-$(FOO_VERSION)
- 10 FOO_BINARY:=foo
- 11 FOO_TARGET_BINARY:=usr/bin/foo
- 12
- 13 $(DL_DIR)/$(FOO_SOURCE):
- 14 $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)
- 15
- 16 $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
- 17 $(ZCAT) $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
- 18 touch $@
- 19
- 20 $(FOO_DIR)/.configured: $(FOO_DIR)/.source
- 21 (cd $(FOO_DIR); rm -rf config.cache ; \
- 22 $(TARGET_CONFIGURE_OPTS) \
- 23 CFLAGS="$(TARGET_CFLAGS)" \
- 24 ./configure \
- 25 --target=$(GNU_TARGET_NAME) \
- 26 --host=$(GNU_TARGET_NAME) \
- 27 --build=$(GNU_HOST_NAME) \
- 28 --prefix=/usr \
- 29 --sysconfdir=/etc \
- 30 );
- 31 touch $@
- 32
- 33 $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
- 34 $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
- 35
- 36 $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
- 37 $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
- 38 rm -Rf $(TARGET_DIR)/usr/man
- 39
- 40 foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
- 41
- 42 foo-source: $(DL_DIR)/$(FOO_SOURCE)
- 43
- 44 foo-clean:
- 45 $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
- 46 -$(MAKE) -C $(FOO_DIR) clean
- 47
- 48 foo-dirclean:
- 49 rm -rf $(FOO_DIR)
- 50
- 51 #############################################################
- 52 #
- 53 # Toplevel Makefile options
- 54 #
- 55 #############################################################
- 56 ifeq ($(strip $(BR2_PACKAGE_FOO)),y)
- 57 TARGETS+=foo
- 58 endif
+ <a name="line1" id="line1">1</a> #############################################################
+ <a name="line2" id="line2">2</a> #
+ <a name="line3" id="line3">3</a> # foo
+ <a name="line4" id="line4">4</a> #
+ <a name="line5" id="line5">5</a> #############################################################
+ <a name="line6" id="line6">6</a> FOO_VERSION:=1.0
+ <a name="line7" id="line7">7</a> FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
+ <a name="line8" id="line8">8</a> FOO_SITE:=http://www.foosoftware.org/downloads
+ <a name="line9" id="line9">9</a> FOO_DIR:=$(BUILD_DIR)/foo-$(FOO_VERSION)
+ <a name="line10" id="line10">10</a> FOO_BINARY:=foo
+ <a name="line11" id="line11">11</a> FOO_TARGET_BINARY:=usr/bin/foo
+ <a name="line12" id="line12">12</a>
+ <a name="line13" id="line13">13</a> $(DL_DIR)/$(FOO_SOURCE):
+ <a name="line14" id="line14">14</a> $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)
+ <a name="line15" id="line15">15</a>
+ <a name="line16" id="line16">16</a> $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
+ <a name="line17" id="line17">17</a> $(ZCAT) $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
+ <a name="line18" id="line18">18</a> touch $@
+ <a name="line19" id="line19">19</a>
+ <a name="line20" id="line20">20</a> $(FOO_DIR)/.configured: $(FOO_DIR)/.source
+ <a name="line21" id="line21">21</a> (cd $(FOO_DIR); rm -rf config.cache ; \
+ <a name="line22" id="line22">22</a> $(TARGET_CONFIGURE_OPTS) \
+ <a name="line23" id="line23">23</a> CFLAGS="$(TARGET_CFLAGS)" \
+ <a name="line24" id="line24">24</a> ./configure \
+ <a name="line25" id="line25">25</a> --target=$(GNU_TARGET_NAME) \
+ <a name="line26" id="line26">26</a> --host=$(GNU_TARGET_NAME) \
+ <a name="line27" id="line27">27</a> --build=$(GNU_HOST_NAME) \
+ <a name="line28" id="line28">28</a> --prefix=/usr \
+ <a name="line29" id="line29">29</a> --sysconfdir=/etc \
+ <a name="line30" id="line30">30</a> );
+ <a name="line31" id="line31">31</a> touch $@
+ <a name="line32" id="line32">32</a>
+ <a name="line33" id="line33">33</a> $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
+ <a name="line34" id="line34">34</a> $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
+ <a name="line35" id="line35">35</a>
+ <a name="line36" id="line36">36</a> $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
+ <a name="line37" id="line37">37</a> $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
+ <a name="line38" id="line38">38</a> rm -Rf $(TARGET_DIR)/usr/man
+ <a name="line39" id="line39">39</a>
+ <a name="line40" id="line40">40</a> foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
+ <a name="line41" id="line41">41</a>
+ <a name="line42" id="line42">42</a> foo-source: $(DL_DIR)/$(FOO_SOURCE)
+ <a name="line43" id="line43">43</a>
+ <a name="line44" id="line44">44</a> foo-clean:
+ <a name="line45" id="line45">45</a> $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
+ <a name="line46" id="line46">46</a> -$(MAKE) -C $(FOO_DIR) clean
+ <a name="line47" id="line47">47</a>
+ <a name="line48" id="line48">48</a> foo-dirclean:
+ <a name="line49" id="line49">49</a> rm -rf $(FOO_DIR)
+ <a name="line50" id="line50">50</a>
+ <a name="line51" id="line51">51</a> #############################################################
+ <a name="line52" id="line52">52</a> #
+ <a name="line53" id="line53">53</a> # Toplevel Makefile options
+ <a name="line54" id="line54">54</a> #
+ <a name="line55" id="line55">55</a> #############################################################
+ <a name="line56" id="line56">56</a> ifeq ($(strip $(BR2_PACKAGE_FOO)),y)
+ <a name="line57" id="line57">57</a> TARGETS+=foo
+ <a name="line58" id="line58">58</a> endif
</pre>
@@ -516,7 +516,7 @@
the other <code>*.mk</code> files in the <code>package</code>
directory.</p>
- <p>At lines 6-11, a couple of useful variables are defined :</p>
+ <p>At lines <a href="#line6">6-11</a>, a couple of useful variables are defined :</p>
<ul>
@@ -545,21 +545,21 @@
</ul>
- <p>Lines 13-14 defines a target that downloads the tarball from
+ <p>Lines <a href="#line13">13-14</a> defines a target that downloads the tarball from
the remote site to the download directory
(<code>DL_DIR</code>).</p>
- <p>Lines 16-18 defines a target and associated rules that
+ <p>Lines <a href="#line16">16-18</a> defines a target and associated rules that
uncompress the downloaded tarball. As you can see, this target
depends on the tarball file, so that the previous target (line
- 13-14) is called before executing the rules of the current
+ <a href="#line13">13-14</a>) is called before executing the rules of the current
target. Uncompressing is followed by <i>touching</i> a hidden file
to mark the software has having been uncompressed. This trick is
used everywhere in Buildroot <i>Makefile</i> to split steps
(download, uncompress, configure, compile, install) while still
having correct dependencies.</p>
- <p>Lines 20-31 defines a target and associated rules that
+ <p>Lines <a href="#line20">20-31</a> defines a target and associated rules that
configures the software. It depends on the previous target (the
hidden <code>.source</code> file) so that we are sure the software has
been uncompressed. In order to configure it, it basically runs the
@@ -571,14 +571,14 @@
filesystem. Finally it creates a <code>.configured</code> file to
mark the software as configured.</p>
- <p>Lines 33-34 defines a target and a rule that compiles the
+ <p>Lines <a href="#line33">33-34</a> defines a target and a rule that compiles the
software. This target will create the binary file in the
compilation directory, and depends on the software being already
configured (hence the reference to the <code>.configured</code>
file). It basically runs <code>make</code> inside the source
directory.</p>
- <p>Lines 36-38 defines a target and associated rules that install
+ <p>Lines <a href="#line36">36-38</a> defines a target and associated rules that install
the software inside the target filesystem. It depends on the
binary file in the source directory, to make sure the software has
been compiled. It uses the <code>install</code> target of the
@@ -589,7 +589,7 @@
<code>/usr/man</code> directory inside the target filesystem is
removed to save space.</p>
- <p>Line 40 defines the main target of the software, the one
+ <p>Line <a href="#line40">40</a> defines the main target of the software, the one
that will be eventually be used by the top level
<code>Makefile</code> to download, compile, and then install
this package. This target should first of all depends on all
@@ -598,7 +598,7 @@
final binary. This last dependency will call all previous
dependencies in the correct order. </p>
- <p>Line 42 defines a simple target that only downloads the code
+ <p>Line <a href="#line42">42</a> defines a simple target that only downloads the code
source. This is not used during normal operation of Buildroot, but
is needed if you intend to download all required sources at once
for later offline build. Note that if you add a new package providing
@@ -606,24 +606,24 @@
users that wish to do offline-builds. Furthermore it eases checking
if all package-sources are downloadable.</p>
- <p>Lines 44-46 define a simple target to clean the software build
+ <p>Lines <a href="#line44">44-46</a> define a simple target to clean the software build
by calling the <i>Makefiles</i> with the appropriate option.<br>
The <code>clean</code> target should run <code>make clean</code>
on $(BUILD_DIR)/package-version and MUST uninstall all files of the
package from $(STAGING_DIR) and from $(TARGET_DIR).</p>
- <p>Lines 48-49 define a simple target to completely remove the
+ <p>Lines <a href="#line48">48-49</a> define a simple target to completely remove the
directory in which the software was uncompressed, configured and
compiled. This target MUST completely rm $(BUILD_DIR)/package-version.</p>
- <p>Lines 51-58 adds the target <code>foo</code> to the list
+ <p>Lines <a href="#line51">51-58</a> adds the target <code>foo</code> to the list
of targets to be compiled by Buildroot by first checking if
the configuration option for this package has been enabled
using the configuration tool, and if so then "subscribes"
this package to be compiled by adding it to the TARGETS
global variable. The name added to the TARGETS global
variable is the name of this package's target, as defined on
- line 40, which is used by Buildroot to download, compile, and
+ line <a href="#line40">40</a>, which is used by Buildroot to download, compile, and
then install this package.</p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-19 11:00 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-19 11:00 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-19 03:00:05 -0800 (Fri, 19 Jan 2007)
New Revision: 17376
Log:
- add missing space
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-01-19 10:57:03 UTC (rev 17375)
+++ trunk/buildroot/docs/buildroot.html 2007-01-19 11:00:05 UTC (rev 17376)
@@ -563,7 +563,7 @@
configures the software. It depends on the previous target (the
hidden <code>.source</code> file) so that we are sure the software has
been uncompressed. In order to configure it, it basically runs the
- well-known <code>./configure</code>script. As we may be doing
+ well-known <code>./configure</code> script. As we may be doing
cross-compilation, <code>target</code>, <code>host</code> and
<code>build</code> arguments are given. The prefix is also set to
<code>/usr</code>, not because the software will be installed in
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-19 12:35 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-19 12:35 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-19 04:35:26 -0800 (Fri, 19 Jan 2007)
New Revision: 17378
Log:
- some minor corrections
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-01-19 11:12:46 UTC (rev 17377)
+++ trunk/buildroot/docs/buildroot.html 2007-01-19 12:35:26 UTC (rev 17378)
@@ -395,7 +395,7 @@
<p>If you want to use the generated toolchain for other purposes,
you can configure Buildroot to generate it elsewhere using the
- option of the configuration tool : <code>Build options ->
+ option of the configuration tool : <code>Build options ->
Toolchain and header file location</code>, which defaults to
<code>$(BUILD_DIR)/staging_dir/</code>.</p>
@@ -434,7 +434,9 @@
bool "foo"
default n
help
- This is a comment that explains what foo is.
+ This is a comment that explains what foo is.
+
+ http://foosoftware.org/foo/
</pre>
<p>Of course, you can add other options to configure particular
@@ -607,7 +609,7 @@
if all package-sources are downloadable.</p>
<p>Lines <a href="#line44">44-46</a> define a simple target to clean the software build
- by calling the <i>Makefiles</i> with the appropriate option.<br>
+ by calling the <i>Makefiles</i> with the appropriate option.
The <code>clean</code> target should run <code>make clean</code>
on $(BUILD_DIR)/package-version and MUST uninstall all files of the
package from $(STAGING_DIR) and from $(TARGET_DIR).</p>
@@ -650,12 +652,10 @@
</div>
<!--
-->
- <td>
- <a href="http://validator.w3.org/check?uri=referer"><img
- border="0" height="31" width="88"
- src="images/valid-html401.png"
- alt="Valid HTML"></a>
- </td>
+ <a href="http://validator.w3.org/check?uri=referer"><img
+ border="0" height="31" width="88"
+ src="images/valid-html401.png"
+ alt="Valid HTML"></img></a>
<!--
-->
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-19 13:32 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-19 13:32 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-19 05:32:21 -0800 (Fri, 19 Jan 2007)
New Revision: 17379
Log:
- add some more documentation
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-01-19 12:35:26 UTC (rev 17378)
+++ trunk/buildroot/docs/buildroot.html 2007-01-19 13:32:21 UTC (rev 17379)
@@ -12,15 +12,16 @@
<body>
<div class="main">
<div class="titre">
- <h1><a href="http://buildroot.uclibc.org/">Buildroot</a></h1>
+ <h1>Buildroot</h1>
</div>
- <p>Usage and documentation by Thomas Petazzoni. Contributions from
- Karsten Kruse, Ned Ludd, Martin Herren.</p>
+ <p><a href="http://buildroot.uclibc.org/">Buildroot</a> usage and documentation by Thomas Petazzoni. Contributions from
+ Karsten Kruse, Ned Ludd, Martin Herren and others.</p>
<p><small>$LastChangedDate$</small></p>
<ul>
+
<li><a href="#about">About Buildroot</a></li>
<li><a href="#download">Obtaining Buildroot</a></li>
<li><a href="#using">Using Buildroot</a></li>
@@ -41,7 +42,7 @@
<h2><a name="about" id="about"></a>About Buildroot</h2>
- <p>Buildroot is a set of Makefiles and patches that allows to easily
+ <p>Buildroot is a set of Makefiles and patches that allow to easily
generate both a cross-compilation toolchain and a root filesystem for your
target. The cross-compilation toolchain uses uClibc (<a href=
"http://www.uclibc.org/">http://www.uclibc.org/</a>), a tiny C standard
@@ -65,9 +66,9 @@
toolchain runs on an x86 processor and generates code for a x86
processor. Under most Linux systems, the compilation toolchain
uses the GNU libc as C standard library. This compilation
- toolchain is called the "host compilation toolchain", and more
+ toolchain is called the "host compilation toolchain", and more
generally, the machine on which it is running, and on which you're
- working is called the "host system". The compilation toolchain is
+ working is called the "host system". The compilation toolchain is
provided by your distribution, and Buildroot has nothing to do
with it.</p>
@@ -116,7 +117,7 @@
href="http://buildroot.uclibc.org/downloads/snapshots/">http://buildroot.uclibc.org/downloads/snapshots/</a>.</p>
<p>To download Buildroot using SVN, you can simply follow
- the rules described on the "Accessing SVN"-page (<a href=
+ the rules described on the "Accessing SVN"-page (<a href=
"http://buildroot.uclibc.org/subversion.html">http://buildroot.uclibc.org/subversion.html</a>)
of the uClibc buildroot website (<a href=
"http://buildroot.uclibc.org">http://buildroot.uclibc.org</a>), and download the
@@ -133,7 +134,7 @@
in the Linux Kernel (<a href=
"http://www.kernel.org/">http://www.kernel.org/</a>) or in Busybox
(<a href="http://www.busybox.org/">http://www.busybox.org/</a>). Note that
- you can run everything as a normal user. There is no need to be root to
+ you can build everything as a normal user. There is no need to be root to
configure and use Buildroot. The first step is to run the configuration
assistant:</p>
@@ -161,6 +162,39 @@
selected in the <code>Target options</code> section of the configuration
tool.</p>
+ <p>If you intend to do an offline-build and just want to download all
+ sources that you previously selected in "make menuconfig" then
+ issue:</p>
+<pre>
+ $ make source
+</pre>
+ <p>You can now disconnect or copy the content of your <code>dl</code>
+ directory to the build-host.</p>
+
+ <h3><a name="environment_variables" id="environment_variables"></a>
+ Environment variables</h3>
+
+ <p>Buildroot optionally honors some environment variables that are passed
+ to <code>make</code> :</p>
+ <ul>
+ <li>HOSTCXX
+ <li>HOSTCC
+ <li>UCLIBC_CONFIG_FILE=<path/to/.config>
+ <li>BUSYBOX_CONFIG_FILE=<path/to/.config>
+ </ul>
+
+ <p>An example that uses config files located in the toplevel directory and
+ in your $HOME:</p>
+<pre>
+$ make UCLIBC_CONFIG_FILE=uClibc.config BUSYBOX_CONFIG_FILE=$HOME/bb.config
+</pre>
+
+ <p>If you want to use a compiler other than the default <code>gcc</code>
+ or <code>g++</code> for building helper-binaries on your host, then do</p>
+<pre>
+$ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
+</pre>
+
<h2><a name="custom_targetfs" id="custom_targetfs"></a>Customizing the
target filesystem</h2>
@@ -198,7 +232,8 @@
<h2><a name="custom_busybox" id="custom_busybox"></a>Customizing the
Busybox configuration</h2>
- <p>Busybox is very configurable, and you may want to customize it. You can
+ <p><a href="http://www.busybox.net/">Busybox</a> is very configurable, and
+ you may want to customize it. You can
follow these simple steps to do it. It's not an optimal way, but it's
simple and it works.</p>
@@ -206,21 +241,18 @@
<li>Make a first compilation of buildroot with busybox without trying to
customize it.</li>
- <li>Go into <code>build_ARCH/busybox/</code> and run <code>make
- menuconfig</code>. The nice configuration tool appears and you can
+ <li>Invoke <code>make busybox-menuconfig</code>.
+ The nice configuration tool appears and you can
customize everything.</li>
- <li>Copy the <code>.config</code> file to
- <code>package/busybox/busybox.config</code> so that your customized
- configuration will remains even if you remove the cross-compilation
- toolchain.</li>
-
<li>Run the compilation of buildroot again.</li>
</ol>
<p>Otherwise, you can simply change the
<code>package/busybox/busybox.config</code> file if you know the options
you want to change without using the configuration tool.</p>
+ <p>If you want to use an existing config file for busybox, then see
+ section <a href="#environment_variables">environment variables</a>.</p>
<h2><a name="custom_uclibc" id="custom_uclibc"></a>Customizing the uClibc
configuration</h2>
@@ -238,9 +270,8 @@
<li>Make a first compilation of buildroot without trying to
customize uClibc.</li>
- <li>Go into the directory
- <code>toolchain_build_ARCH/uClibc/</code> and run <code>make
- menuconfig</code>. The nice configuration assistant, similar to
+ <li>Invoke <code>make uclibc-menuconfig</code>.
+ The nice configuration assistant, similar to
the one used in the Linux Kernel or in Buildroot appears. Make
your configuration as appropriate.</li>
@@ -260,6 +291,9 @@
<code>toolchain/uClibc/uClibc.config-locale</code> without running
the configuration assistant.</p>
+ <p>If you want to use an existing config file for uclibc, then see
+ section <a href="#environment_variables">environment variables</a>.</p>
+
<h2><a name="buildroot_innards" id="buildroot_innards"></a>How Buildroot
works</h2>
@@ -343,8 +377,8 @@
<li>Add the <code>TARGETS</code> dependency. This should generally check
if the configuration option for this package is enabled, and if so then
- "subscribe" this package to be compiled by adding it to the TARGETS
- global variable.</li>
+ "subscribe" this package to be compiled by adding it to the
+ TARGETS global variable.</li>
</ol>
<h2><a name="using_toolchain" id="using_toolchain"></a>Using the
@@ -367,7 +401,7 @@
<code>~/buildroot/</code>) :</p>
<pre>
-export PATH=$PATH:~/buildroot/build_mips/staging_dir/bin/
+export PATH="$PATH:~/buildroot/build_mips/staging_dir/bin/"
</pre>
<p>Then you can simply do :</p>
@@ -621,7 +655,7 @@
<p>Lines <a href="#line51">51-58</a> adds the target <code>foo</code> to the list
of targets to be compiled by Buildroot by first checking if
the configuration option for this package has been enabled
- using the configuration tool, and if so then "subscribes"
+ using the configuration tool, and if so then "subscribes"
this package to be compiled by adding it to the TARGETS
global variable. The name added to the TARGETS global
variable is the name of this package's target, as defined on
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-19 19:20 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-19 19:20 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-19 11:20:07 -0800 (Fri, 19 Jan 2007)
New Revision: 17387
Log:
- explicitely mention -clean and -dirclean targets so it is easier to search for them
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-01-19 19:14:33 UTC (rev 17386)
+++ trunk/buildroot/docs/buildroot.html 2007-01-19 19:20:07 UTC (rev 17387)
@@ -644,13 +644,13 @@
<p>Lines <a href="#line44">44-46</a> define a simple target to clean the software build
by calling the <i>Makefiles</i> with the appropriate option.
- The <code>clean</code> target should run <code>make clean</code>
+ The <code>-clean</code> target should run <code>make clean</code>
on $(BUILD_DIR)/package-version and MUST uninstall all files of the
package from $(STAGING_DIR) and from $(TARGET_DIR).</p>
<p>Lines <a href="#line48">48-49</a> define a simple target to completely remove the
directory in which the software was uncompressed, configured and
- compiled. This target MUST completely rm $(BUILD_DIR)/package-version.</p>
+ compiled. The <code>-dirclean</code> target MUST completely rm $(BUILD_DIR)/package-version.</p>
<p>Lines <a href="#line51">51-58</a> adds the target <code>foo</code> to the list
of targets to be compiled by Buildroot by first checking if
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-19 19:21 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-19 19:21 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-19 11:21:03 -0800 (Fri, 19 Jan 2007)
New Revision: 17388
Log:
- remove validator
Modified:
trunk/buildroot/docs/header.html
Changeset:
Modified: trunk/buildroot/docs/header.html
===================================================================
--- trunk/buildroot/docs/header.html 2007-01-19 19:20:07 UTC (rev 17387)
+++ trunk/buildroot/docs/header.html 2007-01-19 19:21:03 UTC (rev 17388)
@@ -68,11 +68,9 @@
<br><a href="http://www.tldp.org/HOWTO">Linux HOWTOs</a>
<!--
--->
<a href="http://validator.w3.org/check/referer"><img
src="/images/valid-html401.png" height="31" width="88"
align="left" border="0" alt="Valid HTML"></a>
-<!--
-->
</td>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-19 19:28 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-19 19:28 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-19 11:28:39 -0800 (Fri, 19 Jan 2007)
New Revision: 17389
Log:
- duh. add missing listentry stop markers
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-01-19 19:21:03 UTC (rev 17388)
+++ trunk/buildroot/docs/buildroot.html 2007-01-19 19:28:39 UTC (rev 17389)
@@ -177,10 +177,10 @@
<p>Buildroot optionally honors some environment variables that are passed
to <code>make</code> :</p>
<ul>
- <li>HOSTCXX
- <li>HOSTCC
- <li>UCLIBC_CONFIG_FILE=<path/to/.config>
- <li>BUSYBOX_CONFIG_FILE=<path/to/.config>
+ <li>HOSTCXX</li>
+ <li>HOSTCC</li>
+ <li>UCLIBC_CONFIG_FILE=<path/to/.config></li>
+ <li>BUSYBOX_CONFIG_FILE=<path/to/.config></li>
</ul>
<p>An example that uses config files located in the toplevel directory and
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-01-21 21:49 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-01-21 21:49 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-01-21 13:49:55 -0800 (Sun, 21 Jan 2007)
New Revision: 17443
Log:
- remove validator, all is fine now.
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-01-21 21:32:49 UTC (rev 17442)
+++ trunk/buildroot/docs/buildroot.html 2007-01-21 21:49:55 UTC (rev 17443)
@@ -685,12 +685,10 @@
</div>
<!--
--->
<a href="http://validator.w3.org/check?uri=referer"><img
border="0" height="31" width="88"
src="images/valid-html401.png"
alt="Valid HTML"></img></a>
-<!--
-->
</body>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-03-13 12:59 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-03-13 12:59 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-03-13 05:59:45 -0700 (Tue, 13 Mar 2007)
New Revision: 18084
Log:
- point to busybox-<version>.config
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-03-13 11:02:33 UTC (rev 18083)
+++ trunk/buildroot/docs/buildroot.html 2007-03-13 12:59:45 UTC (rev 18084)
@@ -249,7 +249,7 @@
</ol>
<p>Otherwise, you can simply change the
- <code>package/busybox/busybox.config</code> file if you know the options
+ <code>package/busybox/busybox-<version>.config</code> file if you know the options
you want to change without using the configuration tool.</p>
<p>If you want to use an existing config file for busybox, then see
section <a href="#environment_variables">environment variables</a>.</p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-06-21 16:58 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-06-21 16:58 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-06-21 09:58:36 -0700 (Thu, 21 Jun 2007)
New Revision: 18884
Log:
- update docs to mention the new sysroot support.
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-06-21 13:44:53 UTC (rev 18883)
+++ trunk/buildroot/docs/buildroot.html 2007-06-21 16:58:36 UTC (rev 18884)
@@ -362,7 +362,7 @@
default). This is where the cross-compilation toolchain will be
installed. If you want to use the same cross-compilation toolchain for
other purposes, such as compiling third-party applications, you can add
- <code>build_ARCH/staging_dir/bin</code> to your PATH, and then use
+ <code>build_ARCH/staging_dir/usr/bin</code> to your PATH, and then use
<code>arch-linux-gcc</code> to compile your application. In order to
setup this staging directory, it first removes it, and then it creates
various subdirectories and symlinks inside it.</li>
@@ -390,7 +390,7 @@
<p>The toolchain generated by Buildroot by default is located in
<code>build_ARCH/staging_dir/</code>. The simplest way to use it
- is to add <code>build_ARCH/staging_dir/bin/</code> to your PATH
+ is to add <code>build_ARCH/staging_dir/usr/bin/</code> to your PATH
environnement variable, and then to use
<code>arch-linux-gcc</code>, <code>arch-linux-objdump</code>,
<code>arch-linux-ld</code>, etc.</p>
@@ -401,7 +401,7 @@
<code>~/buildroot/</code>) :</p>
<pre>
-export PATH="$PATH:~/buildroot/build_mips/staging_dir/bin/"
+export PATH="$PATH:~/buildroot/build_mips/staging_dir/usr/bin/"
</pre>
<p>Then you can simply do :</p>
@@ -410,12 +410,15 @@
mips-linux-gcc -o foo foo.c
</pre>
- <p><b>Important</b> : do not try to move the toolchain to an other
+ <p><b>Important</b> : do not try to move a gcc-3.x toolchain to an other
directory, it won't work. There are some hard-coded paths in the
<i>gcc</i> configuration. If the default toolchain directory
doesn't suit your needs, please refer to the <a
href="#toolchain_standalone">Using the uClibc toolchain outside of
buildroot</a> section.</p>
+ <p>If you are using a current gcc-4.x, then use --sysroot and -isysroot
+ since these toolchains have fully functional sysroot support. No
+ hardcoded paths do exist in these configurations.</p>
<h2><a name="toolchain_standalone" id="toolchain_standalone"></a>Using the
uClibc toolchain outside of buildroot</h2>
@@ -424,10 +427,11 @@
<code>build_ARCH/staging_dir/</code>. But sometimes, it may be useful to
install it somewhere else, so that it can be used to compile other programs
or by other users. Moving the <code>build_ARCH/staging_dir/</code>
- directory elsewhere is <b>not possible</b>, because they are some hardcoded
- paths in the toolchain configuration.</p>
+ directory elsewhere is <b>not possible if using gcc-3.x</b>, because they are some hardcoded
+ paths in the toolchain configuration. This works, thanks to sysroot support, with current,
+ stable gcc-4.x toolchains, of course.</p>
- <p>If you want to use the generated toolchain for other purposes,
+ <p>If you want to use the generated gcc-3.x toolchain for other purposes,
you can configure Buildroot to generate it elsewhere using the
option of the configuration tool : <code>Build options ->
Toolchain and header file location</code>, which defaults to
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-07-12 14:43 ulf at uclibc.org
2007-07-12 15:07 ` Bernhard Fischer
0 siblings, 1 reply; 59+ messages in thread
From: ulf at uclibc.org @ 2007-07-12 14:43 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2007-07-12 07:43:44 -0700 (Thu, 12 Jul 2007)
New Revision: 19071
Log:
Update Documentation for BSP patch
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-07-12 13:11:03 UTC (rev 19070)
+++ trunk/buildroot/docs/buildroot.html 2007-07-12 14:43:44 UTC (rev 19071)
@@ -145,10 +145,15 @@
<p>For each entry of the configuration tool, you can find associated help
that describes the purpose of the entry.</p>
+ <p>One of the key configuration items is the <code>PROJECT</code> which
+ determines where some board specific packages are built and where the
+ results are stored.</p>
+
<p>Once everything is configured, the configuration tool has generated a
<code>.config</code> file that contains the description of your
configuration. It will be used by the Makefiles to do what's needed.</p>
+
<p>Let's go:</p>
<pre>
@@ -160,7 +165,7 @@
be named <code>root_fs_ARCH.EXT</code> where <code>ARCH</code> is your
architecture and <code>EXT</code> depends on the type of target filesystem
selected in the <code>Target options</code> section of the configuration
- tool.</p>
+ tool.The file is stored in the "binaries/<code>$(PROJECT)</code>/" directory</p>
<p>If you intend to do an offline-build and just want to download all
sources that you previously selected in "make menuconfig" then
@@ -198,11 +203,11 @@
<h2><a name="custom_targetfs" id="custom_targetfs"></a>Customizing the
target filesystem</h2>
- <p>There are two ways to customize the resulting target filesystem:</p>
+ <p>There are a few ways to customize the resulting target filesystem:</p>
<ul>
<li>Customize the target filesystem directly, and rebuild the image. The
- target filesystem is available under <code>build_ARCH/root/</code> where
+ target filesystem is available under <code>project_build_ARCH/root/</code> where
<code>ARCH</code> is the chosen target architecture. You can simply make
your changes here, and run make afterwards, which will rebuild the target
filesystem image. This method allows to do everything on the target
@@ -224,9 +229,13 @@
it should be changed. These main directories are in an tarball inside of
inside the skeleton because it contains symlinks that would be broken
otherwise.<br />
- These customizations are deployed into <code>build_ARCH/root/</code> just
+ These customizations are deployed into <code>project_build_ARCH/root/</code> just
before the actual image is made. So simply rebuilding the image by running
make should propogate any new changes to the image.</li>
+
+ <li>When configuring the build system, using <code>make menuconfig</code>, you
+ can specify the contents of the /etc/hostname and /etc/issue
+ (the welcome banner) in the <code>PROJECT</code> section</li>
</ul>
<h2><a name="custom_busybox" id="custom_busybox"></a>Customizing the
@@ -349,10 +358,30 @@
tarballs are in this directory because it may be useful to save them
somewhere to avoid further downloads.</li>
- <li>Create the build directory (<code>build_ARCH/</code> by default,
+ <li>Create the shared build directory (<code>build_ARCH/</code> by default,
where <code>ARCH</code> is your architecture). This is where all
- user-space tools while be compiled.</li>
+ non configurable user-space tools will be compiled.When building two or more
+ targets using the same architecture, the first build will go through the full
+ download, configure, make process, but the second and later builds will only
+ copy the result from the first build to its project specific target directory
+ significantly speeding up the build process</li>
+ <li>Create the project specific build directory
+ (<code>project_build_ARCH/$(PROJECT)</code> by default, where <code>ARCH</code>
+ is your architecture). This is where all configurable user-space tools will be
+ compiled. The project specific build directory is neccessary, if two different
+ targets needs to use a specific package, but the packages have different
+ configuration for both targets. Some examples of packages built in this directory
+ are busybox and linux.
+ </li>
+
+ <li>Create the project specific result directory
+ (<code>binaries/$(PROJECT)</code> by default, where <code>ARCH</code>
+ is your architecture). This is where the root file system images are stored,
+ It is also used to store the linux kernel image and any utilities, boot-loaders
+ etc. needed for a target.
+ </li>
+
<li>Create the toolchain build directory
(<code>toolchain_build_ARCH/</code> by default, where <code>ARCH</code>
is your architecture). This is where the cross compilation toolchain will
@@ -367,7 +396,7 @@
setup this staging directory, it first removes it, and then it creates
various subdirectories and symlinks inside it.</li>
- <li>Create the target directory (<code>build_ARCH/root/</code> by
+ <li>Create the target directory (<code>project_build_ARCH/root/</code> by
default) and the target filesystem skeleton. This directory will contain
the final root filesystem. To setup it up, it first deletes it, then it
uncompress the <code>target/generic/skel.tar.gz</code> file to create the
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-07-12 14:46 ulf at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: ulf at uclibc.org @ 2007-07-12 14:46 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2007-07-12 07:46:03 -0700 (Thu, 12 Jul 2007)
New Revision: 19072
Log:
Update Instructions for applying for Buildroot write access
Modified:
trunk/buildroot/docs/developer.html
Changeset:
Modified: trunk/buildroot/docs/developer.html
===================================================================
--- trunk/buildroot/docs/developer.html 2007-07-12 14:43:44 UTC (rev 19071)
+++ trunk/buildroot/docs/developer.html 2007-07-12 14:46:03 UTC (rev 19072)
@@ -19,12 +19,19 @@
or more. If you do not currently have an ssh version 2 DSA key, you can
generate a key using the command<pre>ssh-keygen -t dsa</pre> This will
create the files <pre>/home/<USERNAME>/ssh/id_dsa
-/home/<USERNAME>/.ssh/id_dsa.pub</pre> You must then send the content
-of 'id_dsa.pub' to me so I can setup your account. The content of 'id_dsa'
-should of course be kept secret.
+/home/<USERNAME>/.ssh/id_dsa.pub</pre>
+It is recommended that you generate a key with a "passphrase" for security reasons.
<p>
+Make the file known to the system by running
+<pre>ssh-add ~/.ssh/id_dsa</pre>
+
+You must then send the content of 'id_dsa.pub' to me so I can setup your account.
+The content of 'id_dsa' should of course be kept secret.
+
+<p>
+
Note that if you would prefer to keep your communications with me
private, you can encrypt your email using my
<a href="http://www.codepoet.org/andersen/erik/gpg.asc">public key</a>.
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
2007-07-12 14:43 ulf at uclibc.org
@ 2007-07-12 15:07 ` Bernhard Fischer
0 siblings, 0 replies; 59+ messages in thread
From: Bernhard Fischer @ 2007-07-12 15:07 UTC (permalink / raw)
To: buildroot
On Thu, Jul 12, 2007 at 07:43:45AM -0700, ulf at uclibc.org wrote:
>Author: ulf
>Date: 2007-07-12 07:43:44 -0700 (Thu, 12 Jul 2007)
>New Revision: 19071
>
>Log:
>Update Documentation for BSP patch
>
>Modified:
> trunk/buildroot/docs/buildroot.html
>
>
>@@ -160,7 +165,7 @@
> be named <code>root_fs_ARCH.EXT</code> where <code>ARCH</code> is your
> architecture and <code>EXT</code> depends on the type of target filesystem
> selected in the <code>Target options</code> section of the configuration
>- tool.</p>
>+ tool.The file is stored in the "binaries/<code>$(PROJECT)</code>/" directory</p>
whitespace damaged (missing space after punctuation)
>
> <p>If you intend to do an offline-build and just want to download all
> sources that you previously selected in "make menuconfig" then
>@@ -224,9 +229,13 @@
> it should be changed. These main directories are in an tarball inside of
> inside the skeleton because it contains symlinks that would be broken
> otherwise.<br />
>- These customizations are deployed into <code>build_ARCH/root/</code> just
>+ These customizations are deployed into <code>project_build_ARCH/root/</code> just
overlong line.
> before the actual image is made. So simply rebuilding the image by running
> make should propogate any new changes to the image.</li>
>+
>+ <li>When configuring the build system, using <code>make menuconfig</code>, you
overlong line.
>+ can specify the contents of the /etc/hostname and /etc/issue
>+ (the welcome banner) in the <code>PROJECT</code> section</li>
> </ul>
>
> <h2><a name="custom_busybox" id="custom_busybox"></a>Customizing the
>@@ -349,10 +358,30 @@
> tarballs are in this directory because it may be useful to save them
> somewhere to avoid further downloads.</li>
>
overlong line everywhere below
>- <li>Create the build directory (<code>build_ARCH/</code> by default,
>+ <li>Create the shared build directory (<code>build_ARCH/</code> by default,
> where <code>ARCH</code> is your architecture). This is where all
>- user-space tools while be compiled.</li>
>+ non configurable user-space tools will be compiled.When building two or more
whitespace damaged (missing space after punctuation)
>+ targets using the same architecture, the first build will go through the full
>+ download, configure, make process, but the second and later builds will only
>+ copy the result from the first build to its project specific target directory
>+ significantly speeding up the build process</li>
>
>+ <li>Create the project specific build directory
>+ (<code>project_build_ARCH/$(PROJECT)</code> by default, where <code>ARCH</code>
>+ is your architecture). This is where all configurable user-space tools will be
>+ compiled. The project specific build directory is neccessary, if two different
I don't think that comma before if is correct.. and you ment to type
necessary with just one 'c'.
>+ targets needs to use a specific package, but the packages have different
>+ configuration for both targets. Some examples of packages built in this directory
>+ are busybox and linux.
>+ </li>
>+
>+ <li>Create the project specific result directory
>+ (<code>binaries/$(PROJECT)</code> by default, where <code>ARCH</code>
>+ is your architecture). This is where the root file system images are stored,
it is 'filesystem' without a space.
>+ It is also used to store the linux kernel image and any utilities, boot-loaders
>+ etc. needed for a target.
>+ </li>
>+
> <li>Create the toolchain build directory
> (<code>toolchain_build_ARCH/</code> by default, where <code>ARCH</code>
> is your architecture). This is where the cross compilation toolchain will
>@@ -367,7 +396,7 @@
> setup this staging directory, it first removes it, and then it creates
> various subdirectories and symlinks inside it.</li>
>
>- <li>Create the target directory (<code>build_ARCH/root/</code> by
>+ <li>Create the target directory (<code>project_build_ARCH/root/</code> by
> default) and the target filesystem skeleton. This directory will contain
> the final root filesystem. To setup it up, it first deletes it, then it
> uncompress the <code>target/generic/skel.tar.gz</code> file to create the
Please make sure that at least the source of the documentation can be
edited on a 80x24 console without too much pain, TIA.
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-07-12 16:53 ulf at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: ulf at uclibc.org @ 2007-07-12 16:53 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2007-07-12 09:53:13 -0700 (Thu, 12 Jul 2007)
New Revision: 19075
Log:
Fix Document style
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-07-12 15:32:04 UTC (rev 19074)
+++ trunk/buildroot/docs/buildroot.html 2007-07-12 16:53:13 UTC (rev 19075)
@@ -34,7 +34,8 @@
<li><a href="#using_toolchain">Using the uClibc toolchain</a></li>
<li><a href="#toolchain_standalone">Using the uClibc toolchain
outside of Buildroot</a></li>
- <li><a href="#downloaded_packages">Location of downloaded packages</a></li>
+ <li><a href="#downloaded_packages">Location of downloaded packages</a>
+ </li>
<li><a href="#add_software">Extending Buildroot with more
Software</a></li>
<li><a href="#links">Resources</a></li>
@@ -68,8 +69,8 @@
uses the GNU libc as C standard library. This compilation
toolchain is called the "host compilation toolchain", and more
generally, the machine on which it is running, and on which you're
- working is called the "host system". The compilation toolchain is
- provided by your distribution, and Buildroot has nothing to do
+ working is called the "host system". The compilation toolchain
+ is provided by your distribution, and Buildroot has nothing to do
with it.</p>
<p>As said above, the compilation toolchain that comes with your system
@@ -147,7 +148,7 @@
<p>One of the key configuration items is the <code>PROJECT</code> which
determines where some board specific packages are built and where the
- results are stored.</p>
+ results are stored. </p>
<p>Once everything is configured, the configuration tool has generated a
<code>.config</code> file that contains the description of your
@@ -165,7 +166,8 @@
be named <code>root_fs_ARCH.EXT</code> where <code>ARCH</code> is your
architecture and <code>EXT</code> depends on the type of target filesystem
selected in the <code>Target options</code> section of the configuration
- tool.The file is stored in the "binaries/<code>$(PROJECT)</code>/" directory</p>
+ tool.
+ The file is stored in the "binaries/<code>$(PROJECT)</code>/" directory</p>
<p>If you intend to do an offline-build and just want to download all
sources that you previously selected in "make menuconfig" then
@@ -207,12 +209,12 @@
<ul>
<li>Customize the target filesystem directly, and rebuild the image. The
- target filesystem is available under <code>project_build_ARCH/root/</code> where
- <code>ARCH</code> is the chosen target architecture. You can simply make
- your changes here, and run make afterwards, which will rebuild the target
- filesystem image. This method allows to do everything on the target
- filesystem, but if you decide to completely rebuild your toolchain and
- tools, these changes will be lost.</li>
+ target filesystem is available under <code>project_build_ARCH/root/</code>
+ where <code>ARCH</code> is the chosen target architecture.
+ You can simply make your changes here, and run make afterwards, which will
+ rebuild the target filesystem image. This method allows to do everything
+ on the target filesystem, but if you decide to completely rebuild your
+ toolchain and tools, these changes will be lost.</li>
<li>Customize the target filesystem skeleton, available under
<code>target/generic/target_skeleton/</code>. You can customize
@@ -229,12 +231,13 @@
it should be changed. These main directories are in an tarball inside of
inside the skeleton because it contains symlinks that would be broken
otherwise.<br />
- These customizations are deployed into <code>project_build_ARCH/root/</code> just
- before the actual image is made. So simply rebuilding the image by running
- make should propogate any new changes to the image.</li>
+ These customizations are deployed into
+ <code>project_build_ARCH/root/</code> just before the actual image
+ is made. So simply rebuilding the image by running
+ make should propagate any new changes to the image.</li>
- <li>When configuring the build system, using <code>make menuconfig</code>, you
- can specify the contents of the /etc/hostname and /etc/issue
+ <li>When configuring the build system, using <code>make menuconfig</code>,
+ you can specify the contents of the /etc/hostname and /etc/issue
(the welcome banner) in the <code>PROJECT</code> section</li>
</ul>
@@ -258,8 +261,9 @@
</ol>
<p>Otherwise, you can simply change the
- <code>package/busybox/busybox-<version>.config</code> file if you know the options
- you want to change without using the configuration tool.</p>
+ <code>package/busybox/busybox-<version>.config</code> file if you
+ know the options you want to change without using the configuration tool.
+ </p>
<p>If you want to use an existing config file for busybox, then see
section <a href="#environment_variables">environment variables</a>.</p>
@@ -358,28 +362,28 @@
tarballs are in this directory because it may be useful to save them
somewhere to avoid further downloads.</li>
- <li>Create the shared build directory (<code>build_ARCH/</code> by default,
- where <code>ARCH</code> is your architecture). This is where all
- non configurable user-space tools will be compiled.When building two or more
- targets using the same architecture, the first build will go through the full
- download, configure, make process, but the second and later builds will only
- copy the result from the first build to its project specific target directory
- significantly speeding up the build process</li>
+ <li>Create the shared build directory (<code>build_ARCH/</code> by
+ default, where <code>ARCH</code> is your architecture). This is where all
+ non configurable user-space tools will be compiled.When building two or
+ more targets using the same architecture, the first build will go through
+ the full download, configure, make process, but the second and later
+ builds will only copy the result from the first build to its project
+ specific target directory significantly speeding up the build process</li>
<li>Create the project specific build directory
- (<code>project_build_ARCH/$(PROJECT)</code> by default, where <code>ARCH</code>
- is your architecture). This is where all configurable user-space tools will be
- compiled. The project specific build directory is neccessary, if two different
- targets needs to use a specific package, but the packages have different
- configuration for both targets. Some examples of packages built in this directory
- are busybox and linux.
+ (<code>project_build_ARCH/$(PROJECT)</code> by default, where
+ <code>ARCH</code> is your architecture). This is where all configurable
+ user-space tools will be compiled. The project specific build directory
+ is neccessary, if two different targets needs to use a specific package,
+ but the packages have different configuration for both targets. Some
+ examples of packages built in this directory are busybox and linux.
</li>
<li>Create the project specific result directory
(<code>binaries/$(PROJECT)</code> by default, where <code>ARCH</code>
- is your architecture). This is where the root file system images are stored,
- It is also used to store the linux kernel image and any utilities, boot-loaders
- etc. needed for a target.
+ is your architecture). This is where the root file system images are
+ stored, It is also used to store the linux kernel image and any
+ utilities, boot-loaders etc. needed for a target.
</li>
<li>Create the toolchain build directory
@@ -456,9 +460,9 @@
<code>build_ARCH/staging_dir/</code>. But sometimes, it may be useful to
install it somewhere else, so that it can be used to compile other programs
or by other users. Moving the <code>build_ARCH/staging_dir/</code>
- directory elsewhere is <b>not possible if using gcc-3.x</b>, because they are some hardcoded
- paths in the toolchain configuration. This works, thanks to sysroot support, with current,
- stable gcc-4.x toolchains, of course.</p>
+ directory elsewhere is <b>not possible if using gcc-3.x</b>, because they
+ are some hardcoded paths in the toolchain configuration. This works, thanks
+ to sysroot support, with current, stable gcc-4.x toolchains, of course.</p>
<p>If you want to use the generated gcc-3.x toolchain for other purposes,
you can configure Buildroot to generate it elsewhere using the
@@ -585,7 +589,8 @@
the other <code>*.mk</code> files in the <code>package</code>
directory.</p>
- <p>At lines <a href="#line6">6-11</a>, a couple of useful variables are defined :</p>
+ <p>At lines <a href="#line6">6-11</a>, a couple of useful variables are
+ defined :</p>
<ul>
@@ -614,22 +619,22 @@
</ul>
- <p>Lines <a href="#line13">13-14</a> defines a target that downloads the tarball from
- the remote site to the download directory
+ <p>Lines <a href="#line13">13-14</a> defines a target that downloads the
+ tarball from the remote site to the download directory
(<code>DL_DIR</code>).</p>
- <p>Lines <a href="#line16">16-18</a> defines a target and associated rules that
- uncompress the downloaded tarball. As you can see, this target
+ <p>Lines <a href="#line16">16-18</a> defines a target and associated rules
+ that uncompress the downloaded tarball. As you can see, this target
depends on the tarball file, so that the previous target (line
- <a href="#line13">13-14</a>) is called before executing the rules of the current
- target. Uncompressing is followed by <i>touching</i> a hidden file
+ <a href="#line13">13-14</a>) is called before executing the rules of the
+ current target. Uncompressing is followed by <i>touching</i> a hidden file
to mark the software has having been uncompressed. This trick is
used everywhere in Buildroot <i>Makefile</i> to split steps
(download, uncompress, configure, compile, install) while still
having correct dependencies.</p>
- <p>Lines <a href="#line20">20-31</a> defines a target and associated rules that
- configures the software. It depends on the previous target (the
+ <p>Lines <a href="#line20">20-31</a> defines a target and associated rules
+ that configures the software. It depends on the previous target (the
hidden <code>.source</code> file) so that we are sure the software has
been uncompressed. In order to configure it, it basically runs the
well-known <code>./configure</code> script. As we may be doing
@@ -640,15 +645,15 @@
filesystem. Finally it creates a <code>.configured</code> file to
mark the software as configured.</p>
- <p>Lines <a href="#line33">33-34</a> defines a target and a rule that compiles the
- software. This target will create the binary file in the
+ <p>Lines <a href="#line33">33-34</a> defines a target and a rule that
+ compiles the software. This target will create the binary file in the
compilation directory, and depends on the software being already
configured (hence the reference to the <code>.configured</code>
file). It basically runs <code>make</code> inside the source
directory.</p>
- <p>Lines <a href="#line36">36-38</a> defines a target and associated rules that install
- the software inside the target filesystem. It depends on the
+ <p>Lines <a href="#line36">36-38</a> defines a target and associated rules
+ that install the software inside the target filesystem. It depends on the
binary file in the source directory, to make sure the software has
been compiled. It uses the <code>install</code> target of the
software <code>Makefile</code> by passing a <code>prefix</code>
@@ -658,8 +663,8 @@
<code>/usr/man</code> directory inside the target filesystem is
removed to save space.</p>
- <p>Line <a href="#line40">40</a> defines the main target of the software, the one
- that will be eventually be used by the top level
+ <p>Line <a href="#line40">40</a> defines the main target of the software,
+ the one that will be eventually be used by the top level
<code>Makefile</code> to download, compile, and then install
this package. This target should first of all depends on all
needed dependecies of the software (in our example,
@@ -667,33 +672,34 @@
final binary. This last dependency will call all previous
dependencies in the correct order. </p>
- <p>Line <a href="#line42">42</a> defines a simple target that only downloads the code
- source. This is not used during normal operation of Buildroot, but
- is needed if you intend to download all required sources at once
- for later offline build. Note that if you add a new package providing
+ <p>Line <a href="#line42">42</a> defines a simple target that only
+ downloads the code source. This is not used during normal operation of
+ Buildroot, but is needed if you intend to download all required sources at
+ once for later offline build. Note that if you add a new package providing
a <code>foo-source</code> target is <i>mandatory</i> to support
users that wish to do offline-builds. Furthermore it eases checking
if all package-sources are downloadable.</p>
- <p>Lines <a href="#line44">44-46</a> define a simple target to clean the software build
- by calling the <i>Makefiles</i> with the appropriate option.
+ <p>Lines <a href="#line44">44-46</a> define a simple target to clean the
+ software build by calling the <i>Makefiles</i> with the appropriate option.
The <code>-clean</code> target should run <code>make clean</code>
on $(BUILD_DIR)/package-version and MUST uninstall all files of the
package from $(STAGING_DIR) and from $(TARGET_DIR).</p>
- <p>Lines <a href="#line48">48-49</a> define a simple target to completely remove the
- directory in which the software was uncompressed, configured and
- compiled. The <code>-dirclean</code> target MUST completely rm $(BUILD_DIR)/package-version.</p>
+ <p>Lines <a href="#line48">48-49</a> define a simple target to completely
+ remove the directory in which the software was uncompressed, configured and
+ compiled. The <code>-dirclean</code> target MUST completely rm $(BUILD_DIR)/
+ package-version.</p>
- <p>Lines <a href="#line51">51-58</a> adds the target <code>foo</code> to the list
- of targets to be compiled by Buildroot by first checking if
+ <p>Lines <a href="#line51">51-58</a> adds the target <code>foo</code> to
+ the list of targets to be compiled by Buildroot by first checking if
the configuration option for this package has been enabled
using the configuration tool, and if so then "subscribes"
this package to be compiled by adding it to the TARGETS
global variable. The name added to the TARGETS global
variable is the name of this package's target, as defined on
- line <a href="#line40">40</a>, which is used by Buildroot to download, compile, and
- then install this package.</p>
+ line <a href="#line40">40</a>, which is used by Buildroot to download,
+ compile, and then install this package.</p>
<h3>Conclusion</h3>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-07-12 17:04 ulf at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: ulf at uclibc.org @ 2007-07-12 17:04 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2007-07-12 10:04:05 -0700 (Thu, 12 Jul 2007)
New Revision: 19077
Log:
Fix Document style
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-07-12 16:57:47 UTC (rev 19076)
+++ trunk/buildroot/docs/buildroot.html 2007-07-12 17:04:05 UTC (rev 19077)
@@ -16,7 +16,7 @@
</div>
<p><a href="http://buildroot.uclibc.org/">Buildroot</a> usage and documentation by Thomas Petazzoni. Contributions from
- Karsten Kruse, Ned Ludd, Martin Herren and others.</p>
+ Karsten Kruse, Ned Ludd, Martin Herren and others. </p>
<p><small>$LastChangedDate$</small></p>
@@ -47,12 +47,12 @@
generate both a cross-compilation toolchain and a root filesystem for your
target. The cross-compilation toolchain uses uClibc (<a href=
"http://www.uclibc.org/">http://www.uclibc.org/</a>), a tiny C standard
- library.</p>
+ library. </p>
<p>Buildroot is useful mainly for people working with embedded systems.
Embedded systems often use processors that are not the regular x86
processors everyone is used to have on his PC. It can be PowerPC
- processors, MIPS processors, ARM processors, etc.</p>
+ processors, MIPS processors, ARM processors, etc. </p>
<p>A compilation toolchain is the set of tools that allows to
compile code for your system. It consists of a compiler (in our
@@ -71,7 +71,7 @@
generally, the machine on which it is running, and on which you're
working is called the "host system". The compilation toolchain
is provided by your distribution, and Buildroot has nothing to do
- with it.</p>
+ with it. </p>
<p>As said above, the compilation toolchain that comes with your system
runs and generates code for the processor of your host system. As your
@@ -81,7 +81,7 @@
example, if your host system uses x86 and your target system uses ARM, the
regular compilation toolchain of your host runs on x86 and generates code
for x86, while the cross-compilation toolchain runs on x86 and generates
- code for ARM.</p>
+ code for ARM. </p>
<p>Even if your embedded system uses a x86 processor, you might interested
in Buildroot, for two reasons:</p>
@@ -92,10 +92,10 @@
Libc on your target system, you can use uClibc which is a tiny C standard
library. If you want to use this C library, then you need a compilation
toolchain to generate binaries linked with it. Buildroot can do it for
- you.</li>
+ you. </li>
<li>Buildroot automates the building of a root filesystem with all needed
- tools like busybox. It makes it much easier than doing it by hand.</li>
+ tools like busybox. It makes it much easier than doing it by hand. </li>
</ul>
<p>You might wonder why such a tool is needed when you can compile
@@ -105,17 +105,17 @@
version it very time-consuming and uninteresting. Buildroot automates this
process through the use of Makefiles, and has a collection of patches for
each <code>gcc</code> and <code>binutils</code> version to make them work
- on most architectures.</p>
+ on most architectures. </p>
<h2><a name="download" id="download"></a>Obtaining Buildroot</h2>
<p>Buildroot is available as daily SVN snapshots or directly using
- SVN.</p>
+ SVN. </p>
<p>The latest snapshot is always available at <a
href="http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2">http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2</a>,
and previous snapshots are also available at <a
- href="http://buildroot.uclibc.org/downloads/snapshots/">http://buildroot.uclibc.org/downloads/snapshots/</a>.</p>
+ href="http://buildroot.uclibc.org/downloads/snapshots/">http://buildroot.uclibc.org/downloads/snapshots/</a>. </p>
<p>To download Buildroot using SVN, you can simply follow
the rules described on the "Accessing SVN"-page (<a href=
@@ -144,7 +144,7 @@
</pre>
<p>For each entry of the configuration tool, you can find associated help
- that describes the purpose of the entry.</p>
+ that describes the purpose of the entry. </p>
<p>One of the key configuration items is the <code>PROJECT</code> which
determines where some board specific packages are built and where the
@@ -152,7 +152,7 @@
<p>Once everything is configured, the configuration tool has generated a
<code>.config</code> file that contains the description of your
- configuration. It will be used by the Makefiles to do what's needed.</p>
+ configuration. It will be used by the Makefiles to do what's needed. </p>
<p>Let's go:</p>
@@ -176,7 +176,7 @@
$ make source
</pre>
<p>You can now disconnect or copy the content of your <code>dl</code>
- directory to the build-host.</p>
+ directory to the build-host. </p>
<h3><a name="environment_variables" id="environment_variables"></a>
Environment variables</h3>
@@ -214,7 +214,7 @@
You can simply make your changes here, and run make afterwards, which will
rebuild the target filesystem image. This method allows to do everything
on the target filesystem, but if you decide to completely rebuild your
- toolchain and tools, these changes will be lost.</li>
+ toolchain and tools, these changes will be lost. </li>
<li>Customize the target filesystem skeleton, available under
<code>target/generic/target_skeleton/</code>. You can customize
@@ -222,7 +222,7 @@
is not yet present, because it's created during the compilation process.
So you can't do everything on this target filesystem skeleton, but
changes to it remain even if you completely rebuild the cross-compilation
- toolchain and the tools.<br />
+ toolchain and the tools. <br />
You can also customize the <code>target/generic/device_table.txt</code>
file which is used by the tools that generate the target filesystem image
to properly set permissions and create device nodes. The
@@ -230,11 +230,11 @@
directories of a root filesystem and there is no obvious reason for which
it should be changed. These main directories are in an tarball inside of
inside the skeleton because it contains symlinks that would be broken
- otherwise.<br />
+ otherwise. <br />
These customizations are deployed into
<code>project_build_ARCH/root/</code> just before the actual image
is made. So simply rebuilding the image by running
- make should propagate any new changes to the image.</li>
+ make should propagate any new changes to the image. </li>
<li>When configuring the build system, using <code>make menuconfig</code>,
you can specify the contents of the /etc/hostname and /etc/issue
@@ -247,17 +247,17 @@
<p><a href="http://www.busybox.net/">Busybox</a> is very configurable, and
you may want to customize it. You can
follow these simple steps to do it. It's not an optimal way, but it's
- simple and it works.</p>
+ simple and it works. </p>
<ol>
<li>Make a first compilation of buildroot with busybox without trying to
- customize it.</li>
+ customize it. </li>
<li>Invoke <code>make busybox-menuconfig</code>.
The nice configuration tool appears and you can
- customize everything.</li>
+ customize everything. </li>
- <li>Run the compilation of buildroot again.</li>
+ <li>Run the compilation of buildroot again. </li>
</ol>
<p>Otherwise, you can simply change the
@@ -265,7 +265,7 @@
know the options you want to change without using the configuration tool.
</p>
<p>If you want to use an existing config file for busybox, then see
- section <a href="#environment_variables">environment variables</a>.</p>
+ section <a href="#environment_variables">environment variables</a>. </p>
<h2><a name="custom_uclibc" id="custom_uclibc"></a>Customizing the uClibc
configuration</h2>
@@ -273,7 +273,7 @@
<p>Just like <a href="#custom_busybox">BusyBox</a>, <a
href="http://www.uclibc.org/">uClibc</a> offers a lot of
configuration options. They allow to select various
- functionalities, depending on your needs and limitations.</p>
+ functionalities, depending on your needs and limitations. </p>
<p>The easiest way to modify the configuration of uClibc is to
follow these steps :</p>
@@ -281,19 +281,19 @@
<ol>
<li>Make a first compilation of buildroot without trying to
- customize uClibc.</li>
+ customize uClibc. </li>
<li>Invoke <code>make uclibc-menuconfig</code>.
The nice configuration assistant, similar to
the one used in the Linux Kernel or in Buildroot appears. Make
- your configuration as appropriate.</li>
+ your configuration as appropriate. </li>
<li>Copy the <code>.config</code> file to
<code>toolchain/uClibc/uClibc.config</code> or
<code>toolchain/uClibc/uClibc.config-locale</code>. The former
is used if you haven't selected locale support in Buildroot
configuration, and the latter is used if you have selected
- locale support.</li>
+ locale support. </li>
<li>Run the compilation of Buildroot again</li>
@@ -302,10 +302,10 @@
<p>Otherwise, you can simply change
<code>toolchain/uClibc/uClibc.config</code> or
<code>toolchain/uClibc/uClibc.config-locale</code> without running
- the configuration assistant.</p>
+ the configuration assistant. </p>
<p>If you want to use an existing config file for uclibc, then see
- section <a href="#environment_variables">environment variables</a>.</p>
+ section <a href="#environment_variables">environment variables</a>. </p>
<h2><a name="buildroot_innards" id="buildroot_innards"></a>How Buildroot
works</h2>
@@ -314,7 +314,7 @@
configure and compiles software with the correct options. It also includes
some patches for various software, mainly the ones involved in the
cross-compilation tool chain (<code>gcc</code>, <code>binutils</code> and
- uClibc).</p>
+ uClibc). </p>
<p>There is basically one Makefile per software, and they are named with
the <code>.mk</code> extension. Makefiles are split into three
@@ -324,13 +324,13 @@
<li><b>package</b> (in the <code>package/</code> directory) contains the
Makefiles and associated files for all user-space tools that Buildroot
can compile and add to the target root filesystem. There is one
- sub-directory per tool.</li>
+ sub-directory per tool. </li>
<li><b>toolchain</b> (in the <code>toolchain/</code> directory) contains
the Makefiles and associated files for all software related to the
cross-compilation toolchain : <code>binutils</code>, <code>ccache</code>,
<code>gcc</code>, <code>gdb</code>, <code>kernel-headers</code> and
- <code>uClibc</code>.</li>
+ <code>uClibc</code>. </li>
<li><b>target</b> (in the <code>target</code> directory) contains the
Makefiles and associated files for software related to the generation of
@@ -338,18 +338,18 @@
: ext2, jffs2, cramfs and squashfs. For each of them, there's a
sub-directory with the required files. There is also a
<code>default/</code> directory that contains the target filesystem
- skeleton.</li>
+ skeleton. </li>
</ul>
<p>Each directory contains at least 2 files :</p>
<ul>
<li><code>something.mk</code> is the Makefile that downloads, configures,
- compiles and installs the software <code>something</code>.</li>
+ compiles and installs the software <code>something</code>. </li>
<li><code>Config.in</code> is a part of the configuration tool
description file. It describes the option related to the current
- software.</li>
+ software. </li>
</ul>
@@ -360,7 +360,7 @@
<li>Create the download directory (<code>dl/</code> by default). This is
where the tarballs will be downloaded. It is interesting to know that the
tarballs are in this directory because it may be useful to save them
- somewhere to avoid further downloads.</li>
+ somewhere to avoid further downloads. </li>
<li>Create the shared build directory (<code>build_ARCH/</code> by
default, where <code>ARCH</code> is your architecture). This is where all
@@ -381,7 +381,7 @@
<li>Create the project specific result directory
(<code>binaries/$(PROJECT)</code> by default, where <code>ARCH</code>
- is your architecture). This is where the root file system images are
+ is your architecture). This is where the root filesystem images are
stored, It is also used to store the linux kernel image and any
utilities, boot-loaders etc. needed for a target.
</li>
@@ -389,7 +389,7 @@
<li>Create the toolchain build directory
(<code>toolchain_build_ARCH/</code> by default, where <code>ARCH</code>
is your architecture). This is where the cross compilation toolchain will
- be compiled.</li>
+ be compiled. </li>
<li>Setup the staging directory (<code>build_ARCH/staging_dir/</code> by
default). This is where the cross-compilation toolchain will be
@@ -398,7 +398,7 @@
<code>build_ARCH/staging_dir/usr/bin</code> to your PATH, and then use
<code>arch-linux-gcc</code> to compile your application. In order to
setup this staging directory, it first removes it, and then it creates
- various subdirectories and symlinks inside it.</li>
+ various subdirectories and symlinks inside it. </li>
<li>Create the target directory (<code>project_build_ARCH/root/</code> by
default) and the target filesystem skeleton. This directory will contain
@@ -406,12 +406,12 @@
uncompress the <code>target/generic/skel.tar.gz</code> file to create the
main subdirectories and symlinks, copies the skeleton available in
<code>target/generic/target_skeleton</code> and then removes useless
- <code>.svn/</code> directories.</li>
+ <code>.svn/</code> directories. </li>
<li>Add the <code>TARGETS</code> dependency. This should generally check
if the configuration option for this package is enabled, and if so then
"subscribe" this package to be compiled by adding it to the
- TARGETS global variable.</li>
+ TARGETS global variable. </li>
</ol>
<h2><a name="using_toolchain" id="using_toolchain"></a>Using the
@@ -419,14 +419,14 @@
<p>You may want to compile your own programs or other software
that are not packaged in Buildroot. In order to do this, you can
- use the toolchain that was generated by Buildroot.</p>
+ use the toolchain that was generated by Buildroot. </p>
<p>The toolchain generated by Buildroot by default is located in
<code>build_ARCH/staging_dir/</code>. The simplest way to use it
is to add <code>build_ARCH/staging_dir/usr/bin/</code> to your PATH
environnement variable, and then to use
<code>arch-linux-gcc</code>, <code>arch-linux-objdump</code>,
- <code>arch-linux-ld</code>, etc.</p>
+ <code>arch-linux-ld</code>, etc. </p>
<p>For example, you may add the following to your
<code>.bashrc</code> (considering you're building for the MIPS
@@ -448,10 +448,10 @@
<i>gcc</i> configuration. If the default toolchain directory
doesn't suit your needs, please refer to the <a
href="#toolchain_standalone">Using the uClibc toolchain outside of
- buildroot</a> section.</p>
+ buildroot</a> section. </p>
<p>If you are using a current gcc-4.x, then use --sysroot and -isysroot
since these toolchains have fully functional sysroot support. No
- hardcoded paths do exist in these configurations.</p>
+ hardcoded paths do exist in these configurations. </p>
<h2><a name="toolchain_standalone" id="toolchain_standalone"></a>Using the
uClibc toolchain outside of buildroot</h2>
@@ -462,13 +462,13 @@
or by other users. Moving the <code>build_ARCH/staging_dir/</code>
directory elsewhere is <b>not possible if using gcc-3.x</b>, because they
are some hardcoded paths in the toolchain configuration. This works, thanks
- to sysroot support, with current, stable gcc-4.x toolchains, of course.</p>
+ to sysroot support, with current, stable gcc-4.x toolchains, of course. </p>
<p>If you want to use the generated gcc-3.x toolchain for other purposes,
you can configure Buildroot to generate it elsewhere using the
option of the configuration tool : <code>Build options ->
Toolchain and header file location</code>, which defaults to
- <code>$(BUILD_DIR)/staging_dir/</code>.</p>
+ <code>$(BUILD_DIR)/staging_dir/</code>. </p>
<h2><a name="downloaded_packages"
id="downloaded_packages"></a>Location of downloaded packages</h2>
@@ -480,18 +480,18 @@
version of Buildroot which is know to be working with the
associated tarballs. This will allow you to regenerate the
toolchain and the target filesystem with exactly the same
- versions.</p>
+ versions. </p>
<h2><a name="add_software" id="add_software"></a>Extending Buildroot with
more software</h2>
<p>This section will only consider the case in which you want to
- add user-space software.</p>
+ add user-space software. </p>
<h3>Package directory</h3>
<p>First of all, create a directory under the <code>package</code>
- directory for your software, for example <code>foo</code>.</p>
+ directory for your software, for example <code>foo</code>. </p>
<h3><code>Config.in</code> file</h3>
@@ -511,7 +511,7 @@
</pre>
<p>Of course, you can add other options to configure particular
- things in your software.</p>
+ things in your software. </p>
<h3>The real <i>Makefile</i></h3>
@@ -519,7 +519,7 @@
<code>foo.mk</code>. It will contain the <i>Makefile</i> rules that
are in charge of downloading, configuring, compiling and installing
the software. Below is an example that we will comment
- afterwards.</p>
+ afterwards. </p>
<pre>
<a name="line1" id="line1">1</a> #############################################################
@@ -587,7 +587,7 @@
binary software. For other software such as libraries or more
complex stuff with multiple binaries, it should be adapted. Look at
the other <code>*.mk</code> files in the <code>package</code>
- directory.</p>
+ directory. </p>
<p>At lines <a href="#line6">6-11</a>, a couple of useful variables are
defined :</p>
@@ -595,33 +595,33 @@
<ul>
<li><code>FOO_VERSION</code> : The version of <i>foo</i> that
- should be downloaded.</li>
+ should be downloaded. </li>
<li><code>FOO_SOURCE</code> : The name of the tarball of
<i>foo</i> on the download website of FTP site. As you can see
- <code>FOO_VERSION</code> is used.</li>
+ <code>FOO_VERSION</code> is used. </li>
<li><code>FOO_SITE</code> : The HTTP or FTP site from which
<i>foo</i> archive is downloaded. It must include the complete
path to the directory where <code>FOO_SOURCE</code> can be
- found.</li>
+ found. </li>
<li><code>FOO_DIR</code> : The directory into which the software
will be configured and compiled. Basically, it's a subdirectory
of <code>BUILD_DIR</code> which is created upon decompression of
- the tarball.</li>
+ the tarball. </li>
<li><code>FOO_BINARY</code> : Software binary name. As said
- previously, this is an example for a single binary software.</li>
+ previously, this is an example for a single binary software. </li>
<li><code>FOO_TARGET_BINARY</code> : The full path of the binary
- inside the target filesystem.</li>
+ inside the target filesystem. </li>
</ul>
<p>Lines <a href="#line13">13-14</a> defines a target that downloads the
tarball from the remote site to the download directory
- (<code>DL_DIR</code>).</p>
+ (<code>DL_DIR</code>). </p>
<p>Lines <a href="#line16">16-18</a> defines a target and associated rules
that uncompress the downloaded tarball. As you can see, this target
@@ -631,7 +631,7 @@
to mark the software has having been uncompressed. This trick is
used everywhere in Buildroot <i>Makefile</i> to split steps
(download, uncompress, configure, compile, install) while still
- having correct dependencies.</p>
+ having correct dependencies. </p>
<p>Lines <a href="#line20">20-31</a> defines a target and associated rules
that configures the software. It depends on the previous target (the
@@ -643,14 +643,14 @@
<code>/usr</code>, not because the software will be installed in
<code>/usr</code> on your host system, but in the target
filesystem. Finally it creates a <code>.configured</code> file to
- mark the software as configured.</p>
+ mark the software as configured. </p>
<p>Lines <a href="#line33">33-34</a> defines a target and a rule that
compiles the software. This target will create the binary file in the
compilation directory, and depends on the software being already
configured (hence the reference to the <code>.configured</code>
file). It basically runs <code>make</code> inside the source
- directory.</p>
+ directory. </p>
<p>Lines <a href="#line36">36-38</a> defines a target and associated rules
that install the software inside the target filesystem. It depends on the
@@ -661,7 +661,7 @@
the software inside host <code>/usr</code> but inside target
<code>/usr</code>. After the installation, the
<code>/usr/man</code> directory inside the target filesystem is
- removed to save space.</p>
+ removed to save space. </p>
<p>Line <a href="#line40">40</a> defines the main target of the software,
the one that will be eventually be used by the top level
@@ -678,18 +678,18 @@
once for later offline build. Note that if you add a new package providing
a <code>foo-source</code> target is <i>mandatory</i> to support
users that wish to do offline-builds. Furthermore it eases checking
- if all package-sources are downloadable.</p>
+ if all package-sources are downloadable. </p>
<p>Lines <a href="#line44">44-46</a> define a simple target to clean the
software build by calling the <i>Makefiles</i> with the appropriate option.
The <code>-clean</code> target should run <code>make clean</code>
on $(BUILD_DIR)/package-version and MUST uninstall all files of the
- package from $(STAGING_DIR) and from $(TARGET_DIR).</p>
+ package from $(STAGING_DIR) and from $(TARGET_DIR). </p>
<p>Lines <a href="#line48">48-49</a> define a simple target to completely
remove the directory in which the software was uncompressed, configured and
compiled. The <code>-dirclean</code> target MUST completely rm $(BUILD_DIR)/
- package-version.</p>
+ package-version. </p>
<p>Lines <a href="#line51">51-58</a> adds the target <code>foo</code> to
the list of targets to be compiled by Buildroot by first checking if
@@ -699,7 +699,7 @@
global variable. The name added to the TARGETS global
variable is the name of this package's target, as defined on
line <a href="#line40">40</a>, which is used by Buildroot to download,
- compile, and then install this package.</p>
+ compile, and then install this package. </p>
<h3>Conclusion</h3>
@@ -707,7 +707,7 @@
<p>As you can see, adding a software to buildroot is simply a
matter of writing a <i>Makefile</i> using an already existing
example and to modify it according to the compilation process of
- the software.</p>
+ the software. </p>
<p>If you package software that might be useful for other persons,
don't forget to send a patch to Buildroot developers !</p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-08-01 8:11 ulf at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: ulf at uclibc.org @ 2007-08-01 8:11 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2007-08-01 01:11:48 -0700 (Wed, 01 Aug 2007)
New Revision: 19375
Log:
make needs menuconfig to allow configuration
Modified:
trunk/buildroot/docs/README
Changeset:
Modified: trunk/buildroot/docs/README
===================================================================
--- trunk/buildroot/docs/README 2007-08-01 06:17:34 UTC (rev 19374)
+++ trunk/buildroot/docs/README 2007-08-01 08:11:48 UTC (rev 19375)
@@ -1,6 +1,6 @@
To build and use the buildroot stuff, do the following:
-1) run 'make'
+1) run 'make menuconfig'
2) select the packages you wish to compile
3) run 'make'
4) wait while it compiles
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-08-11 21:58 ulf at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: ulf at uclibc.org @ 2007-08-11 21:58 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2007-08-11 14:58:53 -0700 (Sat, 11 Aug 2007)
New Revision: 19441
Log:
Update documentation with advice on completion
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-08-11 21:53:18 UTC (rev 19440)
+++ trunk/buildroot/docs/buildroot.html 2007-08-11 21:58:53 UTC (rev 19441)
@@ -202,6 +202,33 @@
$ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
</pre>
+ <h3><a name="helper_completion" id="helper_completion"></a>
+ Using auto-completion</h3>
+
+ <p>If you are lazy enough that you don't want to type the entire <i>make
+ menuconfig</i> command line, you can enable auto-completion in your shell.
+ Here is how you can do that using <i>bash</i>:</p>
+<pre>
+$ complete -W menuconfig make
+</pre>
+
+ <p>Then just enter the begining of the line, and ask <i>bash</i> to
+ complete it for you by pressing the <i>TAB</i> key:</p>
+<pre>
+$ make me<TAB>
+</pre>
+
+ <p>will result in <i>bash</i> to append <i>nuconfig</i> for you!</p>
+
+ <p>Alternatively, some distributions (of which Debian and Mandriva are but
+ an example) have more powerful make completion. Depending on you
+ distribution, you may have to install a package to enable completion. Under
+ Mandriva, this is <i>bash-completion</i>, while Debian ships it as part of
+ the <i>bash</i> package.</p>
+
+ <p>Other shells, such as <i>zsh</i>, also have completion facilities. See
+ the documentation for your shell.</p>
+
<h2><a name="custom_targetfs" id="custom_targetfs"></a>Customizing the
target filesystem</h2>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-08-12 23:26 ulf at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: ulf at uclibc.org @ 2007-08-12 23:26 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2007-08-12 16:26:28 -0700 (Sun, 12 Aug 2007)
New Revision: 19471
Log:
Cleanup of docs
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-08-12 21:33:06 UTC (rev 19470)
+++ trunk/buildroot/docs/buildroot.html 2007-08-12 23:26:28 UTC (rev 19471)
@@ -15,7 +15,8 @@
<h1>Buildroot</h1>
</div>
- <p><a href="http://buildroot.uclibc.org/">Buildroot</a> usage and documentation by Thomas Petazzoni. Contributions from
+ <p><a href="http://buildroot.uclibc.org/">Buildroot</a>
+ usage and documentation by Thomas Petazzoni. Contributions from
Karsten Kruse, Ned Ludd, Martin Herren and others. </p>
<p><small>$LastChangedDate$</small></p>
@@ -471,7 +472,7 @@
</pre>
<p><b>Important</b> : do not try to move a gcc-3.x toolchain to an other
- directory, it won't work. There are some hard-coded paths in the
+ directory, it won't work. There are some hardcoded paths in the
<i>gcc</i> configuration. If the default toolchain directory
doesn't suit your needs, please refer to the <a
href="#toolchain_standalone">Using the uClibc toolchain outside of
@@ -487,7 +488,7 @@
<code>build_ARCH/staging_dir/</code>. But sometimes, it may be useful to
install it somewhere else, so that it can be used to compile other programs
or by other users. Moving the <code>build_ARCH/staging_dir/</code>
- directory elsewhere is <b>not possible if using gcc-3.x</b>, because they
+ directory elsewhere is <b>not possible if using gcc-3.x</b>, because there
are some hardcoded paths in the toolchain configuration. This works, thanks
to sysroot support, with current, stable gcc-4.x toolchains, of course. </p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-08-16 21:54 ulf at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: ulf at uclibc.org @ 2007-08-16 21:54 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2007-08-16 14:54:48 -0700 (Thu, 16 Aug 2007)
New Revision: 19534
Log:
Add further documentation for BSP patch
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-08-16 18:27:47 UTC (rev 19533)
+++ trunk/buildroot/docs/buildroot.html 2007-08-16 21:54:48 UTC (rev 19534)
@@ -345,14 +345,13 @@
uClibc). </p>
<p>There is basically one Makefile per software, and they are named with
- the <code>.mk</code> extension. Makefiles are split into three
+ the <code>.mk</code> extension. Makefiles are split into four
sections:</p>
<ul>
- <li><b>package</b> (in the <code>package/</code> directory) contains the
- Makefiles and associated files for all user-space tools that Buildroot
- can compile and add to the target root filesystem. There is one
- sub-directory per tool. </li>
+ <li><b>project</b> (in the <code>project/</code> directory) contains
+ the Makefiles and associated files for all software related to the
+ building several root file systems in the same buildroot tree. </li>
<li><b>toolchain</b> (in the <code>toolchain/</code> directory) contains
the Makefiles and associated files for all software related to the
@@ -360,6 +359,11 @@
<code>gcc</code>, <code>gdb</code>, <code>kernel-headers</code> and
<code>uClibc</code>. </li>
+ <li><b>package</b> (in the <code>package/</code> directory) contains the
+ Makefiles and associated files for all user-space tools that Buildroot
+ can compile and add to the target root filesystem. There is one
+ sub-directory per tool. </li>
+
<li><b>target</b> (in the <code>target</code> directory) contains the
Makefiles and associated files for software related to the generation of
the target root filesystem image. Four types of filesystems are supported
@@ -442,6 +446,271 @@
TARGETS global variable. </li>
</ol>
+ <h2><a name="multi_project" id="multi_project"></a>Building several
+ projects in the same buildroot source tree</h2>
+
+ <p><b>BACKGROUND</b></p>
+
+ <p>Buildroot has always supported building several projects in the same
+ tree if each project was for a different architecture. </p>
+
+ <p>The root file system has been created in the
+ <code>"build_<ARCH>/root"</code>
+ directory which is unique for each architecture.
+ Toolchains have been built in
+ <code>"toolchain_build_<ARCH>"</code>. </p>
+
+ <p> It the user wanted to build several root file systems for the same
+ architecture, a prefix or suffix could be added in the configuration file
+ so the root file system would be built in
+ <code>"<PREFIX>_build_<ARCH>_<SUFFIX>/root"</code>
+ By supplying <u>unique</u> combinations of
+ <code>"<PREFIX>"</code> and
+ <code>"<SUFFIX>"</code>
+ each project would get a <u>unique</u> root file system tree. </p>
+
+ <p>The disadvantage of this approach is that a new toolchain was
+ built for each project, adding considerable time to the build
+ process, even if it was two projects for the same chip. </p>
+
+ <p>This drawback has been somewhat lessened with
+ <code>gcc-4.x.y</code> which allows buildroot to use an external
+ toolchain. Certain packages requires special
+ features in the toolchain, and if an external toolchain is selected,
+ this may lack the neccessary features to complete the build of the root
+ file system.</p>
+
+ <p>A bigger problem was that the
+ <code>"build_<ARCH>"</code> tree
+ was also duplicated, so each </code>package</code> would also
+ be rebuilt once per project, resulting in even longer build times.</p>
+
+
+ <p><b>PROJECT TO SHARE TOOLCHAIN AND PACKAGE BUILDS</b></p>
+
+ <p>Work has started on a project which will allow the user to build
+ multiple root file systems for the same architecture in the same tree.
+ The toolchain and the package build directory will be shared, but each
+ project will have a dedicated directory tree for project specific
+ builds. </p>
+
+ <p>With this approach, most, if not all packages will be compiled
+ when the first project is built.
+ The process is almost identical to the original process.
+ Packages are downloaded and extracted to the shared
+ <code>"build_<ARCH>/<package>"</code>
+ directory. They are configured and compiled. </p>
+
+ <p>Package libraries and headers are installed in the shared $(STAGING_DIR),
+ and then the project specific root file system "$(TARGET_DIR)"
+ is populated. </p>
+
+ <p>At the end of the build, the root file system will be used
+ to generate the resulting root file system binaries. </p>
+
+ <p>Once the first project has been built, building other projects will
+ typically involve populating the new project's root file system directory
+ from the existing binaries generated in the shared
+ <code>"build_<ARCH>/<>"</code> directory. </p>
+
+ <p>Only packages, not used by the first project, will have to go
+ through the normal extract-configure-compile flow. </p>
+
+ <p><b>IMPLEMENTATION</b></p>
+
+ <p>The core of the solution is the introduction
+ of two new directories: </p>
+
+ <ul>
+ <li><code>project_build_<ARCH></code></li>
+
+ <li><code>binaries;</code></li>
+ </ul>
+
+ <p>Each of the directories contain one subdirectory per project.
+ The name of the subdirectory is configured by the user in the
+ normal buildroot configuration, using the value of: </p>
+
+ <p><code>Project Options ---> Project name</code></p>
+
+ <p>The configuration defines the $(PROJECT) variable.</p>
+
+ <p>The default project name is <code>"uclibc"</code>.</p>
+
+ <p><code>"package/Makefile.in"</code> defines:
+ <pre>
+ <code>PROJECT_BUILD_DIR:=project_build_$(ARCH)/$(PROJECT)</code>
+ <code>BINARIES_DIR:=binaries/$(PROJECT)</code>
+ </pre>
+ </p>
+
+ <p>It also defines the location for the target root file system:
+ <pre>
+ <code>TARGET_DIR:=$(PROJECT_BUILD_DIR)/$(PROJECT)/root</code>
+ </pre>
+ </p>
+
+ <p>I.E: If the user has choosen
+ <code>"myproject"</code>
+ as the $(PROJECT) name:
+
+ <ul>
+ <li><code>"project_build_<ARCH>/myproject"</code></li>
+ <li><code>"binaries/myproject"</code></li>
+ </ul>
+
+ <p>will be created. </p>
+
+ <p>Currently, the <u>root file system</u>, <u>busybox</u> and an Atmel
+ customized version of
+ <u><code>U-Boot</code></u>, as well as some Atmel specific
+ bootloaders like <u>at91-bootstrap</u> and <u>dataflashboot.bin</u>
+ are built in
+ <code>"$(PROJECT_BUILD_DIR)"</code>
+
+ <p>The resulting binaries for all architectures are stored in the
+ <code>"$(BINARIES_DIR)"</code> directory. <p>
+
+ <p><b>SUMMARY</b></p>
+
+ <p>The project will share directories which can be share without
+ conflicts, but will use unique build directories, where the user
+ can configure the build. </p>
+
+ <p><b>THINGS TO DO</b></p>
+
+ <ol>
+
+ <li>Linux</li>
+
+ <p>The current Linux implementation is flawed. It only works
+ if the user chooses to use one of the few kernels selected
+ as base for the kernel-headers. While the Makefile seems to have
+ hooks, allowing the developer to specify whatever version he/she
+ wants in the target/device/*/* Makefiles, the build will fail
+ if another kernel version is choosen.</p>
+
+ <p>The reason for this is that the kernel patches are not
+ applied by the <code>"target/linux/linux.mk"</code>
+ build script fragment. They are only applied by the
+ <code>"toolchain/kernel-headers/*.makefile"</code>
+ build script fragments</p>
+
+ <p>If the kernel-header version and the linux version differs,
+ there will be two <code>"linux-2.6.X.Y"</code>
+ directories in
+ <code>"build_<ARCH>/<>"</code>,
+ each with its own set of patches. </p>
+
+ <p>The solution in the works, is to move the build of Linux to
+ <code>"project_build_<ARCH>/<project name>/linux-2.6.X.Y"</code> combined with method to configure
+ which patches can be applied. Possibly, the linux source tree
+ used to generate the kernel headers will be moved to the
+ <code>"toolchain_build_<ARCH>"</code>
+ directory
+ </p>
+
+ <p>The user will be able to select from three different
+ Linux strategies:
+
+ <ul>
+ <li>Conservative Strategy: Only use version ssupported by the kernel headers</li>
+ <li>Stable Linux Strategy: Allow any 2.6.X.Y combination.
+ (Minimum 2.6.19)</li>
+ <li>Power-User Strategy: Allow
+ <code>"-git"</code>, or
+ <code>"-mm"</code>, or user downloadable kernels</li>
+ </ul>
+
+ <p>The current kernel patches can be configured to be applied to the
+ linux source tree even if the version differs from the
+ kernel header version. </p>
+
+ <p>Since the user can select any kernel-patch
+ he/she will be able to select a non-working combination.
+ If the patch fails, the user will have to generate a new
+ proprietary kernel-patch or decide to not apply the kernel
+ patches</p>
+
+ <p>Other optional patches will be <u>board specific</u> or
+ <u>architecture specific</u> patches. </p>
+
+ <p>There will also be a way for the user to supply absolute
+ or relative paths to patches, possibly outside the main tree.
+ This can be used to apply custom kernel-header-patches, if
+ the versions available in buildroot cannot be applied to the
+ specific linux version used</p>
+
+ <p>Maybe, there will also be a possibility to supply an
+ <code>"URL"</code> to a patch available on Internet. </p>
+
+ <li>Configurable packages</li>
+
+ <p>Many packages can, on top of the simple
+ "enable/disable build",
+ be further configured using Kconfig.
+ Currently these packages will be compiled using the
+ configuration specified in the
+ <code>".config"</code> file of the <u>first</u>
+ project demanding the build of the package.</p>
+
+ <p>If <u>another</u> project uses the same packages, but with
+ a different configuration,these packages will <u>not</u> be rebuilt,
+ and the root file system for the new project will be populated
+ with files from the build of the <u>first</u> project</p>
+
+ <p>If multiple project are built, and a specific package
+ needs two different configuration, then the user must
+ delete the package from the
+ <code>"build_<ARCH>"</code> directory
+ before rebuilding the new project.<p>
+
+ <p>A long term solution is to edit the package makefile and move
+ the build of the configurable packages from
+ <code>"build_<ARCH>"</code> to
+ <code>"project_build_<ARCH>/<project name>"</code>
+ and send a patch to the buildroot mailing list.
+
+ <li>Naming conventions</li>
+
+ <p>Names of resulting binaries should reflect the
+ "project name"
+
+ <li>Generating File System binaries</li>
+ <p>
+ Packages which needs to be installed with the "root"
+ as owner, will generate a
+ <code>".fakeroot.<package>"</code> file
+ which will be used for the final build of the root file system binary. </p>
+
+ <p>This was previously located in the
+ <code>"$(STAGING_DIR)"</code> directory, but was
+ recently moved to the
+ <code>"$(PROJECT_BUILD_DIR)"</code> directory. </p>
+
+ <p>Currently only three packages:
+ <code>"at"</code>,
+ <code>"ltp-testsuite"</code> and
+ <code>"nfs-utils"</code>
+ requests fakeroot. <p>
+
+ <p>The makefile fragments for each file system type like
+ <code>"ext2"</code>,
+ <code>"jffs2"</code> or
+ <code>"squashfs"</code>
+ will, when the file system binary is generated,
+ collect all present
+ <code>".fakeroot.<package>"</code> files
+ to a single <code>"_fakeroot.<file system>"</code>
+ file and call fakeroot.</p>
+ <code>".fakeroot.<package>"</code>
+ files are deleted as the last action of the Buildroot Makefile. </p>
+
+ <p>It needs to be evaluated if any further action for the
+ file system binary build is needed. </p>
+
+ </ol>
+
<h2><a name="using_toolchain" id="using_toolchain"></a>Using the
uClibc toolchain</h2>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-08-24 5:28 ulf at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: ulf at uclibc.org @ 2007-08-24 5:28 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2007-08-23 22:28:18 -0700 (Thu, 23 Aug 2007)
New Revision: 19669
Log:
Fix spelling error in docs
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-08-24 05:27:17 UTC (rev 19668)
+++ trunk/buildroot/docs/buildroot.html 2007-08-24 05:28:18 UTC (rev 19669)
@@ -213,7 +213,7 @@
$ complete -W menuconfig make
</pre>
- <p>Then just enter the begining of the line, and ask <i>bash</i> to
+ <p>Then just enter the beginning of the line, and ask <i>bash</i> to
complete it for you by pressing the <i>TAB</i> key:</p>
<pre>
$ make me<TAB>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-09-02 17:44 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-09-02 17:44 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-09-02 10:44:09 -0700 (Sun, 02 Sep 2007)
New Revision: 19763
Log:
- document BUSYBOX_CONFIG_FILE
Modified:
trunk/buildroot/docs/README
Changeset:
Modified: trunk/buildroot/docs/README
===================================================================
--- trunk/buildroot/docs/README 2007-09-02 15:28:30 UTC (rev 19762)
+++ trunk/buildroot/docs/README 2007-09-02 17:44:09 UTC (rev 19763)
@@ -32,6 +32,9 @@
You can specify a config-file for uClibc:
$ make UCLIBC_CONFIG_FILE=/my/uClibc.config
+And you can specify a config-file for busybox:
+$ make BUSYBOX_CONFIG_FILE=/my/busybox.config
+
To use a non-standart host-compiler (if you do not have 'gcc'),
make sure that the compiler is in your PATH and that the library paths are
setup properly, if your compiler is built dynamically:
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-09-19 9:08 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-09-19 9:08 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-09-19 02:08:10 -0700 (Wed, 19 Sep 2007)
New Revision: 19882
Log:
- trivial style fixes.
TODO: document HAVE_MANPAGES and HAVE_INFOPAGES (and adjust line-numbers in the text accordingly)
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2007-09-19 08:50:54 UTC (rev 19881)
+++ trunk/buildroot/docs/buildroot.html 2007-09-19 09:08:10 UTC (rev 19882)
@@ -899,16 +899,16 @@
<a name="line18" id="line18">18</a> touch $@
<a name="line19" id="line19">19</a>
<a name="line20" id="line20">20</a> $(FOO_DIR)/.configured: $(FOO_DIR)/.source
- <a name="line21" id="line21">21</a> (cd $(FOO_DIR); rm -rf config.cache ; \
+ <a name="line21" id="line21">21</a> (cd $(FOO_DIR); rm -rf config.cache; \
<a name="line22" id="line22">22</a> $(TARGET_CONFIGURE_OPTS) \
- <a name="line23" id="line23">23</a> CFLAGS="$(TARGET_CFLAGS)" \
+ <a name="line23" id="line23">23</a> $(TARGET_CONFIGURE_ARGS) \
<a name="line24" id="line24">24</a> ./configure \
<a name="line25" id="line25">25</a> --target=$(GNU_TARGET_NAME) \
<a name="line26" id="line26">26</a> --host=$(GNU_TARGET_NAME) \
<a name="line27" id="line27">27</a> --build=$(GNU_HOST_NAME) \
<a name="line28" id="line28">28</a> --prefix=/usr \
<a name="line29" id="line29">29</a> --sysconfdir=/etc \
- <a name="line30" id="line30">30</a> );
+ <a name="line30" id="line30">30</a> )
<a name="line31" id="line31">31</a> touch $@
<a name="line32" id="line32">32</a>
<a name="line33" id="line33">33</a> $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2007-09-27 21:32 aldot at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: aldot at uclibc.org @ 2007-09-27 21:32 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2007-09-27 14:32:50 -0700 (Thu, 27 Sep 2007)
New Revision: 20073
Log:
- add a sample README.diskimage for i386
Added:
trunk/buildroot/docs/README.diskimage
Changeset:
Added: trunk/buildroot/docs/README.diskimage
===================================================================
--- trunk/buildroot/docs/README.diskimage (rev 0)
+++ trunk/buildroot/docs/README.diskimage 2007-09-27 21:32:50 UTC (rev 20073)
@@ -0,0 +1,37 @@
+# Sample for i386 to create a 6MB disk-image
+
+# create an image file
+dd if=/dev/zero bs=512 count=$((6*1024*1024/512)) of=img
+# create a partition (optional)
+echo -e "n\np\n1\n\nw\n" | \
+ ~/src/busybox/busybox fdisk -C 16065 -H 255 -S 63 ./img
+# as root, associate the image with a look-device:
+# The offset of 512 comes from the the layout of the image. See
+# ~/src/busybox/busybox fdisk -C 16065 -H 255 -S 63 -l ./img for the start
+# block and multiply this with the block size (==512).
+~/src/busybox/busybox losetup -o 512 /dev/loop/0 /path/to/the/img
+# create some filesystem on it, for example ext2
+mkfs.ext2 -m0 -Lslash /dev/loop/0
+# mount it and copy your stuff to it
+~/src/busybox/busybox mount -oloop,rw /dev/loop/0 /media/l0
+~/src/busybox/busybox mkdir -p /media/l0/boot/grub
+~/src/busybox/busybox cp -a project_build_i386/root/boot/grub/stage? /media/l0/boot/grub/
+~/src/busybox/busybox cp -a project_build_i386/root/boot/bzImage /media/l0/boot/
+~/src/busybox/busybox cat > /media/l0/boot/grub/menu.lst <<EOF
+title=GNU/Linux
+root (hd0,0)
+kernel /boot/bzImage
+EOF
+# finally unmount the dist and disassociate the loopdev
+~/src/busybox/busybox umount /media/l0
+~/src/busybox/busybox losetup -d /dev/loop/0
+# now install grub from the chroot
+~/src/busybox/busybox losetup /dev/loop/0 /path/to/the/img
+project_build_i386/root/usr/sbin/grub --device-map=/dev/null
+device (hd0) img
+geometry (hd0) 16065 255 63
+root (hd0,0)
+setup (hd0)
+quit
+# finally boot the thing
+/opt/qemu-trunk_ggi-2.2.2/bin/qemu -snapshot -hda img -boot c
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2008-03-13 17:16 ninevoltz at uclibc.org
2008-03-13 18:25 ` Peter Korsgaard
0 siblings, 1 reply; 59+ messages in thread
From: ninevoltz at uclibc.org @ 2008-03-13 17:16 UTC (permalink / raw)
To: buildroot
Author: ninevoltz
Date: 2008-03-13 10:16:30 -0700 (Thu, 13 Mar 2008)
New Revision: 21326
Log:
add some documentation about buildroot's patch system
Added:
trunk/buildroot/docs/patches.html
Changeset:
Added: trunk/buildroot/docs/patches.html
===================================================================
--- trunk/buildroot/docs/patches.html (rev 0)
+++ trunk/buildroot/docs/patches.html 2008-03-13 17:16:30 UTC (rev 21326)
@@ -0,0 +1,43 @@
+<!--#include file="header.html" -->
+
+<h2>Buildroot patch structure</h2>
+
+<p>
+<h4>Keeping track of applied patches</h4>
+Whenever a patch is applied to a source code directory in buildroot, a text file named .applied_patches_list is created inside that source directory.
+This file contains a list of all the patch filenames that were applied to that source code, just for reference.
+</p>
+
+<p>
+<h4>Linux kernel patches</h4>
+The Linux kernel has several patch levels available for it in the buildroot patch system.
+Buildroot first downloads the chosen kernel source from the mirror site, followed by any selected minor patch.
+Buildroot then extracts the kernel source from the compressed file and applies the minor patch, if one was chosen.
+After extracting the source and applying the official minor patch, buildroot looks for more patches in the following locations and in the order shown:
+
+<ol>
+<li> a custom, user downloaded kernel patch can be located in $(DL_DIR) and the filename is stored as $(LINUX26_BSP_PATCH) </li>
+<li> Atmel keeps their official kernel patches in target/device/Atmel/Linux/kernel-patches with subdirectories for each kernel release.
+They also keep any board-specific patches in $(BR2_BOARD_PATH) </li>
+<li> globally available patches are kept in toolchain/kernel-headers </li>
+<li> IPMI (<a href="http://www.intel.com/design/servers/ipmi/ipmi.htm">Intelligent Platform Management Interface</a>)
+kernel patches are kept in toolchain/kernel-headers/ipmi </li>
+<li> LZMA kernel compression support patches are kept in toolchain/kernel-headers/lzma </li>
+<li> <a href="http://www.realtimelinuxfoundation.org/downloads/downloads.html">Real-time Linux kernel</a> patches are kept in $(LINUX_RT_SOURCE) </li>
+<li> <a href="http://www.openswan.org/">Openswan</a> kernel patches are kept in package/openswan </li>
+</ol>
+</p>
+
+ <p>
+ <h4>Package source patches</h4>
+ Any patches for the Linux programs supported by buildroot are kept in that program's corresponding package/ directory.
+ </p>
+
+ <p>
+ <h4>How the patching is done</h4>
+Patches are applied in buildroot by running a shell script called toolchain/patch-kernel.sh with three arguments. The first argument is the target directory
+where the source code to be patched is saved. The second argument is the directory where the patch is saved. The third argument is the filename pattern
+to match when looking in the patch directory. The third argument can include wildcards to select multiple patch files.
+</p>
+
+<!--#include file="footer.html" -->
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
2008-03-13 17:16 ninevoltz at uclibc.org
@ 2008-03-13 18:25 ` Peter Korsgaard
0 siblings, 0 replies; 59+ messages in thread
From: Peter Korsgaard @ 2008-03-13 18:25 UTC (permalink / raw)
To: buildroot
>>>>> "ninevoltz" == ninevoltz <ninevoltz@uclibc.org> writes:
ninevoltz> Author: ninevoltz
ninevoltz> Date: 2008-03-13 10:16:30 -0700 (Thu, 13 Mar 2008)
ninevoltz> New Revision: 21326
ninevoltz> Log:
ninevoltz> add some documentation about buildroot's patch system
ninevoltz> Added:
ninevoltz> trunk/buildroot/docs/patches.html
ninevoltz> Changeset:
ninevoltz> Added: trunk/buildroot/docs/patches.html
ninevoltz> ===================================================================
ninevoltz> --- trunk/buildroot/docs/patches.html (rev 0)
ninevoltz> +++ trunk/buildroot/docs/patches.html 2008-03-13 17:16:30 UTC (rev 21326)
ninevoltz> @@ -0,0 +1,43 @@
ninevoltz> +<!--#include file="header.html" -->
ninevoltz> +
ninevoltz> +<h2>Buildroot patch structure</h2>
ninevoltz> +
ninevoltz> +<p>
ninevoltz> +<h4>Keeping track of applied patches</h4>
ninevoltz> +Whenever a patch is applied to a source code directory in buildroot, a text file named .applied_patches_list is created inside that source directory.
Please try to keep the lines <80 chars like the rest of the
documentation.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2008-06-23 13:40 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2008-06-23 13:40 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2008-06-23 06:40:34 -0700 (Mon, 23 Jun 2008)
New Revision: 22480
Log:
README: s/standart/standard/
Modified:
trunk/buildroot/docs/README
Changeset:
Modified: trunk/buildroot/docs/README
===================================================================
--- trunk/buildroot/docs/README 2008-06-23 13:24:19 UTC (rev 22479)
+++ trunk/buildroot/docs/README 2008-06-23 13:40:34 UTC (rev 22480)
@@ -35,7 +35,7 @@
And you can specify a config-file for busybox:
$ make BUSYBOX_CONFIG_FILE=/my/busybox.config
-To use a non-standart host-compiler (if you do not have 'gcc'),
+To use a non-standard host-compiler (if you do not have 'gcc'),
make sure that the compiler is in your PATH and that the library paths are
setup properly, if your compiler is built dynamically:
$ make HOSTCC=gcc-4.3.orig HOSTCXX=gcc-4.3-mine
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2008-10-06 9:11 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2008-10-06 9:11 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2008-10-06 02:11:57 -0700 (Mon, 06 Oct 2008)
New Revision: 23590
Log:
README: document out-of-tree build support
Modified:
trunk/buildroot/docs/README
Changeset:
Modified: trunk/buildroot/docs/README
===================================================================
--- trunk/buildroot/docs/README 2008-10-06 08:56:48 UTC (rev 23589)
+++ trunk/buildroot/docs/README 2008-10-06 09:11:57 UTC (rev 23590)
@@ -26,6 +26,17 @@
and issue "make source" there, then copy the content of your dl/ dir to
the build-host.
+Building out-of-tree:
+=====================
+
+Buildroot supports building out of tree with a syntax similar
+to the Linux kernel. To use it, add O=<directory> to the
+make command line, E.G.:
+
+$ make O=/tmp/build
+
+And all the output files will be located under /tmp/build.
+
More finegrained configuration:
===============================
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2008-10-14 16:20 aldot at uclibc.org
2008-10-18 6:58 ` Peter Korsgaard
0 siblings, 1 reply; 59+ messages in thread
From: aldot at uclibc.org @ 2008-10-14 16:20 UTC (permalink / raw)
To: buildroot
Author: aldot
Date: 2008-10-14 09:20:55 -0700 (Tue, 14 Oct 2008)
New Revision: 23678
Log:
- extend documentation to mention adding package/foo/Config.in to package/Config.in
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2008-10-14 15:16:20 UTC (rev 23677)
+++ trunk/buildroot/docs/buildroot.html 2008-10-14 16:20:55 UTC (rev 23678)
@@ -882,7 +882,19 @@
<p>Of course, you can add other options to configure particular
things in your software. </p>
-
+ <p>Finally you have to add your new <code>foo/Config.in</code> to
+ <code>package/Config.in</code>. The files included there are
+ <em>sorted alphabetically</em> per category and are <em>NOT<em>
+ supposed to contain anything but the <em>bare</em> name of the package.</p>
+<pre>
+if !BR2_PACKAGE_BUSYBOX_HIDE_OTHERS
+source "package/procps/Config.in"
+endif
+</pre>
+ <p><strong>Note:</strong><br>
+ Generally all packages should live <em>directly</em> in the
+ <code>package</code> directory to make it easier to find them.
+ </p>
<h3>The real <i>Makefile</i></h3>
<p>Finally, here's the hardest part. Create a file named
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
2008-10-14 16:20 aldot at uclibc.org
@ 2008-10-18 6:58 ` Peter Korsgaard
0 siblings, 0 replies; 59+ messages in thread
From: Peter Korsgaard @ 2008-10-18 6:58 UTC (permalink / raw)
To: buildroot
>>>>> "aldot" == aldot <aldot@uclibc.org> writes:
aldot> Author: aldot
aldot> Date: 2008-10-14 09:20:55 -0700 (Tue, 14 Oct 2008)
aldot> New Revision: 23678
aldot> Log:
aldot> - extend documentation to mention adding package/foo/Config.in to package/Config.in
aldot> +if !BR2_PACKAGE_BUSYBOX_HIDE_OTHERS
aldot> +source "package/procps/Config.in"
aldot> +endif
aldot> +</pre>
aldot> + <p><strong>Note:</strong><br>
aldot> + Generally all packages should live <em>directly</em> in the
aldot> + <code>package</code> directory to make it easier to find them.
aldot> + </p>
Is that the agreement we have? It seems to be counter to the latest
changes (package/audio, package/database, ..)
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2008-12-08 8:15 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2008-12-08 8:15 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2008-12-08 00:15:46 -0800 (Mon, 08 Dec 2008)
New Revision: 24309
Log:
docs/: get rid of unneeded $(strip ..)
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2008-12-08 08:15:42 UTC (rev 24308)
+++ trunk/buildroot/docs/buildroot.html 2008-12-08 08:15:46 UTC (rev 24309)
@@ -959,7 +959,7 @@
<a name="line53" id="line53">53</a> # Toplevel Makefile options
<a name="line54" id="line54">54</a> #
<a name="line55" id="line55">55</a> #############################################################
- <a name="line56" id="line56">56</a> ifeq ($(strip $(BR2_PACKAGE_FOO)),y)
+ <a name="line56" id="line56">56</a> ifeq ($(BR2_PACKAGE_FOO),y)
<a name="line57" id="line57">57</a> TARGETS+=foo
<a name="line58" id="line58">58</a> endif
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2008-12-15 22:14 tpetazzoni at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: tpetazzoni at uclibc.org @ 2008-12-15 22:14 UTC (permalink / raw)
To: buildroot
Author: tpetazzoni
Date: 2008-12-15 14:14:02 -0800 (Mon, 15 Dec 2008)
New Revision: 24427
Log:
Mention another important benefit of Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2008-12-15 22:07:38 UTC (rev 24426)
+++ trunk/buildroot/docs/buildroot.html 2008-12-15 22:14:02 UTC (rev 24427)
@@ -108,6 +108,12 @@
each <code>gcc</code> and <code>binutils</code> version to make them work
on most architectures. </p>
+ <p>Moreover, Buildroot provides an infrastructure for reproducing
+ the build process of your embedded root filesystem. Being able to
+ reproduce the build process will be useful when a component needs
+ to be patched or updated, or when another person is supposed to
+ take over the project.</p>
+
<h2><a name="download" id="download"></a>Obtaining Buildroot</h2>
<p>Buildroot is available as daily SVN snapshots or directly using
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2008-12-15 22:35 tpetazzoni at uclibc.org
2008-12-15 22:44 ` Thomas Petazzoni
2008-12-16 9:00 ` Peter Korsgaard
0 siblings, 2 replies; 59+ messages in thread
From: tpetazzoni at uclibc.org @ 2008-12-15 22:35 UTC (permalink / raw)
To: buildroot
Author: tpetazzoni
Date: 2008-12-15 14:35:09 -0800 (Mon, 15 Dec 2008)
New Revision: 24428
Log:
Documentation fixes and updates
The biggest update is to document the Makefile.autotools.in way of
writing .mk files.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2008-12-15 22:14:02 UTC (rev 24427)
+++ trunk/buildroot/docs/buildroot.html 2008-12-15 22:35:09 UTC (rev 24428)
@@ -117,7 +117,7 @@
<h2><a name="download" id="download"></a>Obtaining Buildroot</h2>
<p>Buildroot is available as daily SVN snapshots or directly using
- SVN. </p>
+ SVN. As of today, no stable releases of Buildroot are made. </p>
<p>The latest snapshot is always available at <a
href="http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2">http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2</a>,
@@ -444,7 +444,7 @@
</ul>
<p>The main Makefile do the job through the following steps (once the
- configuration is done):</p>
+ configuration is done) :</p>
<ol>
<li>Create the download directory (<code>dl/</code> by default). This is
@@ -890,7 +890,7 @@
things in your software. </p>
<p>Finally you have to add your new <code>foo/Config.in</code> to
<code>package/Config.in</code>. The files included there are
- <em>sorted alphabetically</em> per category and are <em>NOT<em>
+ <em>sorted alphabetically</em> per category and are <em>NOT</em>
supposed to contain anything but the <em>bare</em> name of the package.</p>
<pre>
if !BR2_PACKAGE_BUSYBOX_HIDE_OTHERS
@@ -906,69 +906,140 @@
<p>Finally, here's the hardest part. Create a file named
<code>foo.mk</code>. It will contain the <i>Makefile</i> rules that
are in charge of downloading, configuring, compiling and installing
- the software. Below is an example that we will comment
- afterwards. </p>
+ the software.</p>
+ <p>Two types of <i>Makefiles</i> can be written :</p>
+
+ <ul>
+ <li>Makefile for autotools-based (autoconf, automake, etc.)
+ softwares, are very easy to write thanks to the infrastructure
+ available in <code>package/Makefile.autotools.in</code>.</li>
+ <li>Makefile for other types of packages are a little bit more
+ complex to write.</li>
+ </ul>
+
+ <p>First, let's see how to write a <i>Makefile</i> for an
+ autotools-based package, with an example :</p>
+
<pre>
- <a name="line1" id="line1">1</a> #############################################################
- <a name="line2" id="line2">2</a> #
- <a name="line3" id="line3">3</a> # foo
- <a name="line4" id="line4">4</a> #
- <a name="line5" id="line5">5</a> #############################################################
- <a name="line6" id="line6">6</a> FOO_VERSION:=1.0
- <a name="line7" id="line7">7</a> FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
- <a name="line8" id="line8">8</a> FOO_SITE:=http://www.foosoftware.org/downloads
- <a name="line9" id="line9">9</a> FOO_DIR:=$(BUILD_DIR)/foo-$(FOO_VERSION)
- <a name="line10" id="line10">10</a> FOO_BINARY:=foo
- <a name="line11" id="line11">11</a> FOO_TARGET_BINARY:=usr/bin/foo
- <a name="line12" id="line12">12</a>
- <a name="line13" id="line13">13</a> $(DL_DIR)/$(FOO_SOURCE):
- <a name="line14" id="line14">14</a> $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)
- <a name="line15" id="line15">15</a>
- <a name="line16" id="line16">16</a> $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
- <a name="line17" id="line17">17</a> $(ZCAT) $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
- <a name="line18" id="line18">18</a> touch $@
- <a name="line19" id="line19">19</a>
- <a name="line20" id="line20">20</a> $(FOO_DIR)/.configured: $(FOO_DIR)/.source
- <a name="line21" id="line21">21</a> (cd $(FOO_DIR); rm -rf config.cache; \
- <a name="line22" id="line22">22</a> $(TARGET_CONFIGURE_OPTS) \
- <a name="line23" id="line23">23</a> $(TARGET_CONFIGURE_ARGS) \
- <a name="line24" id="line24">24</a> ./configure \
- <a name="line25" id="line25">25</a> --target=$(GNU_TARGET_NAME) \
- <a name="line26" id="line26">26</a> --host=$(GNU_TARGET_NAME) \
- <a name="line27" id="line27">27</a> --build=$(GNU_HOST_NAME) \
- <a name="line28" id="line28">28</a> --prefix=/usr \
- <a name="line29" id="line29">29</a> --sysconfdir=/etc \
- <a name="line30" id="line30">30</a> )
- <a name="line31" id="line31">31</a> touch $@
- <a name="line32" id="line32">32</a>
- <a name="line33" id="line33">33</a> $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
- <a name="line34" id="line34">34</a> $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
- <a name="line35" id="line35">35</a>
- <a name="line36" id="line36">36</a> $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
- <a name="line37" id="line37">37</a> $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
- <a name="line38" id="line38">38</a> rm -Rf $(TARGET_DIR)/usr/man
- <a name="line39" id="line39">39</a>
- <a name="line40" id="line40">40</a> foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
- <a name="line41" id="line41">41</a>
- <a name="line42" id="line42">42</a> foo-source: $(DL_DIR)/$(FOO_SOURCE)
- <a name="line43" id="line43">43</a>
- <a name="line44" id="line44">44</a> foo-clean:
- <a name="line45" id="line45">45</a> $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
- <a name="line46" id="line46">46</a> -$(MAKE) -C $(FOO_DIR) clean
- <a name="line47" id="line47">47</a>
- <a name="line48" id="line48">48</a> foo-dirclean:
- <a name="line49" id="line49">49</a> rm -rf $(FOO_DIR)
- <a name="line50" id="line50">50</a>
- <a name="line51" id="line51">51</a> #############################################################
- <a name="line52" id="line52">52</a> #
- <a name="line53" id="line53">53</a> # Toplevel Makefile options
- <a name="line54" id="line54">54</a> #
- <a name="line55" id="line55">55</a> #############################################################
- <a name="line56" id="line56">56</a> ifeq ($(BR2_PACKAGE_FOO),y)
- <a name="line57" id="line57">57</a> TARGETS+=foo
- <a name="line58" id="line58">58</a> endif
+ <a name="ex1line1" id="ex1line1">1</a> #############################################################
+ <a name="ex1line2" id="ex1line2">2</a> #
+ <a name="ex1line3" id="ex1line3">3</a> # foo
+ <a name="ex1line4" id="ex1line4">4</a> #
+ <a name="ex1line5" id="ex1line5">5</a> #############################################################
+ <a name="ex1line6" id="ex1line6">6</a> FOO_VERSION:=1.0
+ <a name="ex1line7" id="ex1line7">7</a> FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
+ <a name="ex1line8" id="ex1line8">8</a> FOO_SITE:=http://www.foosoftware.org/downloads
+ <a name="ex1line9" id="ex1line9">9</a> FOO_INSTALL_STAGING = YES
+ <a name="ex1line10" id="ex1line10">10</a> FOO_INSTALL_TARGET = YES
+ <a name="ex1line11" id="ex1line11">11</a> FOO_CONF_OPT = --enable-shared
+ <a name="ex1line12" id="ex1line12">12</a> FOO_DEPENDENCIES = libglib2 pkgconfig
+ <a name="ex1line13" id="ex1line13">13</a> $(eval $(call AUTOTARGETS,package,foo))
+</pre>
+ <p>On <a href="#ex1line6">line 6</a>, we declare the version of
+ the package. On line <a href="#ex1line7">7</a> and <a
+ href="#ex1line8">8</a>, we declare the name of the tarball and the
+ location of the tarball on the Web. Buildroot will automatically
+ download the tarball from this location.</p>
+
+ <p>On <a href="#ex1line9">line 9</a>, we tell Buildroot to install
+ the application to the staging directory. The staging directory,
+ located in <code>build_ARCH/staging_dir/</code> is the directory
+ where all the packages are installed, including their
+ documentation, etc. By default, packages are installed in this
+ location using the <code>make install</code> command.</p>
+
+ <p>On <a href="#ex1line10">line 10</a>, we tell Buildroot to also
+ install the application to the target directory. This directory
+ contains what will become the root filesystem running on the
+ target. Usually, we try not to install the documentation, and to
+ install stripped versions of the binary. By default, packages are
+ installed in this location using the <code>make
+ install-strip</code> command.</p>
+
+ <p>On <a href="#ex1line11">line 11</a>, we tell Buildroot to pass
+ a custom configure option, that will be passed to the
+ <code>./configure</code> script before configuring and building
+ the package.</p>
+
+ <p>On <a href="#ex1line12">line 12</a>, we declare our
+ dependencies, so that they are built before the build process of
+ our package starts.</p>
+
+ <p>Finally, on line <a href="#ex1line13">line 13</a>, we invoke
+ the <code>package/Makefile.autotools.in</code> magic to get things
+ working.</p>
+
+ <p>For more details about the available variables and options, see
+ the comment at the top of
+ <code>package/Makefile.autotools.in</code> and the examples in all
+ the available packages.</p>
+
+ <p>The second solution, suitable for every type of package, looks
+ like this :</p>
+
+
+<pre>
+ <a name="ex2line1" id="ex2line1">1</a> #############################################################
+ <a name="ex2line2" id="ex2line2">2</a> #
+ <a name="ex2line3" id="ex2line3">3</a> # foo
+ <a name="ex2line4" id="ex2line4">4</a> #
+ <a name="ex2line5" id="ex2line5">5</a> #############################################################
+ <a name="ex2line6" id="ex2line6">6</a> FOO_VERSION:=1.0
+ <a name="ex2line7" id="ex2line7">7</a> FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
+ <a name="ex2line8" id="ex2line8">8</a> FOO_SITE:=http://www.foosoftware.org/downloads
+ <a name="ex2line9" id="ex2line9">9</a> FOO_DIR:=$(BUILD_DIR)/foo-$(FOO_VERSION)
+ <a name="ex2line10" id="ex2line10">10</a> FOO_BINARY:=foo
+ <a name="ex2line11" id="ex2line11">11</a> FOO_TARGET_BINARY:=usr/bin/foo
+ <a name="ex2line12" id="ex2line12">12</a>
+ <a name="ex2line13" id="ex2line13">13</a> $(DL_DIR)/$(FOO_SOURCE):
+ <a name="ex2line14" id="ex2line14">14</a> $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)
+ <a name="ex2line15" id="ex2line15">15</a>
+ <a name="ex2line16" id="ex2line16">16</a> $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
+ <a name="ex2line17" id="ex2line17">17</a> $(ZCAT) $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
+ <a name="ex2line18" id="ex2line18">18</a> touch $@
+ <a name="ex2line19" id="ex2line19">19</a>
+ <a name="ex2line20" id="ex2line20">20</a> $(FOO_DIR)/.configured: $(FOO_DIR)/.source
+ <a name="ex2line21" id="ex2line21">21</a> (cd $(FOO_DIR); rm -rf config.cache; \
+ <a name="ex2line22" id="ex2line22">22</a> $(TARGET_CONFIGURE_OPTS) \
+ <a name="ex2line23" id="ex2line23">23</a> $(TARGET_CONFIGURE_ARGS) \
+ <a name="ex2line24" id="ex2line24">24</a> ./configure \
+ <a name="ex2line25" id="ex2line25">25</a> --target=$(GNU_TARGET_NAME) \
+ <a name="ex2line26" id="ex2line26">26</a> --host=$(GNU_TARGET_NAME) \
+ <a name="ex2line27" id="ex2line27">27</a> --build=$(GNU_HOST_NAME) \
+ <a name="ex2line28" id="ex2line28">28</a> --prefix=/usr \
+ <a name="ex2line29" id="ex2line29">29</a> --sysconfdir=/etc \
+ <a name="ex2line30" id="ex2line30">30</a> )
+ <a name="ex2line31" id="ex2line31">31</a> touch $@
+ <a name="ex2line32" id="ex2line32">32</a>
+ <a name="ex2line33" id="ex2line33">33</a> $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
+ <a name="ex2line34" id="ex2line34">34</a> $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
+ <a name="ex2line35" id="ex2line35">35</a>
+ <a name="ex2line36" id="ex2line36">36</a> $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
+ <a name="ex2line37" id="ex2line37">37</a> $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
+ <a name="ex2line38" id="ex2line38">38</a> rm -Rf $(TARGET_DIR)/usr/man
+ <a name="ex2line39" id="ex2line39">39</a>
+ <a name="ex2line40" id="ex2line40">40</a> foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
+ <a name="ex2line41" id="ex2line41">41</a>
+ <a name="ex2line42" id="ex2line42">42</a> foo-source: $(DL_DIR)/$(FOO_SOURCE)
+ <a name="ex2line43" id="ex2line43">43</a>
+ <a name="ex2line44" id="ex2line44">44</a> foo-clean:
+ <a name="ex2line45" id="ex2line45">45</a> $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
+ <a name="ex2line46" id="ex2line46">46</a> -$(MAKE) -C $(FOO_DIR) clean
+ <a name="ex2line47" id="ex2line47">47</a>
+ <a name="ex2line48" id="ex2line48">48</a> foo-dirclean:
+ <a name="ex2line49" id="ex2line49">49</a> rm -rf $(FOO_DIR)
+ <a name="ex2line50" id="ex2line50">50</a>
+ <a name="ex2line51" id="ex2line51">51</a> #############################################################
+ <a name="ex2line52" id="ex2line52">52</a> #
+ <a name="ex2line53" id="ex2line53">53</a> # Toplevel Makefile options
+ <a name="ex2line54" id="ex2line54">54</a> #
+ <a name="ex2line55" id="ex2line55">55</a> #############################################################
+ <a name="ex2line56" id="ex2line56">56</a> ifeq ($(BR2_PACKAGE_FOO),y)
+ <a name="ex2line57" id="ex2line57">57</a> TARGETS+=foo
+ <a name="ex2line58" id="ex2line58">58</a> endif
+
</pre>
<p>First of all, this <i>Makefile</i> example works for a single
@@ -977,7 +1048,7 @@
the other <code>*.mk</code> files in the <code>package</code>
directory. </p>
- <p>At lines <a href="#line6">6-11</a>, a couple of useful variables are
+ <p>At lines <a href="#ex2line6">6-11</a>, a couple of useful variables are
defined :</p>
<ul>
@@ -1007,21 +1078,21 @@
</ul>
- <p>Lines <a href="#line13">13-14</a> defines a target that downloads the
+ <p>Lines <a href="#ex2line13">13-14</a> defines a target that downloads the
tarball from the remote site to the download directory
(<code>DL_DIR</code>). </p>
- <p>Lines <a href="#line16">16-18</a> defines a target and associated rules
+ <p>Lines <a href="#ex2line16">16-18</a> defines a target and associated rules
that uncompress the downloaded tarball. As you can see, this target
depends on the tarball file, so that the previous target (line
- <a href="#line13">13-14</a>) is called before executing the rules of the
+ <a href="#ex2line13">13-14</a>) is called before executing the rules of the
current target. Uncompressing is followed by <i>touching</i> a hidden file
to mark the software has having been uncompressed. This trick is
used everywhere in Buildroot <i>Makefile</i> to split steps
(download, uncompress, configure, compile, install) while still
having correct dependencies. </p>
- <p>Lines <a href="#line20">20-31</a> defines a target and associated rules
+ <p>Lines <a href="#ex2line20">20-31</a> defines a target and associated rules
that configures the software. It depends on the previous target (the
hidden <code>.source</code> file) so that we are sure the software has
been uncompressed. In order to configure it, it basically runs the
@@ -1033,14 +1104,14 @@
filesystem. Finally it creates a <code>.configured</code> file to
mark the software as configured. </p>
- <p>Lines <a href="#line33">33-34</a> defines a target and a rule that
+ <p>Lines <a href="#ex2line33">33-34</a> defines a target and a rule that
compiles the software. This target will create the binary file in the
compilation directory, and depends on the software being already
configured (hence the reference to the <code>.configured</code>
file). It basically runs <code>make</code> inside the source
directory. </p>
- <p>Lines <a href="#line36">36-38</a> defines a target and associated rules
+ <p>Lines <a href="#ex2line36">36-38</a> defines a target and associated rules
that install the software inside the target filesystem. It depends on the
binary file in the source directory, to make sure the software has
been compiled. It uses the <code>install</code> target of the
@@ -1051,7 +1122,7 @@
<code>/usr/man</code> directory inside the target filesystem is
removed to save space. </p>
- <p>Line <a href="#line40">40</a> defines the main target of the software,
+ <p>Line <a href="#ex2line40">40</a> defines the main target of the software,
the one that will be eventually be used by the top level
<code>Makefile</code> to download, compile, and then install
this package. This target should first of all depends on all
@@ -1060,7 +1131,7 @@
final binary. This last dependency will call all previous
dependencies in the correct order. </p>
- <p>Line <a href="#line42">42</a> defines a simple target that only
+ <p>Line <a href="#ex2line42">42</a> defines a simple target that only
downloads the code source. This is not used during normal operation of
Buildroot, but is needed if you intend to download all required sources at
once for later offline build. Note that if you add a new package providing
@@ -1068,25 +1139,25 @@
users that wish to do offline-builds. Furthermore it eases checking
if all package-sources are downloadable. </p>
- <p>Lines <a href="#line44">44-46</a> define a simple target to clean the
+ <p>Lines <a href="#ex2line44">44-46</a> define a simple target to clean the
software build by calling the <i>Makefiles</i> with the appropriate option.
The <code>-clean</code> target should run <code>make clean</code>
on $(BUILD_DIR)/package-version and MUST uninstall all files of the
package from $(STAGING_DIR) and from $(TARGET_DIR). </p>
- <p>Lines <a href="#line48">48-49</a> define a simple target to completely
+ <p>Lines <a href="#ex2line48">48-49</a> define a simple target to completely
remove the directory in which the software was uncompressed, configured and
compiled. The <code>-dirclean</code> target MUST completely rm $(BUILD_DIR)/
package-version. </p>
- <p>Lines <a href="#line51">51-58</a> adds the target <code>foo</code> to
+ <p>Lines <a href="#ex2line51">51-58</a> adds the target <code>foo</code> to
the list of targets to be compiled by Buildroot by first checking if
the configuration option for this package has been enabled
using the configuration tool, and if so then "subscribes"
this package to be compiled by adding it to the TARGETS
global variable. The name added to the TARGETS global
variable is the name of this package's target, as defined on
- line <a href="#line40">40</a>, which is used by Buildroot to download,
+ line <a href="#ex2line40">40</a>, which is used by Buildroot to download,
compile, and then install this package. </p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
2008-12-15 22:35 tpetazzoni at uclibc.org
@ 2008-12-15 22:44 ` Thomas Petazzoni
2008-12-16 9:03 ` Peter Korsgaard
2008-12-16 9:00 ` Peter Korsgaard
1 sibling, 1 reply; 59+ messages in thread
From: Thomas Petazzoni @ 2008-12-15 22:44 UTC (permalink / raw)
To: buildroot
Le Mon, 15 Dec 2008 14:35:09 -0800 (PST),
tpetazzoni at uclibc.org a ?crit :
> Documentation fixes and updates
BTW, the documentation contains a big ?Building several projects in the
same buildroot source tree? section, which IMHO, has nothing to do in
an user manual. It describes unimplemented things, historical
reasons, has a TODO-list, and so on.
Is the author of this section on the list ? If so, could he mention
what the intention was ?
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
2008-12-15 22:35 tpetazzoni at uclibc.org
2008-12-15 22:44 ` Thomas Petazzoni
@ 2008-12-16 9:00 ` Peter Korsgaard
1 sibling, 0 replies; 59+ messages in thread
From: Peter Korsgaard @ 2008-12-16 9:00 UTC (permalink / raw)
To: buildroot
>>>>> "tpetazzoni" == tpetazzoni <tpetazzoni@uclibc.org> writes:
tpetazzoni> Author: tpetazzoni
tpetazzoni> Date: 2008-12-15 14:35:09 -0800 (Mon, 15 Dec 2008)
tpetazzoni> New Revision: 24428
tpetazzoni> Log:
tpetazzoni> Documentation fixes and updates
tpetazzoni> The biggest update is to document the
tpetazzoni> Makefile.autotools.in way of writing .mk files.
Cool, thanks!
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2008-12-16 9:00 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2008-12-16 9:00 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2008-12-16 01:00:11 -0800 (Tue, 16 Dec 2008)
New Revision: 24430
Log:
docs/buildroot.html: misc small fixes and strip trailing spaces
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2008-12-16 07:48:29 UTC (rev 24429)
+++ trunk/buildroot/docs/buildroot.html 2008-12-16 09:00:11 UTC (rev 24430)
@@ -70,7 +70,7 @@
uses the GNU libc as C standard library. This compilation
toolchain is called the "host compilation toolchain", and more
generally, the machine on which it is running, and on which you're
- working is called the "host system". The compilation toolchain
+ working is called the "host system". The compilation toolchain
is provided by your distribution, and Buildroot has nothing to do
with it. </p>
@@ -173,7 +173,7 @@
be named <code>root_fs_ARCH.EXT</code> where <code>ARCH</code> is your
architecture and <code>EXT</code> depends on the type of target filesystem
selected in the <code>Target options</code> section of the configuration
- tool.
+ tool.
The file is stored in the "binaries/<code>$(PROJECT)</code>/" directory</p>
<h3><a name="local_board_support" id="local_board_support"></a>
@@ -181,7 +181,7 @@
<p>Once a package has been unpacked, it is possible to manually update
configuration files. Buildroot can automatically save the configuration
- of buildroot, linux, busybox, uclibc and u-boot in "local/$(PROJECT) by
+ of buildroot, linux, busybox, uclibc and u-boot in "local/$(PROJECT) by
using the command:
</p>
@@ -189,7 +189,7 @@
$ make saveconfig
</pre>
- <p>Once a buildroot configuration has been created by saveconfig,
+ <p>Once a buildroot configuration has been created by saveconfig,
the default "$(TOPDIR)/.config" file can be overridden by</p>
<pre>
@@ -200,7 +200,7 @@
instead of ".config". </p>
<p>If you want to modify your board, you can copy the project configuration
- file to ".config" by using the command:</p>
+ file to ".config" by using the command:</p>
<pre>
$ make BOARD=<project> getconfig
@@ -208,7 +208,7 @@
<p>You can share your custom board support directory between several buildroot trees
by setting the environment variable <code>BUILDROOT_LOCAL</code> to this directory,
- </p>
+ </p>
<h3><a name="offline_builds" id="offline_builds"></a>
@@ -220,7 +220,7 @@
<pre>
$ make source
</pre>
- <p>You can now disconnect or copy the content of your <code>dl</code>
+ <p>You can now disconnect or copy the content of your <code>dl</code>
directory to the build-host. </p>
<h3><a name="building_out_of_tree" id="building_out_of_tree"></a>
@@ -298,8 +298,8 @@
target filesystem is available under <code>project_build_ARCH/root/</code>
where <code>ARCH</code> is the chosen target architecture.
You can simply make your changes here, and run make afterwards, which will
- rebuild the target filesystem image. This method allows to do everything
- on the target filesystem, but if you decide to completely rebuild your
+ rebuild the target filesystem image. This method allows to do everything
+ on the target filesystem, but if you decide to completely rebuild your
toolchain and tools, these changes will be lost. </li>
<li>Customize the target filesystem skeleton, available under
@@ -317,7 +317,7 @@
it should be changed. These main directories are in an tarball inside of
inside the skeleton because it contains symlinks that would be broken
otherwise. <br />
- These customizations are deployed into
+ These customizations are deployed into
<code>project_build_ARCH/root/</code> just before the actual image
is made. So simply rebuilding the image by running
make should propagate any new changes to the image. </li>
@@ -347,10 +347,10 @@
</ol>
<p>Otherwise, you can simply change the
- <code>package/busybox/busybox-<version>.config</code> file if you
+ <code>package/busybox/busybox-<version>.config</code> file if you
know the options you want to change without using the configuration tool.
</p>
- <p>If you want to use an existing config file for busybox, then see
+ <p>If you want to use an existing config file for busybox, then see
section <a href="#environment_variables">environment variables</a>. </p>
<h2><a name="custom_uclibc" id="custom_uclibc"></a>Customizing the uClibc
@@ -390,7 +390,7 @@
<code>toolchain/uClibc/uClibc.config-locale</code> without running
the configuration assistant. </p>
- <p>If you want to use an existing config file for uclibc, then see
+ <p>If you want to use an existing config file for uclibc, then see
section <a href="#environment_variables">environment variables</a>. </p>
<h2><a name="buildroot_innards" id="buildroot_innards"></a>How Buildroot
@@ -455,24 +455,24 @@
<li>Create the shared build directory (<code>build_ARCH/</code> by
default, where <code>ARCH</code> is your architecture). This is where all
non configurable user-space tools will be compiled.When building two or
- more targets using the same architecture, the first build will go through
- the full download, configure, make process, but the second and later
- builds will only copy the result from the first build to its project
+ more targets using the same architecture, the first build will go through
+ the full download, configure, make process, but the second and later
+ builds will only copy the result from the first build to its project
specific target directory significantly speeding up the build process</li>
- <li>Create the project specific build directory
- (<code>project_build_ARCH/$(PROJECT)</code> by default, where
- <code>ARCH</code> is your architecture). This is where all configurable
- user-space tools will be compiled. The project specific build directory
- is neccessary, if two different targets needs to use a specific package,
- but the packages have different configuration for both targets. Some
+ <li>Create the project specific build directory
+ (<code>project_build_ARCH/$(PROJECT)</code> by default, where
+ <code>ARCH</code> is your architecture). This is where all configurable
+ user-space tools will be compiled. The project specific build directory
+ is neccessary, if two different targets needs to use a specific package,
+ but the packages have different configuration for both targets. Some
examples of packages built in this directory are busybox and linux.
</li>
- <li>Create the project specific result directory
- (<code>binaries/$(PROJECT)</code> by default, where <code>ARCH</code>
+ <li>Create the project specific result directory
+ (<code>binaries/$(PROJECT)</code> by default, where <code>ARCH</code>
is your architecture). This is where the root filesystem images are
- stored, It is also used to store the linux kernel image and any
+ stored, It is also used to store the linux kernel image and any
utilities, boot-loaders etc. needed for a target.
</li>
@@ -512,9 +512,9 @@
<p>Buildroot has always supported building several projects in the same
tree if each project was for a different architecture. </p>
- <p>The root file system has been created in the
+ <p>The root file system has been created in the
<code>"build_<ARCH>/root"</code>
- directory which is unique for each architecture.
+ directory which is unique for each architecture.
Toolchains have been built in
<code>"toolchain_build_<ARCH>"</code>. </p>
@@ -522,7 +522,7 @@
architecture, a prefix or suffix could be added in the configuration file
so the root file system would be built in
<code>"<PREFIX>_build_<ARCH>_<SUFFIX>/root"</code>
- By supplying <u>unique</u> combinations of
+ By supplying <u>unique</u> combinations of
<code>"<PREFIX>"</code> and
<code>"<SUFFIX>"</code>
each project would get a <u>unique</u> root file system tree. </p>
@@ -531,14 +531,14 @@
built for each project, adding considerable time to the build
process, even if it was two projects for the same chip. </p>
- <p>This drawback has been somewhat lessened with
- <code>gcc-4.x.y</code> which allows buildroot to use an external
+ <p>This drawback has been somewhat lessened with
+ <code>gcc-4.x.y</code> which allows buildroot to use an external
toolchain. Certain packages requires special
features in the toolchain, and if an external toolchain is selected,
this may lack the neccessary features to complete the build of the root
file system.</p>
- <p>A bigger problem was that the
+ <p>A bigger problem was that the
<code>"build_<ARCH>"</code> tree
was also duplicated, so each </code>package</code> would also
be rebuilt once per project, resulting in even longer build times.</p>
@@ -546,29 +546,29 @@
<p><b>PROJECT TO SHARE TOOLCHAIN AND PACKAGE BUILDS</b></p>
- <p>Work has started on a project which will allow the user to build
- multiple root file systems for the same architecture in the same tree.
+ <p>Work has started on a project which will allow the user to build
+ multiple root file systems for the same architecture in the same tree.
The toolchain and the package build directory will be shared, but each
project will have a dedicated directory tree for project specific
builds. </p>
- <p>With this approach, most, if not all packages will be compiled
+ <p>With this approach, most, if not all packages will be compiled
when the first project is built.
The process is almost identical to the original process.
- Packages are downloaded and extracted to the shared
+ Packages are downloaded and extracted to the shared
<code>"build_<ARCH>/<package>"</code>
- directory. They are configured and compiled. </p>
+ directory. They are configured and compiled. </p>
<p>Package libraries and headers are installed in the shared $(STAGING_DIR),
and then the project specific root file system "$(TARGET_DIR)"
- is populated. </p>
+ is populated. </p>
<p>At the end of the build, the root file system will be used
to generate the resulting root file system binaries. </p>
- <p>Once the first project has been built, building other projects will
+ <p>Once the first project has been built, building other projects will
typically involve populating the new project's root file system directory
- from the existing binaries generated in the shared
+ from the existing binaries generated in the shared
<code>"build_<ARCH>/<>"</code> directory. </p>
<p>Only packages, not used by the first project, will have to go
@@ -585,8 +585,8 @@
<li><code>binaries;</code></li>
</ul>
- <p>Each of the directories contain one subdirectory per project.
- The name of the subdirectory is configured by the user in the
+ <p>Each of the directories contain one subdirectory per project.
+ The name of the subdirectory is configured by the user in the
normal buildroot configuration, using the value of: </p>
<p><code>Project Options ---> Project name</code></p>
@@ -620,13 +620,13 @@
<p>will be created. </p>
<p>Currently, the <u>root file system</u>, <u>busybox</u> and an Atmel
- customized version of
+ customized version of
<u><code>U-Boot</code></u>, as well as some Atmel specific
bootloaders like <u>at91-bootstrap</u> and <u>dataflashboot.bin</u>
- are built in
+ are built in
<code>"$(PROJECT_BUILD_DIR)"</code>
- <p>The resulting binaries for all architectures are stored in the
+ <p>The resulting binaries for all architectures are stored in the
<code>"$(BINARIES_DIR)"</code> directory. <p>
<p><b>SUMMARY</b></p>
@@ -636,13 +636,13 @@
can configure the build. </p>
<p><b>THINGS TO DO</b></p>
-
+
<ol>
<li>Linux</li>
<p>The current Linux implementation is flawed. It only works
- if the user chooses to use one of the few kernels selected
+ if the user chooses to use one of the few kernels selected
as base for the kernel-headers. While the Makefile seems to have
hooks, allowing the developer to specify whatever version he/she
wants in the target/device/*/* Makefiles, the build will fail
@@ -650,17 +650,17 @@
<p>The reason for this is that the kernel patches are not
applied by the <code>"target/linux/linux.mk"</code>
- build script fragment. They are only applied by the
+ build script fragment. They are only applied by the
<code>"toolchain/kernel-headers/*.makefile"</code>
build script fragments</p>
<p>If the kernel-header version and the linux version differs,
there will be two <code>"linux-2.6.X.Y"</code>
- directories in
+ directories in
<code>"build_<ARCH>/<>"</code>,
each with its own set of patches. </p>
- <p>The solution in the works, is to move the build of Linux to
+ <p>The solution in the works, is to move the build of Linux to
<code>"project_build_<ARCH>/<project name>/linux-2.6.X.Y"</code> combined with method to configure
which patches can be applied. Possibly, the linux source tree
used to generate the kernel headers will be moved to the
@@ -675,18 +675,18 @@
<li>Conservative Strategy: Only use version ssupported by the kernel headers</li>
<li>Stable Linux Strategy: Allow any 2.6.X.Y combination.
(Minimum 2.6.19)</li>
- <li>Power-User Strategy: Allow
+ <li>Power-User Strategy: Allow
<code>"-git"</code>, or
<code>"-mm"</code>, or user downloadable kernels</li>
</ul>
<p>The current kernel patches can be configured to be applied to the
- linux source tree even if the version differs from the
+ linux source tree even if the version differs from the
kernel header version. </p>
<p>Since the user can select any kernel-patch
he/she will be able to select a non-working combination.
- If the patch fails, the user will have to generate a new
+ If the patch fails, the user will have to generate a new
proprietary kernel-patch or decide to not apply the kernel
patches</p>
@@ -696,10 +696,10 @@
<p>There will also be a way for the user to supply absolute
or relative paths to patches, possibly outside the main tree.
This can be used to apply custom kernel-header-patches, if
- the versions available in buildroot cannot be applied to the
+ the versions available in buildroot cannot be applied to the
specific linux version used</p>
- <p>Maybe, there will also be a possibility to supply an
+ <p>Maybe, there will also be a possibility to supply an
<code>"URL"</code> to a patch available on Internet. </p>
<li>Configurable packages</li>
@@ -707,12 +707,12 @@
<p>Many packages can, on top of the simple
"enable/disable build",
be further configured using Kconfig.
- Currently these packages will be compiled using the
+ Currently these packages will be compiled using the
configuration specified in the
<code>".config"</code> file of the <u>first</u>
project demanding the build of the package.</p>
- <p>If <u>another</u> project uses the same packages, but with
+ <p>If <u>another</u> project uses the same packages, but with
a different configuration,these packages will <u>not</u> be rebuilt,
and the root file system for the new project will be populated
with files from the build of the <u>first</u> project</p>
@@ -723,8 +723,8 @@
<code>"build_<ARCH>"</code> directory
before rebuilding the new project.<p>
- <p>A long term solution is to edit the package makefile and move
- the build of the configurable packages from
+ <p>A long term solution is to edit the package makefile and move
+ the build of the configurable packages from
<code>"build_<ARCH>"</code> to
<code>"project_build_<ARCH>/<project name>"</code>
and send a patch to the buildroot mailing list.
@@ -737,16 +737,16 @@
<li>Generating File System binaries</li>
<p>
Packages which needs to be installed with the "root"
- as owner, will generate a
+ as owner, will generate a
<code>".fakeroot.<package>"</code> file
which will be used for the final build of the root file system binary. </p>
- <p>This was previously located in the
+ <p>This was previously located in the
<code>"$(STAGING_DIR)"</code> directory, but was
- recently moved to the
+ recently moved to the
<code>"$(PROJECT_BUILD_DIR)"</code> directory. </p>
- <p>Currently only three packages:
+ <p>Currently only three packages:
<code>"at"</code>,
<code>"ltp-testsuite"</code> and
<code>"nfs-utils"</code>
@@ -764,7 +764,7 @@
<code>".fakeroot.<package>"</code>
files are deleted as the last action of the Buildroot Makefile. </p>
- <p>It needs to be evaluated if any further action for the
+ <p>It needs to be evaluated if any further action for the
file system binary build is needed. </p>
</ol>
@@ -816,7 +816,7 @@
install it somewhere else, so that it can be used to compile other programs
or by other users. Moving the <code>build_ARCH/staging_dir/</code>
directory elsewhere is <b>not possible if using gcc-3.x</b>, because there
- are some hardcoded paths in the toolchain configuration. This works, thanks
+ are some hardcoded paths in the toolchain configuration. This works, thanks
to sysroot support, with current, stable gcc-4.x toolchains, of course. </p>
<p>If you want to use the generated gcc-3.x toolchain for other purposes,
@@ -850,7 +850,7 @@
<p>Another way of accessing a shared download location is to
create the <code>BUILDROOT_DL_DIR</code> environment variable.
If this is set, then the value of DL_DIR in the project is
- overridden. The following line should be added to
+ overridden. The following line should be added to
<code>"~/.bashrc"</code>. <p>
<pre>
@@ -911,10 +911,10 @@
<p>Two types of <i>Makefiles</i> can be written :</p>
<ul>
- <li>Makefile for autotools-based (autoconf, automake, etc.)
+ <li>Makefiles for autotools-based (autoconf, automake, etc.)
softwares, are very easy to write thanks to the infrastructure
available in <code>package/Makefile.autotools.in</code>.</li>
- <li>Makefile for other types of packages are a little bit more
+ <li>Makefiles for other types of packages are a little bit more
complex to write.</li>
</ul>
@@ -1048,7 +1048,7 @@
the other <code>*.mk</code> files in the <code>package</code>
directory. </p>
- <p>At lines <a href="#ex2line6">6-11</a>, a couple of useful variables are
+ <p>At lines <a href="#ex2line6">6-11</a>, a couple of useful variables are
defined :</p>
<ul>
@@ -1078,21 +1078,21 @@
</ul>
- <p>Lines <a href="#ex2line13">13-14</a> defines a target that downloads the
+ <p>Lines <a href="#ex2line13">13-14</a> defines a target that downloads the
tarball from the remote site to the download directory
(<code>DL_DIR</code>). </p>
- <p>Lines <a href="#ex2line16">16-18</a> defines a target and associated rules
+ <p>Lines <a href="#ex2line16">16-18</a> defines a target and associated rules
that uncompress the downloaded tarball. As you can see, this target
depends on the tarball file, so that the previous target (line
- <a href="#ex2line13">13-14</a>) is called before executing the rules of the
+ <a href="#ex2line13">13-14</a>) is called before executing the rules of the
current target. Uncompressing is followed by <i>touching</i> a hidden file
to mark the software has having been uncompressed. This trick is
used everywhere in Buildroot <i>Makefile</i> to split steps
(download, uncompress, configure, compile, install) while still
having correct dependencies. </p>
- <p>Lines <a href="#ex2line20">20-31</a> defines a target and associated rules
+ <p>Lines <a href="#ex2line20">20-31</a> defines a target and associated rules
that configures the software. It depends on the previous target (the
hidden <code>.source</code> file) so that we are sure the software has
been uncompressed. In order to configure it, it basically runs the
@@ -1104,14 +1104,14 @@
filesystem. Finally it creates a <code>.configured</code> file to
mark the software as configured. </p>
- <p>Lines <a href="#ex2line33">33-34</a> defines a target and a rule that
+ <p>Lines <a href="#ex2line33">33-34</a> defines a target and a rule that
compiles the software. This target will create the binary file in the
compilation directory, and depends on the software being already
configured (hence the reference to the <code>.configured</code>
file). It basically runs <code>make</code> inside the source
directory. </p>
- <p>Lines <a href="#ex2line36">36-38</a> defines a target and associated rules
+ <p>Lines <a href="#ex2line36">36-38</a> defines a target and associated rules
that install the software inside the target filesystem. It depends on the
binary file in the source directory, to make sure the software has
been compiled. It uses the <code>install</code> target of the
@@ -1122,7 +1122,7 @@
<code>/usr/man</code> directory inside the target filesystem is
removed to save space. </p>
- <p>Line <a href="#ex2line40">40</a> defines the main target of the software,
+ <p>Line <a href="#ex2line40">40</a> defines the main target of the software,
the one that will be eventually be used by the top level
<code>Makefile</code> to download, compile, and then install
this package. This target should first of all depends on all
@@ -1131,33 +1131,33 @@
final binary. This last dependency will call all previous
dependencies in the correct order. </p>
- <p>Line <a href="#ex2line42">42</a> defines a simple target that only
- downloads the code source. This is not used during normal operation of
- Buildroot, but is needed if you intend to download all required sources at
+ <p>Line <a href="#ex2line42">42</a> defines a simple target that only
+ downloads the code source. This is not used during normal operation of
+ Buildroot, but is needed if you intend to download all required sources at
once for later offline build. Note that if you add a new package providing
a <code>foo-source</code> target is <i>mandatory</i> to support
users that wish to do offline-builds. Furthermore it eases checking
if all package-sources are downloadable. </p>
- <p>Lines <a href="#ex2line44">44-46</a> define a simple target to clean the
+ <p>Lines <a href="#ex2line44">44-46</a> define a simple target to clean the
software build by calling the <i>Makefiles</i> with the appropriate option.
The <code>-clean</code> target should run <code>make clean</code>
on $(BUILD_DIR)/package-version and MUST uninstall all files of the
package from $(STAGING_DIR) and from $(TARGET_DIR). </p>
- <p>Lines <a href="#ex2line48">48-49</a> define a simple target to completely
+ <p>Lines <a href="#ex2line48">48-49</a> define a simple target to completely
remove the directory in which the software was uncompressed, configured and
compiled. The <code>-dirclean</code> target MUST completely rm $(BUILD_DIR)/
package-version. </p>
- <p>Lines <a href="#ex2line51">51-58</a> adds the target <code>foo</code> to
+ <p>Lines <a href="#ex2line51">51-58</a> adds the target <code>foo</code> to
the list of targets to be compiled by Buildroot by first checking if
the configuration option for this package has been enabled
using the configuration tool, and if so then "subscribes"
this package to be compiled by adding it to the TARGETS
global variable. The name added to the TARGETS global
variable is the name of this package's target, as defined on
- line <a href="#ex2line40">40</a>, which is used by Buildroot to download,
+ line <a href="#ex2line40">40</a>, which is used by Buildroot to download,
compile, and then install this package. </p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
2008-12-15 22:44 ` Thomas Petazzoni
@ 2008-12-16 9:03 ` Peter Korsgaard
0 siblings, 0 replies; 59+ messages in thread
From: Peter Korsgaard @ 2008-12-16 9:03 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> Le Mon, 15 Dec 2008 14:35:09 -0800 (PST),
Thomas> tpetazzoni at uclibc.org a ?crit :
>> Documentation fixes and updates
Thomas> BTW, the documentation contains a big ?Building several
Thomas> projects in the same buildroot source tree? section, which
Thomas> IMHO, has nothing to do in an user manual. It describes
Thomas> unimplemented things, historical reasons, has a TODO-list,
Thomas> and so on.
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2008-12-18 0:48 root at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: root at uclibc.org @ 2008-12-18 0:48 UTC (permalink / raw)
To: buildroot
Author: root
Date: 2008-12-18 00:48:49 +0000 (Thu, 18 Dec 2008)
New Revision: 24447
Log:
Update links to new site locations (via Lance Albertson of OSL)
Modified:
trunk/buildroot/docs/download.html
trunk/buildroot/docs/header.html
trunk/buildroot/docs/lists.html
Changeset:
Modified: trunk/buildroot/docs/download.html
===================================================================
--- trunk/buildroot/docs/download.html 2008-12-18 00:48:17 UTC (rev 24446)
+++ trunk/buildroot/docs/download.html 2008-12-18 00:48:49 UTC (rev 24447)
@@ -15,7 +15,7 @@
<li> Click here to <a href="downloads/snapshots/">Daily Snapshots</a>.
</li>
- <li> Click here to <a href="/cgi-bin/viewcvs.cgi/trunk/buildroot/">browse the source tree</a>.
+ <li> Click here to <a href="http://sources.busybox.net/index.py/trunk/buildroot/">browse the source tree</a>.
</li>
<li>Anonymous <a href="subversion.html">Subversion access</a> is available.
Modified: trunk/buildroot/docs/header.html
===================================================================
--- trunk/buildroot/docs/header.html 2008-12-18 00:48:17 UTC (rev 24446)
+++ trunk/buildroot/docs/header.html 2008-12-18 00:48:49 UTC (rev 24447)
@@ -46,7 +46,7 @@
<br><a href="/about.html">About</a>
<br><a href="/news.html">Latest News</a>
<br><a href="/download.html">Download</a>
- <br><a href="/cgi-bin/viewcvs.cgi/trunk/buildroot/">Browse Source</a>
+ <br><a href="http://sources.busybox.net/index.py/trunk/buildroot/">Browse Source</a>
<br><a href="/subversion.html">Accessing Source</a>
<br><a href="http://bugs.uclibc.org/">Bug Tracking</a>
<br><a href="/docs.html">Documentation</a>
Modified: trunk/buildroot/docs/lists.html
===================================================================
--- trunk/buildroot/docs/lists.html 2008-12-18 00:48:17 UTC (rev 24446)
+++ trunk/buildroot/docs/lists.html 2008-12-18 00:48:49 UTC (rev 24447)
@@ -5,7 +5,7 @@
<h3>Mailing List Information</h3>
Buildroot has a <a href="/lists/buildroot/">mailing list</a> for discussion and
development. You can subscribe by visiting
-<a href="/mailman/listinfo/buildroot">this page</a>.
+<a href="http://lists.busybox.net/mailman/listinfo/buildroot">this page</a>.
Only subscribers to the Buildroot mailing list are allowed to post
to this list.
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-06 16:30 ulf at uclibc.org
2009-01-06 16:34 ` Peter Korsgaard
0 siblings, 1 reply; 59+ messages in thread
From: ulf at uclibc.org @ 2009-01-06 16:30 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2009-01-06 16:30:32 +0000 (Tue, 06 Jan 2009)
New Revision: 24707
Log:
Add documentation for u-boot patches to 2009.01-rc1
Added:
trunk/buildroot/docs/U-boot.html
Changeset:
Added: trunk/buildroot/docs/U-boot.html
===================================================================
--- trunk/buildroot/docs/U-boot.html (rev 0)
+++ trunk/buildroot/docs/U-boot.html 2009-01-06 16:30:32 UTC (rev 24707)
@@ -0,0 +1,255 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+ <title>Buildroot - U-boot extensions in 2009.01-rc1</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+ <link rel="stylesheet" type="text/css" href="stylesheet.css" />
+</head>
+
+<body>
+ <div class="main">
+ <div class="titre">
+ <a name="top" id="top"></a>
+ <h1>U-boot extensions in 2009.01-rc1</h1>
+ </div>
+
+ <p><a href="http://buildroot.uclibc.org/">U-Boot</a>
+ usage and documentation by Ulf Samuelsson.
+ </p>
+
+ <p><small>$LastChangedDate: 2008-12-16 10:00:11 +0100 (tis, 16 dec 2008) $</small></p>
+ <ul>
+ <li><a href="#about">About U-Boot</a></li>
+ <li><a href="#at91rm9200dk">Board Support for AT91RM9200DK</a></li>
+ <li><a href="#at91rm9200ek">Board Support for AT91RM9200EK</a></li>
+ <li><a href="#at91sam9g20ek">Board Support for AT91SAM9G20EK</a></li>
+ <li><a href="#Minicom extensions">X-Modem/Raw extensions to minicom</a></li>
+ <li><a href="#cmd_factory">New Command: factory</a></li>
+ <li><a href="#cmd_os">New Command: os</a></li>
+ <li><a href="#cmd_fs">New Command: fs</a></li>
+ <li><a href="#cmd_setargs">New Command: setargs</a></li>
+ <li><a href="#cmd_led">New Command: led</a></li>
+ <li><a href="#cmd_mux">New Command: mux</a></li>
+ <li><a href="#cmd_ethinit">New Command: ethinit</a></li>
+ <li><a href="#environment">Special environment variables</a></li>
+ </ul>
+ <h2><a name="about" id="about"></a>About U-boot</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ U-Boot is an open source bootloader ported to a multitude of processors.
+ See (<a href="http://www.denx.de/wiki/U-Boot/WebHome">U-Boot Home</a>)
+ for documentation for vanilla U-Boot. This document only describes
+ changes compared to the vanilla u-boot.
+ </p>
+
+ <h2><a name="at91rm9200dk" id="at91rm9200dk"></a>Board support for at91rm9200dk</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ "at91rm9200dk" is updated to use a linux like API for gpio.
+ A new target "at91rm9200dk_df" is defined to support boot from dataflash.
+ </p>
+
+ <h2><a name="at91rm9200ek" id="at91rm9200ek"></a>Board support for at91rm9200ek</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ The "at91rm9200ek" BSP supports booting from a parallel flash.
+ The "at91rm9200df" BSP supports a generic target booting from dataflash.
+ </p>
+
+ <h2><a name="#at91sam9g20ek" id="#at91sam9g20ek"></a>Board support for at91sam9g20ek</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ The "at91sam9g20ek" target with dataflash(card) and NAND boot support.
+ </p>
+
+ <h2><a name="minicom_extensions" id="minicom_extensions"></a>Minicom extensions </h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ "sx-at91" is a reliable X-Modem application allowing download to the at91rm9200
+ based board
+ </p>
+ <p>
+ "raw-at91" is a download application which will download binary data using minicom.
+ Typically used to download an environment script.
+ </p>
+
+ <h2><a name="cmd_factory" id="cmd_factory"></a>New command: factory</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ <h3><code>factory</code></h3>
+ </p>
+
+ <p>
+ "factory" will set a selected set of environment variables
+ back to the compile time default. The following will give some
+ hints on capabilities, but is not yet complete.
+ </p>
+
+ <p>
+ It will generate a set of scripts which will facilitate downloading
+ the kernel and root file system using tftp and will also
+ add commands to store into and retrieve from flash
+ </p>
+
+ <h2><a name="cmd_os" id="cmd_os"></a>New command: os</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ <h3><code>os<code></h3>
+ </p>
+ <p>
+ "os" computes a new name for the linux kernel
+ </p>
+
+ <h2><a name="cmd_fs" id="cmd_fs"></a>New command: fs</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ <h3><code>fs<code></h3>
+ </p>
+ <p>
+ "fs" computes a new name for the file system
+ </p>
+
+ <h2><a name="cmd_setargs" id="cmd_setargs"></a>New command: setargs</h2>
+ <a href="#top"><small>[TOP]</small></a>
+ <p>
+ <h3><code>setargs<code></h3>
+ </p>
+ <p>
+ "setargs" will create new bootcmd/bootargs combination from
+ kernel name, filesystem name, and rootfs type.
+ </p>
+
+ <h2><a name="cmd_led" id="cmd_led"></a>New command: led</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ <h3><code>led [green | yellow | red | all ] [ on | off ]<code></h3>
+ </p>
+
+ <p>
+ "led" will turn on or off the specified (coloured) led
+ </p>
+
+ <h2><a name="cmd_mux" id="cmd_mux"></a>New command: mux</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ <h3><code>mux [spi | mmc ]<code></h3>
+ </p>
+
+ <p>
+ "mux" will select how to use the flash card connector on the
+ at91rm9200dk or at91rm9200ek
+ </p>
+
+ <h2><a name="cmd_ethinit" id="cmd_ethinit"></a>New command: ethinit</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ <h3><code>ethinit<code></h3>
+ </p>
+
+ <p>
+ "ethinit" can be used to delay the boot of linux, until a valid network
+ connection has been established. This is useful if the machine is NFS mounting
+ the root file system and both this machine and the NFS server are powering up
+ simultaneously. The NFS server could take a lot longer to boot, and waiting
+ for this to boot may be neccessary for proper operation.
+ </p>
+
+ <h2><a name="environment" id="environment"></a>Special environment variables</h2>
+ <a href="#top"><small>[TOP]</small></a>
+
+ <p>
+ <h3><code>rd<code></h3>
+ </p>
+ <p>
+ rd contains the name of the current root file system
+ It is autmatically generated from <bold>ver</bold> and <bold>rd-1</bold>, <bold>rd-2</bold> etc.
+ The "fs-date" is added at the end.
+ </p>
+
+ <p>
+ <h3><code>ver<code></h3>
+ </p>
+ <p>
+ You can handle a number of different root fs by defining <code>ver</code>.
+ When running <code>fs</code> rd will be assigned from one of:
+ <ul><code>rd-1, rd2, rd-3 ...<code></ul>
+ </p>
+ <p>
+ By defining <code>ver</code> to a number you will
+ select the appropriate disk name
+ </p>
+
+ <p>
+ <h3><code>fs-date<code></h3>
+ </p>
+ <p>
+ "date" part of the root file system name
+ </p>
+
+ <p>
+ <h3><code>linux<code></h3>
+ </p>
+ <p>
+ linux contains the name of the current kernel.
+ </p>
+ <p>
+ It is generated from several environment variables when <code>os</code> is run
+ </p>
+ <p>
+ A typical name would be "at91sam9263ek-linux-2.6.28-20090105.gz"
+ </p>
+
+ <p>
+ <h3><code>hostname<code></h3>
+ </p>
+ <p>
+ "name" part of the kernel file name
+ </p>
+
+ <p>
+ <h3><code>kernel-version<code></h3>
+ </p>
+ <p>
+ "version" part of the kernel file name
+ </p>
+
+ <p>
+ <h3><code>kernel-date<code></h3>
+ </p>
+ <p>
+ "date" part of the kernel file name
+ </p>
+
+ <p>
+ <h3><code>fstype [ ram | flash ]<code></h3>
+ <p>
+ You can have several file system types.
+ bootargs is created depending on fstype..
+ </p>
+
+ <a href="#top"><small>[TOP]</small></a>
+
+ </div>
+<!--
+ <a href="http://validator.w3.org/check?uri=referer"><img
+ border="0" height="31" width="88"
+ src="images/valid-html401.png"
+ alt="Valid HTML"></img></a>
+-->
+
+</body>
+</html>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
2009-01-06 16:30 ulf at uclibc.org
@ 2009-01-06 16:34 ` Peter Korsgaard
0 siblings, 0 replies; 59+ messages in thread
From: Peter Korsgaard @ 2009-01-06 16:34 UTC (permalink / raw)
To: buildroot
>>>>> "ulf" == ulf <ulf@uclibc.org> writes:
ulf> Author: ulf
ulf> Date: 2009-01-06 16:30:32 +0000 (Tue, 06 Jan 2009)
ulf> New Revision: 24707
ulf> Log:
ulf> Add documentation for u-boot patches to 2009.01-rc1
Please keep these things in the Atmel fork.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-15 14:50 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-01-15 14:50 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-01-15 14:50:07 +0000 (Thu, 15 Jan 2009)
New Revision: 24857
Log:
docs/README: ask people to mail the list instead of Erik
Modified:
trunk/buildroot/docs/README
Changeset:
Modified: trunk/buildroot/docs/README
===================================================================
--- trunk/buildroot/docs/README 2009-01-15 14:50:03 UTC (rev 24856)
+++ trunk/buildroot/docs/README 2009-01-15 14:50:07 UTC (rev 24857)
@@ -57,6 +57,5 @@
$ make HOSTCC=gcc-4.3 uclibc-menuconfig
$ make HOSTCC=gcc-4.3 busybox-menuconfig
-Please feed suggestions, bug reports, insults, and bribes back to:
- Erik Andersen <andersen@codepoet.org>
-or the buildroot mailing list.
+Please feed suggestions, bug reports, insults, and bribes back to the
+buildroot mailing list: buildroot at uclibc.org
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-15 14:50 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-01-15 14:50 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-01-15 14:50:11 +0000 (Thu, 15 Jan 2009)
New Revision: 24858
Log:
docs/footer.html: ask people to mail the list instead of Erik
And update the year while we're at it.
Modified:
trunk/buildroot/docs/footer.html
Changeset:
Modified: trunk/buildroot/docs/footer.html
===================================================================
--- trunk/buildroot/docs/footer.html 2009-01-15 14:50:07 UTC (rev 24857)
+++ trunk/buildroot/docs/footer.html 2009-01-15 14:50:11 UTC (rev 24858)
@@ -9,11 +9,11 @@
<p>
<font face="arial, helvetica, sans-serif" size="-1">
- <a HREF="/copyright.txt">Copyright © 1999-2005 Erik Andersen</a>
+ <a HREF="/copyright.txt">Copyright © 1999-2009 Erik Andersen</a>
<br>
Mail all comments, insults, suggestions and bribes to
<br>
- Erik Andersen <A HREF="mailto:andersen@codepoet.org">andersen at codepoet.org</A><BR>
+ The Buildroot developers <A HREF="mailto:buildroot@uclibc.org">buildroot at uclibc.org</A><BR>
</font>
</body>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-15 14:50 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-01-15 14:50 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-01-15 14:50:14 +0000 (Thu, 15 Jan 2009)
New Revision: 24859
Log:
docs/about.html: new maintainer
Modified:
trunk/buildroot/docs/about.html
Changeset:
Modified: trunk/buildroot/docs/about.html
===================================================================
--- trunk/buildroot/docs/about.html 2009-01-15 14:50:11 UTC (rev 24858)
+++ trunk/buildroot/docs/about.html 2009-01-15 14:50:14 UTC (rev 24859)
@@ -18,7 +18,7 @@
<p>
buildroot is maintained by <a href=
-"http://codepoet.org/andersen/erik/erik.html">Erik Andersen</a>, and
+"mailto:jacmet at uclibc.org">Peter Korsgaard</a>, and
licensed under the
<a href="http://www.gnu.org/copyleft/lgpl.html">GNU LIBRARY GENERAL PUBLIC LICENSE</a>.
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-15 14:50 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-01-15 14:50 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-01-15 14:50:17 +0000 (Thu, 15 Jan 2009)
New Revision: 24860
Log:
docs/copyright.txt: update year, add buildroot developers
Modified:
trunk/buildroot/docs/copyright.txt
Changeset:
Modified: trunk/buildroot/docs/copyright.txt
===================================================================
--- trunk/buildroot/docs/copyright.txt 2009-01-15 14:50:14 UTC (rev 24859)
+++ trunk/buildroot/docs/copyright.txt 2009-01-15 14:50:17 UTC (rev 24860)
@@ -1,6 +1,7 @@
The code and graphics on this website (and it's mirror sites, if any) are
-Copyright (c) 1999-2005 by Erik Andersen. All rights reserved.
+Copyright (c) 1999-2005 by Erik Andersen, 2006-2009 The Buildroot
+developers. All rights reserved.
Documents on this Web site including their graphical elements, design, and
layout are protected by trade dress and other laws and MAY BE COPIED OR
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-15 14:50 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-01-15 14:50 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-01-15 14:50:20 +0000 (Thu, 15 Jan 2009)
New Revision: 24861
Log:
docs/developer.html: People should ask on the list for commit access
Modified:
trunk/buildroot/docs/developer.html
Changeset:
Modified: trunk/buildroot/docs/developer.html
===================================================================
--- trunk/buildroot/docs/developer.html 2009-01-15 14:50:17 UTC (rev 24860)
+++ trunk/buildroot/docs/developer.html 2009-01-15 14:50:20 UTC (rev 24861)
@@ -5,8 +5,8 @@
If you want to be able to commit things to Subversion, first contribute some
stuff to show you are serious. Then, very nicely ask <a
-href="mailto:andersen@codepoet.org">Erik Andersen</a> if he will set you up
-with an commit access to the Subversion repository. To access Subversion, you
+href="mailto:buildroot at uclibc.org">The Buildroot Developers</a> to set you up
+with commit access to the Subversion repository. To access Subversion, you
will want to add the following to set up your environment:
<p>
@@ -32,12 +32,6 @@
<p>
-Note that if you would prefer to keep your communications with me
-private, you can encrypt your email using my
-<a href="http://www.codepoet.org/andersen/erik/gpg.asc">public key</a>.
-
-<p>
-
Once you are setup with an account, you will need to use your account to
checkout a copy of buildroot from Subversion:
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-16 19:45 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-01-16 19:45 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-01-16 19:45:16 +0000 (Fri, 16 Jan 2009)
New Revision: 24886
Log:
docs/news.html: announce 2009.02-rc1
Modified:
trunk/buildroot/docs/news.html
Changeset:
Modified: trunk/buildroot/docs/news.html
===================================================================
--- trunk/buildroot/docs/news.html 2009-01-16 19:30:21 UTC (rev 24885)
+++ trunk/buildroot/docs/news.html 2009-01-16 19:45:16 UTC (rev 24886)
@@ -3,6 +3,18 @@
<ul>
+ <li><b>16 January 2009 -- Release candidate and new maintainer</b>
+ <p>It has been a long time coming, but we finally have a new
+ release candidate! - And a new maintainer to match (Peter Korsgaard).</p>
+
+ <p>Head to the <a href="/downloads/">downloads page</a> to pick up the
+ <a href="/downloads/buildroot-2009.02-rc1.tar.bz2">2009.02-rc1
+ release candidate</a>, and report any problems found to the <a
+ href="lists.html">mailing list</a> or <a
+ href="http://bugs.uclibc.org">bug tracker</a>. The plan is to
+ release 2009.02 in time for <a
+ href="http://www.fosdem.org/2009/">FOSDEM</a>.</p>
+
<li><b>16 July 2006 -- Buildroot mailing list</b>
<p>Buildroot now has its own <a href=lists.html>mailing list</a>.</p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-16 19:45 jacmet at uclibc.org
2009-01-16 21:02 ` Markus Heidelberg
0 siblings, 1 reply; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-01-16 19:45 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-01-16 19:45:21 +0000 (Fri, 16 Jan 2009)
New Revision: 24887
Log:
docs/download.html: cleanup and mention releases
Modified:
trunk/buildroot/docs/download.html
Changeset:
Modified: trunk/buildroot/docs/download.html
===================================================================
--- trunk/buildroot/docs/download.html 2009-01-16 19:45:16 UTC (rev 24886)
+++ trunk/buildroot/docs/download.html 2009-01-16 19:45:21 UTC (rev 24887)
@@ -6,11 +6,15 @@
<p>
-The best way to obtain and update your own copy of buildroot is to fetch the
-latest version using <a href="subversion.html">Subversion</a>. You can also
-obtain <a href= "downloads/snapshots/">Daily Snapshots</a> of the latest
-buildroot source tree but cannot or do not wish to use Subversion (svn).
+The latest release can always be dowloaded from
+<a href="/downloads/">http://buildroot.uclibc.org/downloads/</a>.
+<p>
+
+You can also obtain <a href="/downloads/snapshots/">Daily
+Snapshots</a> of the latest Buildroot source tree if you want to to
+follow development, but cannot or do not wish to use Subversion (svn).
+
<ul>
<li> Click here to <a href="downloads/snapshots/">Daily Snapshots</a>.
</li>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
2009-01-16 19:45 jacmet at uclibc.org
@ 2009-01-16 21:02 ` Markus Heidelberg
0 siblings, 0 replies; 59+ messages in thread
From: Markus Heidelberg @ 2009-01-16 21:02 UTC (permalink / raw)
To: buildroot
jacmet at uclibc.org, 16.01.2009:
> +The latest release can always be dowloaded from
> +<a href="/downloads/">http://buildroot.uclibc.org/downloads/</a>.
Why not create a releases/ subdirectory as it's done with the snapshots?
Because of the simpler URL? Couldn't this get a bit crowded? Especially
since the directories are currently shown at the bottom and aren't
visible immediately, if there are some more release packages.
Markus
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-23 21:06 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-01-23 21:06 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-01-23 21:06:05 +0000 (Fri, 23 Jan 2009)
New Revision: 24991
Log:
docs/news.html: announce -rc2
Modified:
trunk/buildroot/docs/news.html
Changeset:
Modified: trunk/buildroot/docs/news.html
===================================================================
--- trunk/buildroot/docs/news.html 2009-01-23 20:56:07 UTC (rev 24990)
+++ trunk/buildroot/docs/news.html 2009-01-23 21:06:05 UTC (rev 24991)
@@ -3,6 +3,16 @@
<ul>
+ <li><b>23 January 2009 -- 2009.02-rc2 released</b>
+ <p>Another week, another release candidate with a bunch of
+ cleanups and build fixes.</p>
+
+ <p>Head to the <a href="/downloads/">downloads page</a> to pick up the
+ <a href="/downloads/buildroot-2009.02-rc2.tar.bz2">2009.02-rc2
+ release candidate</a>, and report any problems found to the <a
+ href="lists.html">mailing list</a> or <a
+ href="http://bugs.uclibc.org">bug tracker</a>.</p>
+
<li><b>16 January 2009 -- Release candidate and new maintainer</b>
<p>It has been a long time coming, but we finally have a new
release candidate! - And a new maintainer to match (Peter Korsgaard).</p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-26 20:26 ulf at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: ulf at uclibc.org @ 2009-01-26 20:26 UTC (permalink / raw)
To: buildroot
Author: ulf
Date: 2009-01-26 20:26:16 +0000 (Mon, 26 Jan 2009)
New Revision: 25066
Log:
Update documentation with BUILDROOT_USE_XWINDOWS, & linux cleanup
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2009-01-26 20:17:06 UTC (rev 25065)
+++ trunk/buildroot/docs/buildroot.html 2009-01-26 20:26:16 UTC (rev 25066)
@@ -247,6 +247,9 @@
<li>HOSTCC</li>
<li>UCLIBC_CONFIG_FILE=<path/to/.config></li>
<li>BUSYBOX_CONFIG_FILE=<path/to/.config></li>
+ <li>BUILDROOT_DL_DIR</li>
+ <li>BUILDROOT_LOCAL</li>
+ <li>BUILDROOT_USE_XWINDOWS</li>
</ul>
<p>An example that uses config files located in the toplevel directory and
@@ -635,52 +638,22 @@
conflicts, but will use unique build directories, where the user
can configure the build. </p>
- <p><b>THINGS TO DO</b></p>
-
+ <h2><a name="Linux" id="Linux"></a>Linux</h2>
<ol>
- <li>Linux</li>
- <p>The current Linux implementation is flawed. It only works
- if the user chooses to use one of the few kernels selected
- as base for the kernel-headers. While the Makefile seems to have
- hooks, allowing the developer to specify whatever version he/she
- wants in the target/device/*/* Makefiles, the build will fail
- if another kernel version is choosen.</p>
+ <p>The user can select from three different Linux strategies:
- <p>The reason for this is that the kernel patches are not
- applied by the <code>"target/linux/linux.mk"</code>
- build script fragment. They are only applied by the
- <code>"toolchain/kernel-headers/*.makefile"</code>
- build script fragments</p>
-
- <p>If the kernel-header version and the linux version differs,
- there will be two <code>"linux-2.6.X.Y"</code>
- directories in
- <code>"build_<ARCH>/<>"</code>,
- each with its own set of patches. </p>
-
- <p>The solution in the works, is to move the build of Linux to
- <code>"project_build_<ARCH>/<project name>/linux-2.6.X.Y"</code> combined with method to configure
- which patches can be applied. Possibly, the linux source tree
- used to generate the kernel headers will be moved to the
- <code>"toolchain_build_<ARCH>"</code>
- directory
- </p>
-
- <p>The user will be able to select from three different
- Linux strategies:
-
<ul>
- <li>Conservative Strategy: Only use version ssupported by the kernel headers</li>
- <li>Stable Linux Strategy: Allow any 2.6.X.Y combination.
+ <li>Legacy: Only use version supported by the kernel headers</li>
+ <li>Advanced: Allow any 2.6.X.Y combination.
(Minimum 2.6.19)</li>
<li>Power-User Strategy: Allow
<code>"-git"</code>, or
<code>"-mm"</code>, or user downloadable kernels</li>
</ul>
- <p>The current kernel patches can be configured to be applied to the
+ <p>The current kernel patches can be applied to the
linux source tree even if the version differs from the
kernel header version. </p>
@@ -690,7 +663,7 @@
proprietary kernel-patch or decide to not apply the kernel
patches</p>
- <p>Other optional patches will be <u>board specific</u> or
+ <p>There is also support for <u>board specific</u> and
<u>architecture specific</u> patches. </p>
<p>There will also be a way for the user to supply absolute
@@ -701,9 +674,27 @@
<p>Maybe, there will also be a possibility to supply an
<code>"URL"</code> to a patch available on Internet. </p>
+<pre>
+export BUILDROOT_USE_XWINDOWS <>
+</pre>
- <li>Configurable packages</li>
+ <p>
+ If there is no linux config file available,
+ buildroot starts the linux configuration system, which
+ defaults to "make menuconfig". There is a menuoption
+ allowing you to use the less archaic "make xconfig"
+ You can override any .config setting by defining
+ the BUILDROOT_USE_XWINDOWS environment variable.
+ </p>
+
+
+ </ol>
+
+ <h2><a name="Todo" id="Todo"></a>Todo</h2>
+ <ol>
+
+ <li>Configurable packages</li>
<p>Many packages can, on top of the simple
"enable/disable build",
be further configured using Kconfig.
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-01-31 23:02 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-01-31 23:02 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-01-31 23:02:41 +0000 (Sat, 31 Jan 2009)
New Revision: 25202
Log:
docs/news.html: announce -rc3
Modified:
trunk/buildroot/docs/news.html
Changeset:
Modified: trunk/buildroot/docs/news.html
===================================================================
--- trunk/buildroot/docs/news.html 2009-01-31 22:53:35 UTC (rev 25201)
+++ trunk/buildroot/docs/news.html 2009-01-31 23:02:41 UTC (rev 25202)
@@ -3,6 +3,17 @@
<ul>
+ <li><b>31 January 2009 -- 2009.02-rc3 released</b>
+ <p>RC3 is out with more cleanups and bug fixes. Unless big issues
+ are found, expect this to be the last release candidate before the
+ release - So give it a good test.</p>
+
+ <p>Head to the <a href="/downloads/">downloads page</a> to pick up the
+ <a href="/downloads/buildroot-2009.02-rc3.tar.bz2">2009.02-rc3
+ release candidate</a>, and report any problems found to the <a
+ href="lists.html">mailing list</a> or <a
+ href="http://bugs.uclibc.org">bug tracker</a>.</p>
+
<li><b>23 January 2009 -- 2009.02-rc2 released</b>
<p>Another week, another release candidate with a bunch of
cleanups and build fixes.</p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-02-09 16:44 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-02-09 16:44 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-02-09 16:44:09 +0000 (Mon, 09 Feb 2009)
New Revision: 25278
Log:
docs/news.html: announce -rc4
Modified:
trunk/buildroot/docs/news.html
Changeset:
Modified: trunk/buildroot/docs/news.html
===================================================================
--- trunk/buildroot/docs/news.html 2009-02-09 15:52:49 UTC (rev 25277)
+++ trunk/buildroot/docs/news.html 2009-02-09 16:44:09 UTC (rev 25278)
@@ -3,6 +3,19 @@
<ul>
+ <li><b>9 February 2009 -- 2009.02-rc4 released</b>
+ <p>We had more than 50 changes since RC3, several of them
+ toolchain related, so decided to make a RC4 as well. This is
+ very much expected to be the final release candidate, so give it
+ a good test and expect a final 2009.02 release this week unless
+ critical issues are found.</p>
+
+ <p>Head to the <a href="/downloads/">downloads page</a> to pick up the
+ <a href="/downloads/buildroot-2009.02-rc4.tar.bz2">2009.02-rc4
+ release candidate</a>, and report any problems found to the <a
+ href="lists.html">mailing list</a> or <a
+ href="http://bugs.uclibc.org">bug tracker</a>.</p>
+
<li><b>31 January 2009 -- 2009.02-rc3 released</b>
<p>RC3 is out with more cleanups and bug fixes. Unless big issues
are found, expect this to be the last release candidate before the
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-02-12 9:33 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-02-12 9:33 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-02-12 09:33:01 +0000 (Thu, 12 Feb 2009)
New Revision: 25305
Log:
docs/news.html: announce 2009.02
Modified:
trunk/buildroot/docs/news.html
Changeset:
Modified: trunk/buildroot/docs/news.html
===================================================================
--- trunk/buildroot/docs/news.html 2009-02-12 09:02:36 UTC (rev 25304)
+++ trunk/buildroot/docs/news.html 2009-02-12 09:33:01 UTC (rev 25305)
@@ -3,6 +3,14 @@
<ul>
+ <li><b>12 February 2009 -- 2009.02 released</b>
+ <p>The stable 2009.02 release is out - Thanks to everyone
+ contributing and testing the release candidates. See the
+ <a href="http://lists.busybox.net/pipermail/buildroot/2009-February/025974.html">announcement</a>
+ for more details, and go to the <a href="/downloads/">downloads page</a>
+ to pick up the <a href="/downloads/buildroot-2009.02.tar.bz2">2009.02
+ release</a>.</p>
+
<li><b>9 February 2009 -- 2009.02-rc4 released</b>
<p>We had more than 50 changes since RC3, several of them
toolchain related, so decided to make a RC4 as well. This is
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-03-02 8:34 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-03-02 8:34 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-03-02 08:34:28 +0000 (Mon, 02 Mar 2009)
New Revision: 25479
Log:
docs/buildroot.html: we DO make releases nowadays
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2009-03-02 08:34:20 UTC (rev 25478)
+++ trunk/buildroot/docs/buildroot.html 2009-03-02 08:34:28 UTC (rev 25479)
@@ -116,9 +116,13 @@
<h2><a name="download" id="download"></a>Obtaining Buildroot</h2>
- <p>Buildroot is available as daily SVN snapshots or directly using
- SVN. As of today, no stable releases of Buildroot are made. </p>
+ <p>Buildroot releases are made approximately every 3
+ months. Direct SVN access and daily SVN snapshots are also
+ available if you want more bleeding edge.</p>
+ <p>Releases are available at <a
+ href="http://buildroot.net/downloads/">http://buildroot.net/downloads/</a>.</p>
+
<p>The latest snapshot is always available at <a
href="http://buildroot.net/downloads/snapshots/buildroot-snapshot.tar.bz2">http://buildroot.net/downloads/snapshots/buildroot-snapshot.tar.bz2</a>,
and previous snapshots are also available at <a
@@ -127,7 +131,7 @@
<p>To download Buildroot using SVN, you can simply follow
the rules described on the "Accessing SVN"-page (<a href=
"http://buildroot.net/subversion.html">http://buildroot.net/subversion.html</a>)
- of the uClibc buildroot website (<a href=
+ of the Buildroot website (<a href=
"http://buildroot.net">http://buildroot.net</a>), and download the
<code>buildroot</code> SVN module. For the impatient, here's a quick
recipe:</p>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [Buildroot] svn commit: trunk/buildroot/docs
@ 2009-03-02 10:09 jacmet at uclibc.org
0 siblings, 0 replies; 59+ messages in thread
From: jacmet at uclibc.org @ 2009-03-02 10:09 UTC (permalink / raw)
To: buildroot
Author: jacmet
Date: 2009-03-02 10:09:44 +0000 (Mon, 02 Mar 2009)
New Revision: 25481
Log:
docs/buildroot: use DESTDIR / install-strip for target install example
Modified:
trunk/buildroot/docs/buildroot.html
Changeset:
Modified: trunk/buildroot/docs/buildroot.html
===================================================================
--- trunk/buildroot/docs/buildroot.html 2009-03-02 09:32:46 UTC (rev 25480)
+++ trunk/buildroot/docs/buildroot.html 2009-03-02 10:09:44 UTC (rev 25481)
@@ -1014,7 +1014,7 @@
<a name="ex2line34" id="ex2line34">34</a> $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
<a name="ex2line35" id="ex2line35">35</a>
<a name="ex2line36" id="ex2line36">36</a> $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
- <a name="ex2line37" id="ex2line37">37</a> $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
+ <a name="ex2line37" id="ex2line37">37</a> $(MAKE) DESTDIR=$(TARGET_DIR) -C $(FOO_DIR) install-strip
<a name="ex2line38" id="ex2line38">38</a> rm -Rf $(TARGET_DIR)/usr/man
<a name="ex2line39" id="ex2line39">39</a>
<a name="ex2line40" id="ex2line40">40</a> foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
@@ -1111,8 +1111,8 @@
<p>Lines <a href="#ex2line36">36-38</a> defines a target and associated rules
that install the software inside the target filesystem. It depends on the
binary file in the source directory, to make sure the software has
- been compiled. It uses the <code>install</code> target of the
- software <code>Makefile</code> by passing a <code>prefix</code>
+ been compiled. It uses the <code>install-strip</code> target of the
+ software <code>Makefile</code> by passing a <code>DESTDIR</code>
argument, so that the <code>Makefile</code> doesn't try to install
the software inside host <code>/usr</code> but inside target
<code>/usr</code>. After the installation, the
^ permalink raw reply [flat|nested] 59+ messages in thread
end of thread, other threads:[~2009-03-02 10:09 UTC | newest]
Thread overview: 59+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-19 9:47 [Buildroot] svn commit: trunk/buildroot/docs aldot at uclibc.org
-- strict thread matches above, loose matches on Subject: below --
2009-03-02 10:09 jacmet at uclibc.org
2009-03-02 8:34 jacmet at uclibc.org
2009-02-12 9:33 jacmet at uclibc.org
2009-02-09 16:44 jacmet at uclibc.org
2009-01-31 23:02 jacmet at uclibc.org
2009-01-26 20:26 ulf at uclibc.org
2009-01-23 21:06 jacmet at uclibc.org
2009-01-16 19:45 jacmet at uclibc.org
2009-01-16 21:02 ` Markus Heidelberg
2009-01-16 19:45 jacmet at uclibc.org
2009-01-15 14:50 jacmet at uclibc.org
2009-01-15 14:50 jacmet at uclibc.org
2009-01-15 14:50 jacmet at uclibc.org
2009-01-15 14:50 jacmet at uclibc.org
2009-01-15 14:50 jacmet at uclibc.org
2009-01-06 16:30 ulf at uclibc.org
2009-01-06 16:34 ` Peter Korsgaard
2008-12-18 0:48 root at uclibc.org
2008-12-16 9:00 jacmet at uclibc.org
2008-12-15 22:35 tpetazzoni at uclibc.org
2008-12-15 22:44 ` Thomas Petazzoni
2008-12-16 9:03 ` Peter Korsgaard
2008-12-16 9:00 ` Peter Korsgaard
2008-12-15 22:14 tpetazzoni at uclibc.org
2008-12-08 8:15 jacmet at uclibc.org
2008-10-14 16:20 aldot at uclibc.org
2008-10-18 6:58 ` Peter Korsgaard
2008-10-06 9:11 jacmet at uclibc.org
2008-06-23 13:40 jacmet at uclibc.org
2008-03-13 17:16 ninevoltz at uclibc.org
2008-03-13 18:25 ` Peter Korsgaard
2007-09-27 21:32 aldot at uclibc.org
2007-09-19 9:08 aldot at uclibc.org
2007-09-02 17:44 aldot at uclibc.org
2007-08-24 5:28 ulf at uclibc.org
2007-08-16 21:54 ulf at uclibc.org
2007-08-12 23:26 ulf at uclibc.org
2007-08-11 21:58 ulf at uclibc.org
2007-08-01 8:11 ulf at uclibc.org
2007-07-12 17:04 ulf at uclibc.org
2007-07-12 16:53 ulf at uclibc.org
2007-07-12 14:46 ulf at uclibc.org
2007-07-12 14:43 ulf at uclibc.org
2007-07-12 15:07 ` Bernhard Fischer
2007-06-21 16:58 aldot at uclibc.org
2007-03-13 12:59 aldot at uclibc.org
2007-01-21 21:49 aldot at uclibc.org
2007-01-19 19:28 aldot at uclibc.org
2007-01-19 19:21 aldot at uclibc.org
2007-01-19 19:20 aldot at uclibc.org
2007-01-19 13:32 aldot at uclibc.org
2007-01-19 12:35 aldot at uclibc.org
2007-01-19 11:00 aldot at uclibc.org
2007-01-19 10:57 aldot at uclibc.org
2007-01-19 9:24 aldot at uclibc.org
2007-01-17 10:07 aldot at uclibc.org
2006-12-22 12:11 aldot at uclibc.org
2006-11-05 11:21 aldot at uclibc.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox