docs: remove outdated files
Misleading/outdated docs is worse than no documentation. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit is contained in:
parent
87a5a19408
commit
f55d8dff35
17
TODO
17
TODO
|
@ -1,17 +0,0 @@
|
||||||
Buildroot2 TODOs
|
|
||||||
|
|
||||||
- fix packages/Makefile.autotools.in to use a package-imposed patchdir
|
|
||||||
(Ivan Kuten)
|
|
||||||
- convert all packages that use autoconf to use the infrastructure of
|
|
||||||
packages/Makefile.autotools.in
|
|
||||||
- fix setting of flags for packages
|
|
||||||
|
|
||||||
- coreutils: use make install-strip to install the packages. For now,
|
|
||||||
it fails beause even if we pass STRIP="/path/to/$(ARCH)-strip", the
|
|
||||||
coreutils build system uses the host strip to strip target
|
|
||||||
binaries. The ./configure execution done by Buildroot properly
|
|
||||||
detects the cross-strip, but when running make, build-aux/missing
|
|
||||||
gets run, complains about aclocal-1.10c and atuomake-1.10c not being
|
|
||||||
present, and rerun the configuration... with the wrong environment
|
|
||||||
variables (STRIP= is missing). An autoreconf on this package is
|
|
||||||
probably necessary.
|
|
|
@ -4,15 +4,13 @@ To build and use the buildroot stuff, do the following:
|
||||||
2) select the packages you wish to compile
|
2) select the packages you wish to compile
|
||||||
3) run 'make'
|
3) run 'make'
|
||||||
4) wait while it compiles
|
4) wait while it compiles
|
||||||
5) Use your shiny new root filesystem. Depending on which sortof
|
5) Use your shiny new root filesystem. Depending on which sort of
|
||||||
root filesystem you selected, you may want to loop mount it,
|
root filesystem you selected, you may want to loop mount it,
|
||||||
chroot into it, nfs mount it on your target device, burn it
|
chroot into it, nfs mount it on your target device, burn it
|
||||||
to flash, or whatever is appropriate for your target system.
|
to flash, or whatever is appropriate for your target system.
|
||||||
|
|
||||||
You do not need to be root to build or run buildroot. Have fun!
|
You do not need to be root to build or run buildroot. Have fun!
|
||||||
|
|
||||||
-Erik
|
|
||||||
|
|
||||||
Offline build:
|
Offline build:
|
||||||
==============
|
==============
|
||||||
|
|
||||||
|
|
|
@ -1,37 +0,0 @@
|
||||||
# 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
|
|
|
@ -1,67 +0,0 @@
|
||||||
<!--#include file="header.html" -->
|
|
||||||
|
|
||||||
<h2>Testing Buildroot for an Architecture</h2>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
<h4>scripts/mkpkg script</h4>
|
|
||||||
If you want to test the build of a single package you can use the mkpkg script.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<li>$ scripts/mkpkg PACKAGE</li>
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
Will make the board, and save the result in a log file.
|
|
||||||
The log file resides in
|
|
||||||
<li>$ log/OK/PACKAGE.log.OK</li>
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
if the build succeeds and in
|
|
||||||
<li>$ log/OK/PACKAGE.log.FAIL</li>
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
if it cannot complete.
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
By creating an alias
|
|
||||||
<li>alias mk=scripts/mkpkg</li>
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
it is enough to type
|
|
||||||
<li>$ mk PACKAGE</li>
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
mkpkg will only print out the <h4>{PACKAGE}......OK</h4> or <h4>{PACKAGE}......FAIL</h4>
|
|
||||||
depending on success or failure making it easy to get an overview
|
|
||||||
of the status of this specific architecture.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
It is recommended to build a simple board before running the test
|
|
||||||
to get some basic things done.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<h4>scripts/buildall.sh script</h4>
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
By running this script you will run scripts/mkpkg on
|
|
||||||
a lot of the packages available in Buildroot.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
You need to run the script while in the TOP directory.
|
|
||||||
I.E: Where you typically run make.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
There are a few lacking, for no very good reason,
|
|
||||||
but these can be easily added.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
Note that some packages will not build properly
|
|
||||||
if you do not enable them using makeconfig.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
Examples are:
|
|
||||||
<li>freetype</li>
|
|
||||||
<li>socat</li>
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<!--#include file="footer.html" -->
|
|
254
docs/U-boot.html
254
docs/U-boot.html
|
@ -1,254 +0,0 @@
|
||||||
<?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.net/">U-Boot</a>
|
|
||||||
usage and documentation by Ulf Samuelsson.
|
|
||||||
</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>
|
|
|
@ -1,43 +0,0 @@
|
||||||
<!--#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" -->
|
|
109
scripts/mkpkg
109
scripts/mkpkg
|
@ -1,109 +0,0 @@
|
||||||
#!/bin/bash
|
|
||||||
OK=0
|
|
||||||
FAIL=1
|
|
||||||
TOPDIR=`pwd`
|
|
||||||
LOG_FILE=$1.log
|
|
||||||
LOG_DIR=${TOPDIR}/log/
|
|
||||||
LOG=${LOG_DIR}/${LOG_FILE}
|
|
||||||
DEPENDENCY=${LOG_DIR}/DEPEND/$1.depend.txt
|
|
||||||
|
|
||||||
LOG_OK_DIR=${LOG_DIR}/OK
|
|
||||||
LOG_FAIL_DIR=${LOG_DIR}/FAIL
|
|
||||||
LOG_OK_FILE=${LOG_OK_DIR}/${LOG_FILE}.OK
|
|
||||||
LOG_FAIL_FILE=${LOG_FAIL_DIR}/${LOG_FILE}.FAIL
|
|
||||||
|
|
||||||
mkdir -p ${LOG_DIR}
|
|
||||||
mkdir -p ${LOG_OK_DIR}
|
|
||||||
mkdir -p ${LOG_FAIL_DIR}
|
|
||||||
mkdir -p ${LOG_DIR}/DEPEND
|
|
||||||
|
|
||||||
test=${OK}
|
|
||||||
|
|
||||||
function clean_files()
|
|
||||||
{
|
|
||||||
rm -f ${LOG}
|
|
||||||
rm -f ${LOG_OK_FILE}
|
|
||||||
rm -f ${LOG_FAIL_FILE}
|
|
||||||
rm -f ${DEPENDENCY}
|
|
||||||
}
|
|
||||||
|
|
||||||
function dirclean ()
|
|
||||||
{
|
|
||||||
make $1-dirclean > /dev/null 2>&1
|
|
||||||
}
|
|
||||||
|
|
||||||
function process ()
|
|
||||||
{
|
|
||||||
make $1 >> ${LOG} 2>&1 || test=${FAIL}
|
|
||||||
grep "\.tar\." ${LOG} > ${DEPENDENCY}
|
|
||||||
if [ ${test} = ${OK} ] ; then
|
|
||||||
mv ${LOG} ${LOG_OK_FILE}
|
|
||||||
printf "%-16s" "OK"
|
|
||||||
if [ "${2}X" != "X" ] ; then
|
|
||||||
printf "%-16s" "\"$2\"";
|
|
||||||
fi
|
|
||||||
if [ "${3}X" != "X" ] ; then
|
|
||||||
printf "%s" "\"$3\"";
|
|
||||||
fi
|
|
||||||
echo
|
|
||||||
else
|
|
||||||
mv ${LOG} ${LOG_FAIL_FILE}
|
|
||||||
printf "%-16s" "FAIL"
|
|
||||||
if [ "${2}X" != "X" ] ; then
|
|
||||||
printf "%-16s" "\"$2\"";
|
|
||||||
else
|
|
||||||
printf "%-16s" "\"\""
|
|
||||||
fi
|
|
||||||
if [ "${3}X" != "X" ] ; then
|
|
||||||
printf "%s" "\"$3\"";
|
|
||||||
fi
|
|
||||||
echo
|
|
||||||
fi
|
|
||||||
}
|
|
||||||
|
|
||||||
function build_package ()
|
|
||||||
{
|
|
||||||
# echo "BUILD PACKAGE:1=$1 2=$2 3=$3 4=$4 5=$5 6=$6 7=$7"
|
|
||||||
printf "mk %-32s" "$1"
|
|
||||||
if [ "$2X" = "X" ] ; then # no parameters
|
|
||||||
clean_files $1
|
|
||||||
dirclean $1
|
|
||||||
process $1 "$3"
|
|
||||||
elif [ "$2X" = "?X" ] ; then # no parameters
|
|
||||||
clean_files $1
|
|
||||||
dirclean $1
|
|
||||||
process $1 "$3"
|
|
||||||
elif [ "$2X" = "OKX" ] ; then # Previous build was OK
|
|
||||||
clean_files $1
|
|
||||||
dirclean $1
|
|
||||||
process $1 "$3"
|
|
||||||
elif [ "$2X" = "FAILX" ] ; then
|
|
||||||
clean_files $1
|
|
||||||
dirclean $1
|
|
||||||
process $1 "$3"
|
|
||||||
elif [ "$2X" = "BROKENX" ] ; then
|
|
||||||
printf "%-16s" "BROKEN"
|
|
||||||
if [ "${3}X" != "X" ] ; then
|
|
||||||
printf "%s" "\"$3\"";
|
|
||||||
fi
|
|
||||||
echo
|
|
||||||
elif [ "$2X" = "DISABLEDX" ] ; then
|
|
||||||
printf "%-16s" "DISABLED"
|
|
||||||
if [ "${3}X" != "X" ] ; then
|
|
||||||
printf "%s" "\"$3\"";
|
|
||||||
fi
|
|
||||||
echo
|
|
||||||
else
|
|
||||||
printf "%-16s" "?BROKEN"
|
|
||||||
if [ "${3}X" != "X" ] ; then
|
|
||||||
printf "%s" "\"$3\"";
|
|
||||||
fi
|
|
||||||
echo
|
|
||||||
fi
|
|
||||||
}
|
|
||||||
|
|
||||||
#build_package $1 $2 "\"$3\""
|
|
||||||
build_package $1 $2 "$3"
|
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user