projects / openwrt.git / blob
? search:


bd9642202f9ac4590da2256968ac06b44f130b5c
[openwrt.git] / openwrt / docs / buildroot-documentation.html
1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
3 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
4
5 <html xmlns="http://www.w3.org/1999/xhtml">
6 <head>
7 <title>OpenWrt Buildroot - Usage and documentation</title>
8 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
9 <link rel="stylesheet" type="text/css" href="stylesheet.css" />
10 </head>
11
12 <body>
13 <div class="main">
14 <div class="titre">
15 <h1>OpenWrt Buildroot</h1>
16 </div>
17
18 <p>Usage and documentation by Felix Fietkau, based on uClibc Buildroot
19 documentation by Thomas Petazzoni. Contributions from Karsten Kruse,
20 Ned Ludd, Martin Herren.</p>
21
22 <p><small>Last modification : $Id$</small></p>
23
24 <ul>
25 <li><a href="#about">About OpenWrt Buildroot</a></li>
26 <li><a href="#download">Obtaining OpenWrt Buildroot</a></li>
27 <li><a href="#using">Using OpenWrt Buildroot</a></li>
28 <li><a href="#custom_targetfs">Customizing the target filesystem</a></li>
29 <li><a href="#custom_busybox">Customizing the Busybox
30 configuration</a></li>
31 <li><a href="#custom_uclibc">Customizing the uClibc
32 configuration</a></li>
33 <li><a href="#buildroot_innards">How OpenWrt Buildroot works</a></li>
34 <li><a href="#using_toolchain">Using the uClibc toolchain</a></li>
35 <li><a href="#toolchain_standalone">Using the uClibc toolchain
36 outside of Buildroot</a></li>
37 <li><a href="#downloaded_packages">Location of downloaded packages</a></li>
38 <li><a href="#add_software">Extending OpenWrt with more Software</a></li>
39 <li><a href="#links">Ressources</a></li>
40 </ul>
41
42 <h2><a name="about" id="about"></a>About OpenWrt Buildroot</h2>
43
44 <p>OpenWrt Buildroot is a set of Makefiles and patches that allows to easily
45 generate both a cross-compilation toolchain and a root filesystem for your
46 Wireless Router. The cross-compilation toolchain uses uClibc (<a href=
47 "http://www.uclibc.org/">http://www.uclibc.org/</a>), a tiny C standard
48 library.</p>
49
50 <p>A compilation toolchain is the set of tools that allows to
51 compile code for your system. It consists of a compiler (in our
52 case, <code>gcc</code>), binary utils like assembler and linker
53 (in our case, <code>binutils</code>) and a C standard library (for
54 example <a href="http://www.gnu.org/software/libc/libc.html">GNU
55 Libc</a>, <a href="http://www.uclibc.org">uClibc</a> or <a
56 href="http://www.fefe.de/dietlibc/">dietlibc</a>). The system
57 installed on your development station certainly already has a
58 compilation toolchain that you can use to compile application that
59 runs on your system. If you're using a PC, your compilation
60 toolchain runs on an x86 processor and generates code for a x86
61 processor. Under most Linux systems, the compilation toolchain
62 uses the GNU libc as C standard library. This compilation
63 toolchain is called the "host compilation toolchain", and more
64 generally, the machine on which it is running, and on which you're
65 working is called the "host system". The compilation toolchain is
66 provided by your distribution, and OpenWrt Buildroot has nothing to do
67 with it.</p>
68
69 <p>As said above, the compilation toolchain that comes with your system
70 runs and generates code for the processor of your host system. As your
71 embedded system has a different processor, you need a cross-compilation
72 toolchain: it's a compilation toolchain that runs on your host system but
73 that generates code for your target system (and target processor). For
74 example, if your host system uses x86 and your target system uses MIPS, the
75 regular compilation toolchain of your host runs on x86 and generates code
76 for x86, while the cross-compilation toolchain runs on x86 and generates
77 code for MIPS.</p>
78
79 <p>You might wonder why such a tool is needed when you can compile
80 <code>gcc</code>, <code>binutils</code>, uClibc and all the tools by hand.
81 Of course, doing so is possible. But dealing with all configure options,
82 with all problems of every <code>gcc</code> or <code>binutils</code>
83 version is very time-consuming and uninteresting. OpenWrt Buildroot automates this
84 process through the use of Makefiles, and has a collection of patches for
85 each <code>gcc</code> and <code>binutils</code> version to make them work
86 on the MIPS architecture of most Wireless Routers.</p>
87
88 <h2><a name="download" id="download"></a>Obtaining OpenWrt Buildroot</h2>
89
90 <p>OpenWrt Buildroot is available via CVS - Concurrent Version System.
91 For any kind of development you should get the latest version from cvs via:</p>
92 <pre>
93 $ cvs -d:pserver:anonymous@openwrt.org:/openwrt co openwrt
94 </pre>
95
96 <h2><a name="using" id="using"></a>Using OpenWrt Buildroot</h2>
97
98 <p>OpenWrt Buildroot has a nice configuration tool similar to the one you can find
99 in the Linux Kernel (<a href="http://www.kernel.org/">http://www.kernel.org/</a>)
100 or in Busybox (<a href="http://www.busybox.org/">http://www.busybox.org/</a>).
101 Note that you can run everything as a normal user. There is no need to be root to
102 configure and use the Buildroot. The first step is to run the configuration
103 assistant:</p>
104
105 <pre>
106 $ make menuconfig
107 </pre>
108
109 <p>For each entry of the configuration tool, you can find associated help
110 that describes the purpose of the entry.</p>
111
112 <p>Once everything is configured, the configuration tool has generated a
113 <code>.config</code> file that contains the description of your
114 configuration. It will be used by the Makefiles to do what's needed.</p>
115
116 <p>Let's go:</p>
117
118 <pre>
119 $ make
120 </pre>
121
122 <p>This command will download, configure and compile all the selected
123 tools, and finally generate target firmware images and additional packages
124 (depending on your selections in <code>make menuconfig</code>.
125 All the target files can be found in the <code>bin/</code> subdirectory.
126 You can compile firmware images containing two different filesystem types:
127 <ul>
128 <li>jffs2</li>
129 <li>squashfs</li>
130 </ul>
131 <p><code>jffs2</code> contains a writable root filesystem, which will expand to
132 the size of your flash image. Note that you if you use the generic firmware
133 Image, you need to pick the right image for your Flash size, because of different
134 eraseblock sizes.</p>
135
136 <p><code>squashfs</code> contains a read-only root filesystem using a modified
137 <code>squashfs</code> filesystem with LZMA compression. When booting it, you can
138 create a writable second filesystem, which will contain your modifications to
139 the root filesystem, including the packages you install.
140
141 <h2><a name="custom_targetfs" id="custom_targetfs"></a>Customizing the
142 target filesystem</h2>
143
144 <p>There are two ways to customize the resulting target filesystem:</p>
145
146 <ul>
147 <li>Customize the target filesystem directly, and rebuild the image. The
148 target filesystem is available under <code>build_ARCH/root/</code> where
149 <code>ARCH</code> is the chosen target architecture, usually mipsel.
150 You can simply make your changes here, and run make target_install afterwards,
151 which will rebuild the target filesystem image. This method allows to do
152 everything on the target filesystem, but if you decide to rebuild your toolchain,
153 tools or packages, these changes will be lost.</li>
154
155 <li>Customize the target filesystem skeleton, available under
156 <code>target/default/target_skeleton/</code>. You can customize
157 configuration files or other stuff here. However, the full file hierarchy
158 is not yet present, because it's created during the compilation process.
159 So you can't do everything on this target filesystem skeleton, but
160 changes to it remains even when you completely rebuild the cross-compilation
161 toolchain and the tools.<br />
162 </ul>
163
164 <h2><a name="custom_busybox" id="custom_busybox"></a>Customizing the
165 Busybox configuration</h2>
166
167 <p>Busybox is very configurable, and you may want to customize it.
168 Its configuration is completely integrated into the main menuconfig system.
169 You can find it under "OpenWrt Package Selection" =&gt; "Busybox Configuration"</p>
170
171 <h2><a name="custom_uclibc" id="custom_uclibc"></a>Customizing the uClibc
172 configuration</h2>
173
174 <p>Just like <a href="#custom_busybox">BusyBox</a>, <a
175 href="http://www.uclibc.org">uClibc</a> offers a lot of
176 configuration options. They allow to select various
177 functionalities, depending on your needs and limitations.</p>
178
179 <p>The easiest way to modify the configuration of uClibc is to
180 follow these steps :</p>
181
182 <ol>
183
184 <li>Make a first compilation of buildroot without trying to
185 customize uClibc.</li>
186
187 <li>Go into the directory
188 <code>toolchain_build_ARCH/uClibc/</code> and run <code>make
189 menuconfig</code>. The nice configuration assistant, similar to
190 the one used in the Linux Kernel appears. Make
191 your configuration as appropriate.</li>
192
193 <li>Copy the <code>.config</code> file to
194 <code>toolchain/uClibc/uClibc.config</code> or
195 <code>toolchain/uClibc/uClibc.config-locale</code>. The former
196 is used if you haven't selected locale support in the Buildroot
197 configuration, and the latter is used if you have selected
198 locale support.</li>
199
200 <li>Run the compilation again</li>
201
202 </ol>
203
204 <p>Otherwise, you can simply change
205 <code>toolchain/uClibc/uClibc.config</code> or
206 <code>toolchain/uClibc/uClibc.config-locale</code> without running
207 the configuration assistant.</p>
208
209 <h2><a name="buildroot_innards" id="buildroot_innards"></a>How OpenWrt Buildroot
210 works</h2>
211
212 <p>As said above, OpenWrt is basically a set of Makefiles that download,
213 configure and compiles software with the correct options. It also includes
214 some patches for various software, mainly the ones involved in the
215 cross-compilation tool chain (<code>gcc</code>, <code>binutils</code> and
216 uClibc).</p>
217
218 <p>There is basically one Makefile per software, and they are named <code>Makefile</code>.
219 Makefiles are split into three sections:</p>
220
221 <ul>
222 <li><b>package</b> (in the <code>package/</code> directory) contains the
223 Makefiles and associated files for all user-space tools that Buildroot
224 can compile and add to the target root filesystem. There is one
225 sub-directory per tool.</li>
226
227 <li><b>toolchain</b> (in the <code>toolchain/</code> directory) contains
228 the Makefiles and associated files for all software related to the
229 cross-compilation toolchain : <code>binutils</code>, <code>ccache</code>,
230 <code>gcc</code>, <code>gdb</code>, <code>kernel-headers</code> and
231 <code>uClibc</code>.</li>
232
233 <li><b>target</b> (in the <code>target</code> directory) contains the
234 Makefiles and associated files for software related to the generation of
235 the target root filesystem image. Two types of filesystems are supported
236 : jffs2 and squashfs.
237 </ul>
238
239 <p>Each directory contains at least 2 files :</p>
240
241 <ul>
242 <li><code>Makefile</code> is the Makefile that downloads, configures,
243 compiles and installs the software <code>something</code>.</li>
244
245 <li><code>Config.in</code> is a part of the configuration tool
246 description file. It describes the option related to the current
247 software.</li>
248 </ul>
249
250 <p>The main Makefile do the job through the following steps (once the
251 configuration is done):</p>
252
253 <ol>
254 <li>Create the download directory (<code>dl/</code> by default). This is
255 where the tarballs will be downloaded. It is interesting to know that the
256 tarballs are in this directory because it may be useful to save them
257 somewhere to avoid further downloads.</li>
258
259 <li>Create the build directory (<code>build_ARCH/</code> by default,
260 where <code>ARCH</code> is your architecture). This is where all
261 user-space tools while be compiled.</li>
262
263 <li>Create the toolchain build directory
264 (<code>toolchain_build_ARCH/</code> by default, where <code>ARCH</code>
265 is your architecture). This is where the cross compilation toolchain will
266 be compiled.</li>
267
268 <li>Setup the staging directory (<code>staging_dir_ARCH/</code> by
269 default). This is where the cross-compilation toolchain will be
270 installed. If you want to use the same cross-compilation toolchain for
271 other purposes, such as compiling third-party applications, you can add
272 <code>staging_dir_ARCH/bin</code> to your PATH, and then use
273 <code>arch-linux-gcc</code> to compile your application. In order to
274 setup this staging directory, it first removes it, and then it creates
275 various subdirectories and symlinks inside it.</li>
276
277 <li>Create the target directory (<code>build_ARCH/root/</code> by
278 default) and the target filesystem skeleton. This directory will contain
279 the final root filesystem. To setup it up, it first deletes it, then it
280 copies the skeleton available in <code>target/default/target_skeleton</code>
281 and then removes useless <code>CVS/</code> directories.</li>
282
283 <li>Call the <code>prepare</code>, <code>compile</code> and <code>install</code>
284 targets for the subdirectories <code>toolchain</code>, <code>package</code>
285 and <code>target</code></li>
286 </ol>
287
288 <h2><a name="using_toolchain" id="using_toolchain"></a>Using the
289 uClibc toolchain</h2>
290
291 <p>You may want to compile your own programs or other software
292 that are not packaged in OpenWrt. In order to do this, you can
293 use the toolchain that was generated by the Buildroot.</p>
294
295 <p>The toolchain generated by the Buildroot by default is located in
296 <code>staging_dir_ARCH</code>. The simplest way to use it
297 is to add <code>staging_dir_ARCH/bin/</code> to your PATH
298 environment variable, and then to use
299 <code>arch-linux-gcc</code>, <code>arch-linux-objdump</code>,
300 <code>arch-linux-ld</code>, etc.</p>
301
302 <p>For example, you may add the following to your
303 <code>.bashrc</code> (considering you're building for the MIPS
304 architecture and that Buildroot is located in
305 <code>~/buildroot/</code>) :</p>
306
307 <pre>
308 export PATH=$PATH:~/buildroot/staging_dir_mipsel/bin/
309 </pre>
310
311 <p>Then you can simply do :</p>
312
313 <pre>
314 mipsel-linux-uclibc-gcc -o foo foo.c
315 </pre>
316
317 <p><b>Important</b> : do not try to move the toolchain to an other
318 directory, it won't work. There are some hard-coded paths in the
319 <i>gcc</i> configuration. If the default toolchain directory
320 doesn't suit your needs, please refer to the <a
321 href="#toolchain_standalone">Using the uClibc toolchain outside of
322 buildroot</a> section.</p>
323
324 <h2><a name="toolchain_standalone" id="toolchain_standalone"></a>Using the
325 uClibc toolchain outside of buildroot</h2>
326
327 <p>By default, the cross-compilation toolchain is generated inside
328 <code>staging_dir_ARCH/</code>. But sometimes, it may be useful to
329 install it somewhere else, so that it can be used to compile other programs
330 or by other users. Moving the <code>staging_dir_ARCH/</code>
331 directory elsewhere is <b>not possible</b>, because they are some hardcoded
332 paths in the toolchain configuration.</p>
333
334 <p>If you want to use the generated toolchain for other purposes,
335 you can configure Buildroot to generate it elsewhere using the
336 option of the configuration tool : <code>Build options -&gt;
337 Toolchain and header file location</code>, which defaults to
338 <code>staging_dir_ARCH/</code>.</p>
339
340 <h2><a name="downloaded_packages"
341 id="downloaded_packages"></a>Location of downloaded packages</h2>
342
343 <p>It might be useful to know that the various tarballs that are
344 downloaded by the <i>Makefiles</i> are all stored in the
345 <code>DL_DIR</code> which by default is the <code>dl</code>
346 directory. It's useful for example if you want to keep a complete
347 version of Buildroot which is know to be working with the
348 associated tarballs. This will allow you to regenerate the
349 toolchain and the target filesystem with exactly the same
350 versions.</p>
351
352 <h2><a name="add_software" id="add_software"></a>Extending OpenWrt with
353 more software</h2>
354
355 <p>This section will only consider the case in which you want to
356 add user-space software.</p>
357
358 <h3>Package directory</h3>
359
360 <p>First of all, create a directory under the <code>package</code>
361 directory for your software, for example <code>foo</code>.</p>
362
363 <h3><code>Config.in</code> file</h3>
364
365 <p>Then, create a file named <code>Config.in</code>. This file
366 will contain the portion of options description related to our
367 <code>foo</code> software that will be used and displayed in the
368 configuration tool. It should basically contain :</p>
369
370 <pre>
371 config BR2_PACKAGE_FOO
372 tristate "foo"
373 default n
374 help
375 This is a comment that explains what foo is.
376 </pre>
377
378 <p>Of course, you can add other options to configure particular
379 things in your software.</p>
380
381 <h3><code>Makefile</code> in the package directory</h3>
382
383 <p>To add your package to the build process, you need to edit
384 the Makefile in the <code>package/</code> directory. Locate the
385 lines that look like the following:</p>
386
387 <pre>
388 package-$(BR2_PACKAGE_FOO) += foo
389 </pre>
390
391 <p>As you can see, this short line simply adds the target
392 <code>foo</code> to the list of targets handled by OpenWrt Buildroot.</p>
393
394
395 <p>In addition to the default dependencies, you make your package
396 depend on another package (e.g. a library) by adding a line:
397
398 <pre>
399 foo-compile: bar-compile
400 </pre>
401
402 <h3>The <i>.control</i> file</h3>
403 <p>Additionally, you need to create a control file which contains
404 information about your package, readable by the <i>ipkg</i> package
405 utility.</p>
406
407 <p>The file looks like this</p>
408
409 <pre>
410 1 Package: foo
411 2 Priority: optional
412 3 Section: net
413 4 Maintainer: Foo Software &lt;foo@foosoftware.com&gt;
414 5 Source: http://foosoftware.com
415 6 Description: Your Package Description
416 </pre>
417
418 <p>You can skip the usual <code>Version:</code> and <code>Architecture</code>
419 fields, as they will be generated by the <code>make-ipkg-dir.sh</code> script
420 called from your Makefile</p>
421
422 <h3>The real <i>Makefile</i></h3>
423
424 <p>Finally, here's the hardest part. Create a file named
425 <code>Makefile</code>. It will contain the <i>Makefile</i> rules that
426 are in charge of downloading, configuring, compiling and installing
427 the software. Below is an example that we will comment
428 afterwards.</p>
429
430 <pre>
431 1 # $Id$
432 2 include $(TOPDIR)/rules.mk
433 3 PKG_NAME:=foo
434 4 PKG_VERSION:=1.0
435 5 PKG_RELEASE:=1
436 6 PKG_MD5SUM:=4584f226523776a3cdd2fb6f8212ba8d
437 7
438 8 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
439 9 PKG_SOURCE_URL:=http://www.foosoftware.org/downloads
440 10 PKG_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)
441 11 PKG_IPK:=$(PACKAGE_DIR)/$(PKG_NAME)_$(PKG_VERSION)-$(PKG_RELEASE)_$(ARCH).ipk
442 12 PKG_IPK_DIR:=$(PKG_DIR)/ipkg
443 13
444 14 $(DL_DIR)/$(PKG_SOURCE):
445 15 $(SCRIPT_DIR)/download.pl $(DL_DIR) $(PKG_SOURCE) $(PKG_MD5SUM) $(PKG_SOURCE_URL)
446 16
447 17 $(PKG_DIR)/.source: $(DL_DIR)/$(PKG_SOURCE)
448 18 zcat $(DL_DIR)/$(PKG_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
449 19 touch $(PKG_DIR)/.source
450 20
451 21 $(PKG_DIR)/.configured: $(PKG_DIR)/.source
452 22 (cd $(PKG_DIR); \
453 23 $(TARGET_CONFIGURE_OPTS) \
454 24 CFLAGS="$(TARGET_CFLAGS)" \
455 25 ./configure \
456 26 --target=$(GNU_TARGET_NAME) \
457 27 --host=$(GNU_TARGET_NAME) \
458 28 --build=$(GNU_HOST_NAME) \
459 29 --prefix=/usr \
460 30 --sysconfdir=/etc \
461 31 );
462 32 touch $(PKG_DIR)/.configured;
463 33
464 34 $(PKG_DIR)/$(PKG_NAME): $(PKG_DIR)/.configured
465 35 $(MAKE) CC=$(TARGET_CC) -C $(PKG_DIR)
466 36
467 37 $(PKG_IPK): $(PKG_DIR)/$(PKG_NAME)
468 38 $(SCRIPT_DIR)/make-ipkg-dir.sh $(PKG_IPK_DIR) $(PKG_NAME).control $(PKG_VERSION)-$(PKG_RELEASE) $(ARCH)
469 39 $(MAKE) prefix=$(PKG_IPK_DIR)/usr -C $(PKG_DIR) install
470 40 rm -Rf $(PKG_IPK_DIR)/usr/man
471 41 $(IPKG_BUILD) $(PKG_IPK_DIR) $(PACKAGE_DIR)
472 42
473 43 $(IPKG_STATE_DIR)/info/$(PKG_NAME).list: $(PKG_IPK)
474 44 $(IPKG) install $(PKG_IPK)
475 45
476 46 prepare: $(PKG_DIR)/.source
477 47 compile: $(PKG_IPK)
478 48 install: $(IPKG_STATE_DIR)/info/$(PKG_NAME).list
479 49 clean:
480 50 rm -rf $(PKG_DIR)
481 51 rm -f $(PKG_IPK)
482 </pre>
483
484 <p>First of all, this <i>Makefile</i> example works for a single
485 binary software. For other software such as libraries or more
486 complex stuff with multiple binaries, it should be adapted. Look at
487 the other <code>Makefile</code> files in the <code>package</code>
488 directory.</p>
489
490 <p>At lines 3-12, a couple of useful variables are defined :</p>
491
492 <ul>
493 <li><code>PKG_NAME</code> : The package name, e.g. <i>foo</i>.</li>
494
495 <li><code>PKG_VERSION</code> : The version of the package that
496 should be downloaded.</li>
497
498 <li><code>PKG_RELEASE</code> : The release number that will be
499 appended to the version number of your <i>ipkg</i> package.
500
501 <li><code>PKG_MD5SUM</code> : The md5sum of the software archive.
502
503 <li><code>PKG_SOURCE</code> : The name of the tarball of
504 your package on the download website of FTP site. As you can see
505 <code>PKG_NAME</code> and <code>PKG_VERSION</code> are used.</li>
506
507 <li><code>PKG_SOURCE_URL</code> : Space separated list of the HTTP
508 or FTP sites from which the archive is downloaded. It must include the complete
509 path to the directory where <code>FOO_SOURCE</code> can be
510 found.</li>
511
512 <li><code>PKG_DIR</code> : The directory into which the software
513 will be configured and compiled. Basically, it's a subdirectory
514 of <code>BUILD_DIR</code> which is created upon decompression of
515 the tarball.</li>
516
517 <li><code>PKG_IPK</code> : The resulting <i>ipkg</i> package
518
519 </ul>
520
521 <p>Lines 14-15 defines a target that downloads the tarball from
522 the remote site to the download directory
523 (<code>DL_DIR</code>).</p>
524
525 <p>Lines 17-19 defines a target and associated rules that
526 uncompress the downloaded tarball. As you can see, this target
527 depends on the tarball file, so that the previous target (line
528 14-15) is called before executing the rules of the current
529 target. Uncompressing is followed by <i>touching</i> a hidden file
530 to mark the software has having been uncompressed. This trick is
531 used everywhere in Buildroot <i>Makefile</i> to split steps
532 (download, uncompress, configure, compile, install) while still
533 having correct dependencies.</p>
534
535 <p>Lines 21-32 defines a target and associated rules that
536 configures the software. It depends on the previous target (the
537 hidden <code>.source</code> file) so that we are sure the software has
538 been uncompressed. In order to configure it, it basically runs the
539 well-known <code>./configure</code>script. As we may be doing
540 cross-compilation, <code>target</code>, <code>host</code> and
541 <code>build</code> arguments are given. The prefix is also set to
542 <code>/usr</code>, not because the software will be installed in
543 <code>/usr</code> on your host system, but in the target
544 filesystem. Finally it creates a <code>.configured</code> file to
545 mark the software as configured.</p>
546
547 <p>Lines 34-35 defines a target and a rule that compiles the
548 software. This target will create the binary file in the
549 compilation directory, and depends on the software being already
550 configured (hence the reference to the <code>.configured</code>
551 file). It basically runs <code>make</code> inside the source
552 directory.</p>
553
554 <p>Lines 37-41 defines a target and associated rules that create
555 the <i>ipkg</i> package which can optionally be embedded into
556 the resulting firmware image. It depends on the binary file in
557 the source directory, to make sure the software has been compiled.
558 It uses the make-ipkg-dir.sh script, which will create the ipkg
559 build directory for your package, copy your control file into
560 that directory and add version and architecture information.
561 Then it calls the <code>install</code> target of the
562 software <code>Makefile</code> by passing a <code>prefix</code>
563 argument, so that the <code>Makefile</code> doesn't try to install
564 the software inside host <code>/usr</code> but inside target
565 <code>/usr</code>. After the installation, the
566 <code>/usr/man</code> directory inside the target filesystem is
567 removed to save space.
568 Finally <code>IPKG_BUILD</code> is called to create the package.</p>
569
570 <p>Line 43 and 44 define the installation target of your package,
571 which will embed the software into the target filesystem.</p>
572
573 <p>Lines 46-51 define the main targets that the Makefile in the
574 <code>package</code> dir calls.
575 <ul>
576 <li><code>prepare</code> : Download and unpack the source</li>
577 <li><code>compile</code> : Compile the source and create the package</li>
578 <li><code>install</code> : Embed the package into the target filesystem</li>
579 <li><code>clean</code> : Remove all the files created by the build process</li>
580 </ul></p>
581
582 <h3>Conclusion</h3>
583
584 <p>As you can see, adding a software to buildroot is simply a
585 matter of writing a <i>Makefile</i> using an already existing
586 example and to modify it according to the compilation process of
587 the software.</p>
588
589 <p>If you package software that might be useful for other persons,
590 don't forget to send a patch to OpenWrt developers !</p>
591
592 <h2><a name="links" id="links"></a>Resources</h2>
593
594 <p>To learn more about OpenWrt Buildroot you can visit this
595 website: <a href="http://openwrt.org/">http://openwrt.org/</a></p>
596
597 </div>
598 </body>
599 </html>
Personal OpenWRT clone
This page took 0.0634169999999999 seconds and 3 git commands to generate.