BuildrootBuildroot uso e documentao por Thomas Petazzoni.
Contribuies de Karsten Kruse, Ludd Ned, Herren Martin e outros.
Sobre BuildRoot Obteno BuildRoot Usando BuildRoot Personalizar o
sistema de arquivos gerados alvo Personalizando a configurao
Busybox Personalizando a configurao uClibc Personalizando a
configurao do kernel Linux Compreenso de como reconstruir pacotes
Como funciona BuildRoot Usando o uClibc BuildRoot fora toolchain
Use um conjunto de ferramentas externas Usando ccache em BuildRoot
Localizao de pacotes baixados Adicionando novos pacotes BuildRoot
Criar o seu prprio suporte de placa Perguntas mais frequentes
Recursos
Sobre BuildRootBuildroot um conjunto de Makefiles e patches que
permite que voc facilmente gerar uma compilao cruzada toolchain, um
sistema de arquivos raiz e uma imagem de kernel Linux para o seu
alvo. Buildroot pode ser usado para uma, duas ou todas essas opes,
de forma independente. Buildroot til principalmente para pessoas
que trabalham com sistemas embarcados. Sistemas embarcados, muitas
vezes usam processadores que no so os processadores x86 regulares
todos esto acostumados a ter em seu PC. Podem ser processadores
PowerPC, processadores MIPS, processadores ARM, etc Uma compilao
toolchain o conjunto de ferramentas que permite que voc compilar o
cdigo para o seu sistema. Ele consiste de um compilador (no nosso
caso, gcc ), utils binrios como assembler e linker (no nosso caso,
binutils ) e uma biblioteca C padro (por exemplo Libc GNU , uClibc
ou dietlibc ). O sistema instalado na sua estao de desenvolvimento,
certamente j tem uma compilao toolchain que voc pode usar para
compilar uma aplicao que roda em seu sistema. Se voc estiver usando
um PC, suas corridas compilao toolchain em um processador x86 e
gera cdigo para um processador x86. Na maioria dos sistemas Linux,
a compilao toolchain usa o GNU libc (glibc) como a biblioteca C
padro. Esta compilao toolchain chamado de "compilao anfitrio
toolchain". A mquina em que ele est sendo executado, e no qual voc
est trabalhando, chamado de "sistema host". A compilao toolchain
fornecido por sua distribuio, e BuildRoot no tem nada a ver com
isso (que no us-lo para construir um ferramentas de compilao
cruzada toolchain e outros que so executados na mquina de
desenvolvimento). Como dito acima, a compilao toolchain que vem com
o sistema rodando e gera o cdigo para o processador no seu sistema
host. Como seu sistema incorporado tem um processador diferente,
voc precisa de uma compilao cruzada toolchain - uma compilao
toolchain que roda em seu sistema host, mas gera cdigo para o seu
sistema de destino (e processador de destino). Por exemplo, se seu
sistema host x86 e usa seu sistema de destino usa ARM, a compilao
regulares toolchain em seu
host roda em x86 e gera cdigo para x86, enquanto os
corta-mato-compilao toolchain em x86 e gera cdigo para ARM. Mesmo
que o seu sistema embarcado utiliza um processador x86, voc poderia
estar interessado em BuildRoot por duas razes: A compilao toolchain
em seu host certamente usa a GNU libc que um completo, mas enorme
biblioteca C padro. Em vez de usar Libc GNU no seu sistema alvo,
voc pode usar uClibc que uma pequena biblioteca C padro. Se voc
quiser usar esta biblioteca C, ento voc precisa de uma compilao
toolchain para gerar os binrios ligados com ele. Buildroot pode
fazer isso por voc. Buildroot automatiza a construo de um sistema
de arquivos raiz com todas as ferramentas necessrias como busybox.
Isso torna muito mais fcil do que faz-lo com a mo. Voc pode
perguntar por que essa ferramenta necessrio quando voc pode
compilar gcc , binutils , uClibc e todas as outras ferramentas mo.
claro que isso possvel, mas, lidando com todas as opes de
configurao e problemas de cada gcc ou binutils verso muito demorado
e desinteressante. Buildroot automatiza esse processo atravs do uso
de Makefiles e tem uma coleo de correes para cada gcc e binutils
verso para faz-los funcionar na maioria das arquitecturas. Alm
disso, BuildRoot fornece uma infra-estrutura para reproduzir o
processo de construo do seu kernel, cross-toolchain, e sistema de
arquivos raiz incorporado. Ser capaz de reproduzir o processo de
construo vai ser til quando um componente precisa ser corrigido ou
atualizado ou quando outra pessoa suposto para assumir o
projeto.
Obteno BuildRootBuildroot releases so feitos aproximadamente a
cada 3 meses. Git acesso direto e dirio instantneos tambm esto
disponveis, se voc quiser borda mais sangramento. Lanamentos esto
disponveis em http://buildroot.net/downloads/ . O ltimo snapshot
est sempre disponvel em
http://buildroot.net/downloads/snapshots/buildrootsnapshot.tar.bz2
e instantneos anteriores tambm esto disponveis no
http://buildroot.net/downloads/snapshots/ . Para fazer o download
BuildRoot usando Git, voc pode simplesmente seguir as regras
descritas no "Acessando Git" pgina ( http://buildroot.net/git.html
) do site BuildRoot ( http://buildroot.net ). Para os impacientes,
aqui vai uma receita rpida:$ Git clone git: / / git.buildroot.net /
buildroot
Usando BuildRootBuildroot tem uma boa ferramenta de configurao
semelhante que voc pode encontrar no kernel do Linux (
http://www.kernel.org/ ) ou em Busybox ( http://www.busybox.org/ ).
Note que voc pode (e deve) construir tudo como um usurio normal. No
h necessidade de ser root para configurar e usar BuildRoot. O
primeiro passo executar o assistente de configurao:$ Make
menuconfig
para executar o configurador baseado em curses, ou$ Make
xconfig
ou
$ Make gconfig
para executar o Qt ou GTK baseado configuradores. Todos estes
"make" comandos precisar construir um utilitrio de configurao,
assim voc pode precisar instalar o "desenvolvimento" pacotes para
as bibliotecas relevantes utilizados pelos utilitrios de
configurao. Em Debian-like sistemas, o libncurses5-dev pacote
necessrio usar a interface menuconfig, libqt4-dev necessrio para
usar a interface xconfig, e libglib2.0-dev, libgtk2.0-dev and
libglade2-dev so necessrios para usar a interface gconfig. Para
cada entrada do menu na ferramenta de configurao, voc pode
encontrar ajuda associado que descreve a finalidade da entrada.
Depois que tudo estiver configurado, a ferramenta de configurao
gera um .config arquivo que contm a descrio de sua configurao. Ele
ser usado pela Makefiles para fazer o que necessrio. Vamos l:$
Make
Voc nunca deve usar make -jN com BuildRoot: ele no suporta mais
alto nvel paralelo fazer. Em vez disso, use o BR2_JLEVEL opo para
dizer BuildRoot para executar cada compilao pacote com make -jN .
Este comando geralmente execute os seguintes passos: Baixar
arquivos de origem (conforme necessrio) Configurar, construir e
instalar a compilao cruzada toolchain se um conjunto de ferramentas
interno usado, ou importar um toolchain se um toolchain externo
utilizado Construir / instalar pacotes alvo selecionado Construir
uma imagem de kernel, se selecionado Construir uma imagem do
bootloader, se selecionado Criar um sistema de arquivos raiz em
formatos selecionados Buildroot sada armazenada em um nico
diretrio, output/ . Este diretrio contm vrios subdiretrios: images/
onde todas as imagens (imagem do kernel bootloader, e as imagens do
sistema de arquivos raiz) so armazenados. build/ onde todos os
componentes, exceto para o toolchain compilao cruzada so construdos
(isso inclui ferramentas necessrias para executar BuildRoot no host
e pacotes compilados para o alvo). O build/ diretrio contm um
subdiretrio para cada um desses componentes. staging/ que contm uma
hierarquia semelhante a uma hierarquia do sistema de arquivos raiz.
Este diretrio contm a instalao da compilao cruzada toolchain e
todos os pacotes userspace selecionados para o alvo. No entanto,
este diretrio no se destina a ser o sistema de arquivos raiz para o
alvo: ele contm uma grande quantidade de arquivos de
desenvolvimento, unstripped binrios e bibliotecas que a tornam
muito grandes para um sistema embarcado. Estes arquivos de
desenvolvimento so usados para compilar as bibliotecas e aplicaes
para o destino que dependem de outras bibliotecas. target/ que
contm quase o sistema de arquivos raiz para o alvo: tudo que
necessrio est presente, exceto os arquivos de dispositivo em /dev/
(BuildRoot no pode cri-los porque BuildRoot no executado como root
e no deseja executar como root) . Portanto, este diretrio no deve
ser usado em seu alvo. Em vez disso, voc deve usar uma das imagens
construdas no images/ diretrio. Se voc precisa de uma imagem
extrada do sistema de
arquivos raiz para a inicializao atravs de NFS, em seguida, usar
a imagem gerada em tarball images/ e extra-lo como root. Em
comparao com staging/ , target/ contm apenas os arquivos e
bibliotecas necessrios para executar os aplicativos de destino
selecionado: os arquivos de desenvolvimento (cabealhos, etc) no
esto presentes, a menos que o development files in target
filesystem opo for selecionada. host/ contm a instalao de
ferramentas de compilao para o host que so necessrios para a
correcta execuo das BuildRoot, incluindo o toolchain compilao
cruzada. toolchain/ contm os diretrios de construo para os diversos
componentes do toolchain compilao cruzada.
Constri off-lineSe voc pretende fazer uma compilao offline e s
quero baixar todas as fontes que voc selecionou anteriormente no
configurador (menuconfig, ou xconfig gconfig), assuntos de ento:$
Make fonte
Agora voc pode desconectar ou copiar o contedo do seu dl
diretrio para a construo de host.
Construo de out-of-rvoreBuildroot suporta a construo de rvore
com uma sintaxe semelhante ao kernel Linux. Para us-lo, adicione O
= linha de comando make:$ Make O = / tmp / build
Ou:$ Cd / tmp / build; fazer O caminho = $ PWD-C / para /
buildroot
Todos os arquivos de sada sero localizados sob /tmp/build . Ao
usar out-of-rvore constri, o BuildRoot .config ficheiros e
temporrias tambm so armazenados no diretrio de sada. Isto significa
que voc pode seguramente executar vrios builds em paralelo com a
rvore mesma fonte, desde que use diretrios de sada nica. Para
facilidade de uso, BuildRoot gera um wrapper Makefile no diretrio
de sada - Assim, aps a primeira execuo, voc no precisa mais passar
O=.. e -C .. , basta executar (no diretrio de sada):$ Make
Variveis de ambienteBuildroot tambm homenageia algumas variveis
de ambiente, quando eles so passados para make ou no meio ambiente:
HOSTCXX , o host C + + compilador para usar HOSTCC , o anfitrio do
compilador C para uso UCLIBC_CONFIG_FILE= , caminho para o arquivo
de configurao uClibc, usado para compilar uClibc, se um conjunto de
ferramentas interna est sendo construda BUSYBOX_CONFIG_FILE= ,
caminho para o arquivo de configurao Busybox BUILDROOT_DL_DIR para
substituir o diretrio que armazena BuildRoot / recupera
arquivos baixados Um exemplo que usa arquivos de configurao
localizado no diretrio principal e em sua $ HOME:$ Make
UCLIBC_CONFIG_FILE = uClibc.config BUSYBOX_CONFIG_FILE = $ HOME /
bb.config
Se voc quiser usar um compilador diferente do padro gcc ou g++
para a construo de helperbinrios em seu anfitrio, em seguida,
fazer$ Make HOSTCXX = g + + CABEA-4.3-HOSTCC = gcc-4.3-HEAD
Personalizar o sistema de arquivos gerados alvoExistem algumas
maneiras de personalizar o sistema de arquivos de destino
resultante: Personalizar o sistema de arquivos alvo diretamente e
reconstruir a imagem. O sistema de arquivos-alvo est disponvel sob
output/target/ . Voc pode simplesmente fazer as alteraes aqui e
execute make depois - o que ir reconstruir a imagem do sistema de
arquivos-alvo. Este mtodo permite que voc faa alguma coisa para o
sistema de arquivos de destino, mas se voc decidir reconstruir
completamente a sua toolchain e ferramentas, estas alteraes sero
perdidas. Crie seu esqueleto prpria meta. Voc pode comear com o
esqueleto padro disponvel sob fs/skeleton e depois personaliz-lo
para atender s suas necessidades. O BR2_ROOTFS_SKELETON_CUSTOM e
BR2_ROOTFS_SKELETON_CUSTOM_PATH permitir que voc especifique o
local de seu esqueleto personalizado. Em tempo de compilao, o
contedo do esqueleto so copiados para a sada / target antes de
qualquer instalao do pacote. Na configurao BuildRoot, voc pode
especificar o caminho para um script de ps-build, que chamado
depois BuildRoot constri todo o software selecionado, mas antes que
os pacotes so montados rootfs. O destino da pasta raiz dado como o
primeiro argumento para o script, e esse script pode ser usado para
programas de cpia, os dados estticos ou qualquer outro arquivo
necessrio para seu sistema de arquivos-alvo. Voc deve, no entanto,
usar esse recurso com cuidado. Sempre que voc achar que um
determinado pacote gera arquivos errados ou desnecessrios, voc deve
corrigir esse pacote ao invs de trabalhar em torno dele com um
script de limpeza ps-compilao. Um pacote especial, personalizar,
armazenada em package/customize podem ser usados. Voc pode colocar
todos os arquivos que voc deseja ver no sistema de arquivos raiz no
objectivo final package/customize/source , e ento permitir que este
pacote especial no sistema de configurao.
Personalizando a configurao BusyboxBusybox muito configurvel, e
voc pode querer personaliz-lo. Voc pode seguir estes passos simples
para fazer isso. Este mtodo no ideal, mas simples e funciona: 1.
Fazer uma compilao inicial de BuildRoot, com busybox, sem tentar
personaliz-lo. 2. Invoke make busybox-menuconfig . A ferramenta de
configurao aparece agradvel, e voc pode personalizar tudo. 3.
Executar a compilao de BuildRoot novamente. Caso contrrio, voc pode
simplesmente mudar o package/busybox/busybox.config arquivo, se voc
sabe as opes que pretende alterar, sem usar a ferramenta de
configurao.
Se voc quiser usar um arquivo de configurao existentes para
busybox, ento consulte a seco variveis de ambiente .
Personalizando a configurao uClibcAssim como BusyBox , uClibc
oferece uma srie de opes de configurao. Eles permitem que voc
selecione vrias funcionalidades dependendo de suas necessidades e
limitaes. A maneira mais fcil de modificar a configurao do uClibc
seguir estes passos: 1. Fazer uma compilao inicial de BuildRoot sem
tentar personalizar uClibc. 2. Invoke make uclibc-menuconfig . O
assistente de configurao agradvel, semelhante ao usado no kernel do
Linux ou BuildRoot, aparece. Faa as alteraes de configurao conforme
apropriado. 3. Copie o $(O)/toolchain/uclibc-VERSION/.config
arquivo para um lugar diferente (como
toolchain/uClibc/uClibc-myconfig.config , ou
board/mymanufacturer/myboard/uClibc.config ) e ajustar a configurao
uClibc (configurao opo BR2_UCLIBC_CONFIG ) para usar essa
configurao em vez do padro. 4. Executar a compilao de BuildRoot
novamente. Caso contrrio, voc pode simplesmente mudar
toolchain/uClibc/uClibc.config , sem correr o assistente de
configurao. Se voc quiser usar um arquivo de configurao existentes
para uClibc, ento consulte a seco variveis de ambiente .
Personalizando a configurao do kernel LinuxA configurao do
kernel Linux pode ser personalizado como BusyBox e uClibc usando
make linux-menuconfig . Certifique-se de ter habilitado o kernel
construir no make menuconfig primeiro. Uma vez feito isso, execute
make a (re) construir tudo. Se voc quiser usar um arquivo de
configurao existentes para Linux, ento consulte a seco variveis de
ambiente .
Compreenso de como reconstruir pacotesUma das perguntas mais
comuns feitas pelos usurios BuildRoot como reconstruir um
determinado pacote ou como remover um pacote sem reconstruir tudo
do zero. Remoo de um pacote est atualmente no suportada pelo
BuildRoot sem reconstruo do zero. Isto porque BuildRoot no
acompanhar o que o pacote instala arquivos na output/staging e
output/target diretrios. No entanto, a implementao de remoo do
pacote limpa est na TODO list dos desenvolvedores BuildRoot. A
maneira mais fcil reconstruir um nico pacote a partir do zero
remover o diretrio construir em output/build . Buildroot ento
re-extract, re-configurar, re-re-compilar e instalar este pacote a
partir do zero. No entanto, se voc no quiser reconstruir o pacote
completamente do zero, uma melhor compreenso dos internals
BuildRoot necessrio. Internamente, para acompanhar os passos que tm
sido feitos e que h ainda muito a ser feito, BuildRoot mantm
arquivos de selo (arquivos vazios que apenas dizer se essa ou
aquela ao tem sido feito). O problema que esses arquivos no so
uniformemente selo chamado e manipulados pelos pacotes diferentes,
por isso alguma compreenso do pacote especial necessria.
Para pacotes contando com infra-estruturas BuildRoot pacotes
(veja nesta seo para mais detalhes), os arquivos de selo so
relevantes: output/build/packagename-version/.stamp_configured . Se
removido, BuildRoot ir acionar a recompilao do pacote a partir da
etapa de configurao (execuo de ./configure ).
output/build/packagename-version/.stamp_built . Se removido,
BuildRoot ir acionar a recompilao do pacote da etapa de compilao
(execuo de make ). Para outros pacotes, uma anlise do arquivo
package.mk especfico necessrio. Por exemplo, o Makefile zlib
costumava olhar assim (antes de ser convertido para a
infra-estrutura pacote genrico):$ (ZLIB_DIR) / configurados:. $
(ZLIB_DIR) / corrigido. (Cd $ (ZLIB_DIR); rm-rf config.cache; \
[...] ) toque $ @ $ (ZLIB_DIR) / libz.a: $ (ZLIB_DIR) /
configurado. $ (MAKE)-C $ (ZLIB_DIR) todos os libz.a touch-c $
@
Se voc deseja acionar a reconfigurao, voc precisa remover
output/build/zlibversion/.configured . Se voc deseja acionar apenas
a recompilao, voc precisa remover output/build/zlib-version/libz.a
. Note-se que a maioria dos pacotes, se no todos, sero
progressivamente transferidos ao longo da infra-estrutura genrica
ou autotools, tornando muito mais fcil para reconstruir pacotes
individuais.
Como funciona BuildRootComo mencionado acima, BuildRoot
basicamente um conjunto de Makefiles que o download, configurar e
compilar o software com as opes corretas. Ele tambm inclui patches
para vrios pacotes de software - principalmente os envolvidos na
cadeia de ferramenta cross-compilao ( gcc , binutils e uClibc ). H,
basicamente, um Makefile por pacote de software, e eles so nomeados
com o .mk extenso. Makefiles so divididos em trs seces principais:
toolchain (no toolchain/ diretrio) contm os arquivos Makefiles e
associados para todos os softwares relacionados com o toolchain
compilao cruzada: binutils , gcc , gdb , kernel-headers e uClibc .
pacote (no package/ diretrio) contm os arquivos Makefiles e
associados para todas as ferramentas do espao do usurio que
BuildRoot pode compilar e adicionar ao sistema de arquivos raiz de
destino. H um sub-diretrio por ferramenta. alvo (no target
diretrio) contm os arquivos Makefiles e associados para software
relacionado gerao da imagem do sistema de arquivos raiz meta.
Quatro tipos de sistemas de arquivos so suportados: ext2, jffs2,
cramfs e squashfs. Para cada um deles h um subdiretrio com os
arquivos necessrios. H tambm um default/ diretrio que contm o
esqueleto do sistema de arquivos-alvo. Cada diretrio contm pelo
menos dois arquivos: something.mk o Makefile que downloads,
configura, compila e instala o pacote de something .
Config.in uma parte do arquivo de configurao ferramenta de
descrio. Ele descreve as opes relacionadas com o pacote. O Makefile
principal executa as seguintes etapas (uma vez que a configurao
feita): 1. Criar todos os diretrios de sada: staging , target ,
build , stamps , etc no diretrio de sada ( output/ por padro, outro
valor pode ser especificado usando O= ) 2. Gerar todas as metas
traadas na BASE_TARGETS varivel. Quando um toolchain interna usada,
isto significa gerar a compilao cruzada toolchain. Quando um
toolchain externa usada, isto significa verificar as caractersticas
do conjunto de ferramentas externas e import-la no ambiente
BuildRoot. 3. Gerar todas as metas traadas na TARGETS varivel. Esta
varivel preenchida por Makefiles todos os componentes individuais
". Gerando essas metas ir desencadear a compilao dos pacotes
userspace (bibliotecas, programas), o kernel, o bootloader ea gerao
das imagens do sistema de arquivos raiz, dependendo da
configurao.
Criar o seu prprio suporte de placaCriar o seu prprio suporte de
placa em BuildRoot permite que os usurios de uma plataforma de
hardware especfico para facilmente construir um sistema que
conhecido para o trabalho. Para isso, voc precisa criar uma
configurao BuildRoot normal que constri um sistema bsico para o
hardware: kernel, toolchain, bootloader, sistema de arquivos e um
userspace simples Busybox-only. Nenhum pacote especfico deve ser
selecionado: a configurao deve ser o mnimo possvel, e s deve
construir um sistema Busybox fundamentais de trabalho para a
plataforma alvo. Pode, claro, usar as configuraes mais complicadas
para os seus projetos internos, mas o projeto s ir integrar
BuildRoot configuraes da placa bsica. Isto porque selees de pacotes
so altamente especfico do aplicativo. Depois de ter uma configurao
conhecida de trabalho, executar make savedefconfig . Isso ir gerar
um mnimo de defconfig arquivo na raiz da rvore fonte BuildRoot.
Mova este arquivo para a configs/ diretrio e renome-lo
MYBOARD_defconfig . Recomenda-se usar o mximo possvel verses
originais do kernel do Linux e gerenciadores de partida, e para
utilizar, tanto quanto possvel kernel padro e configuraes
bootloader. Se eles esto incorretas para sua plataforma, ns
encorajamos voc a enviar correes para os projetos correspondentes a
montante. No entanto, nesse meio tempo, voc pode querer armazenar
kernel ou bootloader configurao ou patches especficos para sua
plataforma de destino. Para fazer isso, crie um diretrio
board/MANUFACTURER e um subdiretrio board/MANUFACTURER/BOARDNAME
(aps a substituio, claro, fabricante e BOARDNAME com os valores
apropriados, em letras minsculas). Voc pode ento armazenar seus
patches e configuraes nestes diretrios, e referenci-los a partir da
configurao BuildRoot principal.
Usando o gerado BuildRoot toolchain foraVoc pode querer
compilar, para o seu alvo, os seus prprios programas ou outros
softwares que no so embalados em BuildRoot. Para fazer isso, voc
pode usar o toolchain que foi gerado pelo BuildRoot. O toolchain
gerada pelo BuildRoot est localizado por padro na output/host/ . A
maneira mais simples para us-lo adicionar output/host/usr/bin/ para
a varivel de ambiente PATH e depois de usar ARCH-linux-gcc ,
ARCH-linux-objdump , ARCH-linux-ld , etc possvel mudar o local da
toolchain - mas ento --sysroot deve ser passado sempre que o
compilador chamado a dizer onde as bibliotecas e arquivos de
cabealho so. Tambm possvel gerar o BuildRoot toolchain em um
diretrio que no seja output/host usando o Build options -> Host
dir opo. Isto pode ser til se o toolchain devem ser compartilhados
com outros usurios.
Usando ccache em BuildRootccache um cache do compilador. Ele
armazena os arquivos objeto resultante de cada processo de
compilao, e capaz de pular compilao futuro do mesmo arquivo de
origem (com mesmo compilador e argumentos mesmo) usando os arquivos
pr-existentes objeto. Ao fazer constri quase idnticos a partir do
zero vrias vezes, ele pode muito bem acelerar o processo de
construo. ccache suporte integrado em BuildRoot. Voc apenas tem que
habilitar Enable compiler cache em Build options . Isso ir criar
automaticamente ccache e us-lo para cada host e compilao alvo. O
cache est localizada em $HOME/.buildroot-ccache . Ela armazenada
fora do diretrio de sada BuildRoot para que ele possa ser
compartilhado por constri BuildRoot separado. Se voc quer se livrar
do cache, basta remover este diretrio. Voc pode obter estatsticas
sobre o cache (seu tamanho, nmero de hits, misses, etc), executando
make ccache-stats .
Localizao de pacotes baixadosPode ser til saber que o tarballs
diferentes que so baixados pela Makefiles so todos armazenados no
DL_DIR que por padro o dl diretrio. til, por exemplo, se voc quiser
manter uma verso completa do BuildRoot que conhecido por trabalhar
com o tarballs associados. Isto permitir que voc para regenerar o
toolchain eo sistema de arquivos-alvo com exatamente as mesmas
verses. Se voc mantm vrias rvores BuildRoot, talvez seja melhor ter
um local de download compartilhada. Isso pode ser acessado atravs
da criao de um link simblico do dl diretrio para o local de
download compartilhada:$ Ln-s compartilhada> baixar location>
dl
Outra forma de acessar um local de download compartilhada criar
o BUILDROOT_DL_DIR varivel de ambiente. Se isso for definido, ento
o valor da DL_DIR no projeto substitudo. A seguinte linha deve ser
adicionada ao "~/.bashrc" .$ Export BUILDROOT_DL_DIR
compartilhada> location> baixar
Usando um conjunto de ferramentas externasUsando um conjunto de
ferramentas j existentes til, por diferentes razes: voc j tem um
conjunto de ferramentas que conhecido por trabalhar para a sua CPU
especfica voc quiser acelerar o processo de construo BuildRoot
saltando a longa pea construir toolchain o recurso de gerao de
toolchain BuildRoot no suficientemente flexvel para voc (por
exemplo, se voc precisa gerar um sistema com glibc, em vez de
uClibc) Buildroot suporta o uso de toolchains existentes atravs de
um mecanismo chamado externo toolchain. O mecanismo externo
toolchain est habilitado no Toolchain menu, selecionando
External toolchain no Toolchain type . Ento, voc tem trs solues
para usar um toolchain externo: Use um perfil externo predefinidos
toolchain, e deixe BuildRoot download, extrair e instalar o
toolchain. Buildroot j sabe sobre um toolchains CodeSourcery poucos
para ARM, PowerPC, MIPS e SuperH. Basta selecionar o perfil
toolchain no Toolchain com os disponveis. Esta definitivamente a
soluo mais fcil. Usar um perfil pr-definido toolchain externa, mas
em vez de ter BuildRoot baixar e extrair o toolchain, voc pode
dizer BuildRoot onde seu toolchain j est instalado em seu sistema.
Basta selecionar o perfil toolchain no Toolchain com os disponveis,
desmarque Download toolchain automatically , e preencher o
Toolchain path de entrada de texto com o caminho para o
cross-compilar toolchain. Use um conjunto de ferramentas totalmente
personalizadas externo. Isto particularmente til para toolchains
gerados usando Crosstool NG. Para fazer isso, selecione o Custom
toolchain soluo no Toolchain lista. necessrio preencher o Toolchain
path , Toolchain prefix e External toolchain C library opes. Ento,
voc tem que dizer o que o seu BuildRoot externa suporta toolchain.
Se o seu toolchain externa usa a biblioteca glibc, voc s tem que
dizer se o seu suporta toolchain C + + ou no. Se o seu toolchain
externa usa a biblioteca uClibc, ento voc tem que dizer se ele
suporta BuildRoot largefile, IPv6, RPC, larga-char locale, programa
de invocao, tpicos e C + +. No incio da execuo, BuildRoot vai dizer
se as opes selecionadas no corresponder configurao toolchain. Nosso
apoio externo toolchain foi testado com toolchains de CodeSourcery,
toolchains gerada pelo Crosstool-NG , e toolchains gerada pelo
BuildRoot si. Em geral, todos toolchains que suportam o recurso
sysroot deve funcionar. Se no for, no hesite em entrar em contato
com os desenvolvedores. No apoiamos toolchains do ELDK de Denx ,
por duas razes: O ELDK no contm um toolchain puro (ou seja, apenas
o compilador, binutils, a C e C + + bibliotecas), mas um conjunto
de ferramentas que vem com um conjunto muito grande de
pr-compilados bibliotecas e programas. Portanto, BuildRoot no pode
importar o sysroot do toolchain, pois poderia conter centenas de
megabytes de pr-compilados bibliotecas que so normalmente
construdas por BuildRoot. O toolchains ELDK ter um mecanismo
completamente fora do padro personalizado para lidar com mltiplas
variantes biblioteca. Em vez de usar o padro GCC mecanismo
multilib, o ELDK ARM diferentes usos links simblicos para o
compilador para diferenciar entre as variantes biblioteca (por ARM
macio-float e ARM VFP), eo PowerPC ELDK compilador usa uma
CROSS_COMPILE varivel de ambiente. Este comportamento no-padro
dificulta o apoio ELDK em BuildRoot. Ns tambm no suportam o uso da
distribuio toolchain (ou seja, a biblioteca do gcc / binutils / C
instalado pela sua distribuio) como o conjunto de ferramentas para
criar software para o destino. Isso ocorre porque sua distribuio
toolchain no um "puro" toolchain (ou seja, apenas com o C / C + +
biblioteca), por isso no podemos import-lo corretamente no
BuildRoot construir ambiente. Assim, mesmo se voc est construindo
um sistema para um alvo x86 ou x86_64, voc tem que gerar uma
compilao cruzada toolchain com BuildRoot ou Crosstool NG.
Adicionando novos pacotes BuildRootEsta seo aborda como novos
pacotes (bibliotecas userspace ou aplicaes) podem ser integrados em
BuildRoot. Ele tambm mostra como os pacotes existentes so
integrados, o que necessrio para a correo de problemas ou ajuste
sua configurao.
Diretrio do pacote Config.in arquivo O .mk arquivo Makefile para
pacotes genricos: tutorial Makefile para pacotes genricos:
referncia Makefile para autotools baseado pacotes: tutorial
Makefile para autotools baseado pacotes: de referncia Makefile para
CMake baseado pacotes: tutorial Makefile para CMake baseado
pacotes: de referncia Manual Makefile: tutorial Gettext integrao e
interao com pacotes
Diretrio do pacoteAntes de mais nada, crie um diretrio sob o
package software para o seu diretrio, por exemplo libfoo . Alguns
pacotes foram agrupados por tema em um sub-diretrio: multimedia ,
java , x11r7 , e games . Se o seu pacote se encaixa em uma dessas
categorias, ento criar o seu diretrio do pacote nestes.
Config.in arquivoEm seguida, crie um arquivo chamado Config.in .
Este arquivo conter as descries opo relacionada com a nossa libfoo
software que ser usado e exibido na ferramenta de configurao. Deve
conter, basicamente:configurao BR2_PACKAGE_LIBFOO bool "libfoo"
ajuda Este um comentrio que explica o que libfoo.
http://foosoftware.org/libfoo/
Claro, voc pode adicionar outras opes para configurar as coisas
em particular no seu software. Voc pode olhar para exemplos em
outros pacotes. A sintaxe do arquivo Config.in o mesmo que aquele
para o arquivo KConfig kernel. A documentao para esta sintaxe est
disponvel em
http://lxr.free-electrons.com/source/Documentation/kbuild/kconfig-language.txt
Finalmente, voc tem que adicionar seu novo libfoo/Config.in de
package/Config.in (ou em uma categoria subdiretrio se voc decidiu
colocar o pacote em uma das categorias existentes). Os ficheiros
includos existem classificados em ordem alfabtica por categoria e
no so supostamente para conter qualquer coisa, mas o nome simples
do pacote."pacote / libfoo / Config.in" fonte
O .mk arquivoFinalmente, aqui est a parte mais difcil. Crie um
arquivo chamado libfoo.mk . Ele descreve como o pacote deve ser
baixado, configurado, fabricados, instalados, etc Dependendo do
tipo de pacote, o .mk arquivo deve ser escrito de uma maneira
diferente, utilizando diferentes infra-estruturas: Makefiles para
pacotes genricos (no usando autotools): Estes so baseados em
uma
infra-estrutura semelhante ao usado para autotools baseado em
pacotes, mas requer um pouco mais trabalho do desenvolvedor. Eles
especificar o que deve ser feito para a configurao, compilao,
instalao e limpeza do pacote. Esta infra-estrutura deve ser
utilizado para todos os pacotes que no usam o autotools como seu
sistema de compilao. No futuro, outras infra-estruturas
especializadas poderiam ser escritas para outros sistemas de
construo. Ns cobri-los atravs de um tutorial e uma referncia .
Makefiles para autotools baseado software (autoconf, automake,
etc): Ns fornecemos uma infra-estrutura dedicada para tais pacotes,
pois autotools um sistema de construo muito comum. Esta
infra-estrutura deve ser utilizado para novos pacotes que dependem
do autotools como seu sistema de compilao. Ns cobri-los atravs de
um tutorial e uma referncia . Manual Makefiles: Estes so atualmente
obsoletos, e nenhum novo manual de Makefiles deve ser adicionada.
No entanto, uma vez que ainda h muitos deles na rvore, ns mantlos
documentado em um tutorial . Makefile para pacotes genricos:
tutorial01: ################################################
############# 02: # 03: # libfoo 04: # 05:
################################################ ############# 06:
LIBFOO_VERSION = 1,0 07: LIBFOO_SOURCE = libfoo-$ (LIBFOO_VERSION)
tar.gz. 08: LIBFOO_SITE = http://www.foosoftware.org/download 09:
LIBFOO_INSTALL_STAGING = YES 10: LIBFOO_DEPENDENCIES = host-libaaa
libbbb 11: 12: define LIBFOO_BUILD_CMDS 13: $ (MAKE) CC = $
(TARGET_CC) LD = $ (TARGET_LD)-C $ (@ D) todos os 14: ENDEF 15: 16:
define LIBFOO_INSTALL_STAGING_CMDS 17: $ (INSTALL)-D-m 0755 $ (@ D)
/ libfoo.a $ (STAGING_DIR) / usr / lib / libfoo.a 18: $
(INSTALL)-D-m 0644 $ (@ D) / foo.h $ (STAGING_DIR) / usr / include
/ foo.h 19: $ (INSTALL)-D-m 0755 $ (@ D) / libfoo.so * $
(STAGING_DIR) / usr / lib 20: ENDEF 21: 22: define
LIBFOO_INSTALL_TARGET_CMDS 23: $ (INSTALL)-D-m 0755 $ (@ D) /
libfoo.so * $ (target_dir) / usr / lib 24: $ (INSTALL)-d-m 0755 $
(target_dir) / etc / foo.d 25: ENDEF 26: 27: $ (eval $ (GENTARGETS
chamada, pacote, libfoo))
O Makefile comea na linha 6-8, com informaes de metadados: a
verso do pacote ( LIBFOO_VERSION ), o nome do tarball contendo o
pacote ( LIBFOO_SOURCE ) eo local de Internet em que o tarball pode
ser baixado ( LIBFOO_SITE ). Todas as variveis devem comear com o
mesmo prefixo, LIBFOO_ neste caso. Este prefixo sempre a verso
maiscula do nome do pacote (veja abaixo para entender onde o nome
do pacote definido). Na linha 9, especificamos que este pacote quer
instalar algo para o espao de teste. Isso muitas vezes necessrio
para as bibliotecas, uma vez que deve instalar arquivos de cabealho
e arquivos de desenvolvimento outro no espao de teste. Isso ir
garantir que os comandos listados na
LIBFOO_INSTALL_STAGING_CMDS varivel ser executado. Na linha 10,
ns especificar a lista de dependncias este pacote depende. Essas
dependncias so listados em termos de nomes em minsculo pacote, que
pode ser pacotes para o destino (sem o host- prefixo) ou pacotes
para o host (com o host- ) prefixo). Buildroot ir garantir que
todos estes pacotes so construdos e instalados antes do pacote
atual inicia a sua configurao. O resto do Makefile define o que
deve ser feito em diferentes etapas da compilao do pacote de
configurao e instalao. LIBFOO_BUILD_CMDS diz que passos devem ser
realizados para construir o pacote. LIBFOO_INSTALL_STAGING_CMDS diz
que medidas devem ser executadas para instalar o pacote no espao de
preparao . LIBFOO_INSTALL_TARGET_CMDS diz que medidas devem ser
executadas para instalar o pacote no espao-alvo. Todos estes passos
dependem do $(@D) varivel, que contm o diretrio onde o cdigo-fonte
do pacote foi extrado. Finalmente, na linha 27, chamamos o
GENTARGETS que gera, de acordo com as variveis definidas
anteriormente, todo o cdigo Makefile necessrio para tornar o seu
pacote de trabalho. Makefile para pacotes genricos: referncia O
GENTARGETS macro recebe trs argumentos: O primeiro argumento o
prefixo diretrio do pacote. Se o seu pacote est no package/libfoo ,
o prefixo de diretrio package . Se o seu pacote est no
package/editors/foo , o prefixo de diretrio deve ser
package/editors . O segundo argumento o nome do pacote escrito em
minscula. Ele deve corresponder ao prefixo das variveis no .mk
arquivo e deve coincidir com o nome da opo de configurao no
Config.in arquivo. Por exemplo, se o nome do pacote libfoo , ento
as variveis no .mk arquivo deve comear com LIBFOO_ ea opo de
configurao no Config.in arquivo deve ser BR2_PACKAGE_LIBFOO . O
terceiro argumento opcional. Ele pode ser usado para dizer se o
pacote um pacote de destino (cross-compilados para o destino) ou um
pacote de host (nativamente compilados para o host). Se no for
especificado, presume-se que um pacote de destino. Veja os detalhes
abaixo. Para um determinado pacote, em um nico .mk arquivo, possvel
chamar GENTARGETS duas vezes, uma para criar as regras para gerar
um pacote de destino e uma vez para criar as regras para gerar um
pacote de host:$ (Eval $ (GENTARGETS chamada, pacote, libfoo)) $
(Eval $ (GENTARGETS chamada, pacote, libfoo, host))
Isso pode ser til se a compilao do pacote de destino exige
algumas ferramentas para ser instalado no host. Se o nome do pacote
libfoo , ento o nome do pacote para o alvo tambm libfoo , enquanto
o nome do pacote para o host host-libfoo . Estes nomes devem ser
utilizados nas variveis dependncias de outros pacotes, se eles
dependem libfoo ou host-libfoo . A chamada para o GENTARGETS macro
deve estar no final do .mk arquivo, depois de todas as definies de
variveis. Para o pacote de destino, o GENTARGETS utiliza as
variveis definidas pelo arquivo mk e prefixados pelo nome do pacote
minsculo:. LIBFOO_* . Para o pacote do host, ele usa o
HOST_LIBFOO_* . Para algumas variveis, se o HOST_LIBFOO_ varivel
prefixado no existe, a infra-estrutura pacote usa a varivel
correspondente prefixado por LIBFOO_ . Isto feito para as variveis
que possam ter o mesmo valor para ambos alvo e pacotes de host.
Veja os detalhes abaixo. A lista de variveis que podem ser
definidos em um .mk arquivo para dar informaes de
metadados (assumindo que o nome do pacote libfoo ):
LIBFOO_VERSION , obrigatria, deve conter a verso do pacote. Note
que se HOST_LIBFOO_VERSION no existe, assumido como sendo o mesmo
que LIBFOO_VERSION . Tambm pode ser um Subversion ou Git sucursal
ou tag, para pacotes que so buscadas diretamente de seu sistema de
controle de reviso. Exemplo: LIBFOO_VERSION = 0.1.2 LIBFOO_SOURCE
pode conter o nome do tarball do pacote. Se HOST_LIBFOO_SOURCE no
especificado, o padro LIBFOO_VERSION . Se nenhum for especificado,
ento o valor assumido como sendo
packagename-$(LIBFOO_VERSION).tar.gz . Exemplo: LIBFOO_SOURCE =
foobar-$(LIBFOO_VERSION).tar.bz2 LIBFOO_PATCH pode conter o nome de
um patch, que ser baixado a partir do mesmo local do tarball
indicado no LIBFOO_SOURCE . Se HOST_LIBFOO_PATCH no especificado, o
padro LIBFOO_PATCH . Observe tambm que um outro mecanismo est
disponvel para corrigir um pacote: todos os arquivos da forma
packagenamepackageversion-description.patch presente no diretrio do
pacote dentro BuildRoot ser aplicada para o pacote aps a extrao.
LIBFOO_SITE pode conter a localizao do pacote de Internet. Ela pode
ser a localizao de HTTP ou FTP de um tarball, ou o URL de um
repositrio Git ou Subversion (veja LIBFOO_SITE_METHOD abaixo). Se
HOST_LIBFOO_SITE no especificado, o padro LIBFOO_SITE . Se nenhum
for especificado, ento o local considerado http://$$
(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/packa
gename . Exemplos: LIBFOO_SITE=http://www.libfoosoftware.org/libfoo
LIBFOO_SITE=http://svn.xiph.org/trunk/Tremor/ LIBFOO_SITE_METHOD
pode conter o mtodo para buscar o cdigo fonte do pacote. Ela pode
ser wget (para normal FTP / HTTP downloads de tarballs), svn , git
ou bzr . Quando no especificado, adivinhado a partir do URL dado em
LIBFOO_SITE : svn:// , git:// e bzr:// URLs ir utilizar o svn , git
e bzr mtodos, respectivamente. Todos os outros tipos de URL ir usar
o wget mtodo. Assim, por exemplo, no caso de um pacote cujo cdigo
fonte est disponvel atravs do repositrio no Subversion HTTP,
deve-se especifique LIBFOO_SITE_METHOD=svn . Para svn e git mtodos,
o que faz BuildRoot um checkout / clone do repositrio que ento
tarballed e armazenados no cache de download. Constri seguinte no
checkout / clone de novo, mas vai usar o tarball diretamente.
Quando HOST_LIBFOO_SITE_METHOD no for especificado, o padro o valor
de LIBFOO_SITE_METHOD . Veja package/multimedia/tremor/ para um
exemplo. LIBFOO_DEPENDENCIES lista as dependncias (em termos de
nome do pacote) que so necessrios para o pacote alvo atual para
compilar. Essas dependncias so garantidos para ser compilado e
instalado antes da configurao do pacote actual comea. De maneira
semelhante, HOST_LIBFOO_DEPENDENCIES listas a dependncia para o
pacote do host atual. LIBFOO_INSTALL_STAGING pode ser configurada
para YES ou NO (padro). Se definido como YES , ento os comandos no
LIBFOO_INSTALL_STAGING_CMDS variveis so executadas para instalar o
pacote para o diretrio teste. LIBFOO_INSTALL_TARGET pode ser
definida como YES (default) ou NO . Se definido como YES , ento os
comandos no LIBFOO_INSTALL_TARGET_CMDS variveis so executadas para
instalar o pacote para o diretrio de destino. A maneira recomendada
para definir essas variveis usar a seguinte sintaxe:LIBFOO_VERSION
= 2,32
Agora, as variveis que definem o que deve ser realizado em
diferentes etapas do processo de construo. LIBFOO_CONFIGURE_CMDS ,
usado para listar as aes a serem executadas para configurar o
pacote antes de sua compilao LIBFOO_BUILD_CMDS , usado para listar
as aes a serem executadas para compilar o pacote
HOST_LIBFOO_INSTALL_CMDS , usado para listar as aes a serem
executadas para instalar o pacote, quando o pacote um pacote de
host. O pacote deve instalar seus arquivos para o diretrio dado por
$(HOST_DIR) . Todos os arquivos, incluindo arquivos de
desenvolvimento tais como cabealhos devem ser instalados, uma vez
que outros pacotes podem ser compilados, em cima do pacote.
LIBFOO_INSTALL_TARGET_CMDS , usado para listar as aes a serem
executadas para instalar o pacote para o diretrio de destino,
quando o pacote um pacote de destino. O pacote deve instalar seus
arquivos para o diretrio dado por $(TARGET_DIR) . Apenas os
arquivos necessrios para a documentao e execuo do pacote deve ser
instalado. Arquivos de cabealho no deve ser instalado, eles sero
copiados para o alvo, se a development files in target filesystem
opo for selecionada. LIBFOO_INSTALL_STAGING_CMDS , usado para
listar as aes a serem executadas para instalar o pacote para o
diretrio provisrio, quando o pacote um pacote de destino. O pacote
deve instalar seus arquivos para o diretrio dado por $(STAGING_DIR)
. Todos os arquivos de desenvolvimento deve ser instalado, pois
eles podem ser necessrios para compilar outros pacotes.
LIBFOO_CLEAN_CMDS , usado para listar as aes a executar para limpar
o diretrio de compilao do pacote. LIBFOO_UNINSTALL_TARGET_CMDS ,
usado para listar as aes para desinstalar o pacote do alvo diretrio
$(TARGET_DIR) LIBFOO_UNINSTALL_STAGING_CMDS , usado para listar as
aes para desinstalar o pacote do teste diretrio $(STAGING_DIR) . A
maneira preferida para definir essas variveis :definir
LIBFOO_CONFIGURE_CMDS aco 1 aco 2 aco 3 ENDEF
Nas definies de ao, voc pode usar as seguintes variveis: $(@D) ,
que contm o diretrio em que o cdigo fonte do pacote foi
descompactado. $(TARGET_CC) , $(TARGET_LD) , etc para obter o alvo
compilao cruzada utilitrios $(TARGET_CROSS) para obter o prefixo de
compilao cruzada toolchain Claro que o $(HOST_DIR) , $(STAGING_DIR)
e $(TARGET_DIR) variveis para instalar os pacotes corretamente.
O ltimo recurso da infra-estrutura genrica a capacidade de
adicionar os ganchos. Estes definem novas aces a realizar, aps as
etapas existentes. A maioria dos ganchos no so muito teis para os
pacotes genricos, desde o .mk arquivo j tem total controle sobre as
aes realizadas em cada etapa da construo do pacote. Os ganchos so
mais teis para pacotes usando a infra-estrutura autotools descrito
abaixo. No entanto, uma vez que so fornecidas pela infra-estrutura
genrica, que esto documentadas aqui. A exceo
LIBFOO_POST_PATCH_HOOKS . Remendar o pacote no definido pelo
usurio, de modo LIBFOO_POST_PATCH_HOOKS ser userful para pacotes
genricos.
Os pontos de gancho a seguir esto disponveis:
LIBFOO_POST_PATCH_HOOKS LIBFOO_PRE_CONFIGURE_HOOKS
LIBFOO_POST_CONFIGURE_HOOKS LIBFOO_POST_BUILD_HOOKS
LIBFOO_POST_INSTALL_HOOKS (para pacotes de host somente)
LIBFOO_POST_INSTALL_STAGING_HOOKS (para pacotes nico alvo)
LIBFOO_POST_INSTALL_TARGET_HOOKS (para pacotes nico alvo)
Essas variveis so as listas de nomes de variveis contendo aes a
serem realizadas neste momento gancho. Isto permite que vrios
ganchos para ser registrado em um ponto de gancho dado. Aqui est um
exemplo:definir LIBFOO_POST_PATCH_FIXUP action1 action2 ENDEF
LIBFOO_POST_PATCH_HOOKS + = LIBFOO_POST_PATCH_FIXUP
Makefile para autotools baseado pacotes: tutorial Primeiro,
vamos ver como escrever um .mk ficheiro para um pacote
autotools-based, com um exemplo:01: 02: 03: 04: 05: 06: 07: 08: 09:
10: 11: 12: 13: 14:
################################################ ############# # #
libfoo # ################################################
############# LIBFOO_VERSION = 1,0 LIBFOO_SOURCE = libfoo-$
(LIBFOO_VERSION) tar.gz. LIBFOO_SITE =
http://www.foosoftware.org/download LIBFOO_INSTALL_STAGING = YES
LIBFOO_INSTALL_TARGET = YES LIBFOO_CONF_OPT = - enable-shared
LIBFOO_DEPENDENCIES = libglib2 host-pkg-config $ (eval $
(AUTOTARGETS chamada, pacote, libfoo))
Na linha 6, ns declaramos a verso do pacote. Na linha 7 e 8, ns
declaramos o nome do tarball e da localizao do tarball na web.
Buildroot far automaticamente o download do tarball a partir desta
localizao. Na linha 9, dizemos BuildRoot para instalar o pacote
para o diretrio teste. O diretrio provisrio, localizado na
output/staging/ o diretrio onde todos os pacotes esto instalados,
incluindo arquivos de seu desenvolvimento, etc Por padro, os
pacotes no so instalados no diretrio temporrio, pois normalmente,
apenas as bibliotecas precisam ser instalados no encenao diretrio:
arquivos de seu desenvolvimento so necessrios para compilar outras
bibliotecas ou aplicativos, dependendo deles. Tambm por padro,
quando a instalao de teste for ativado, os pacotes so instalados
neste local usando o make install comando. Na linha 10, dizemos
BuildRoot para tambm instalar o pacote para o diretrio de destino.
Este diretrio contm o que se tornar o sistema de arquivos raiz em
execuo no alvo. Normalmente, tentamos no instalar arquivos de
cabealho e instalar verses despojado do binrio. Por padro, instalao
de destino ativado, assim, de facto, esta linha no estritamente
necessrio. Tambm
por padro, os pacotes so instalados neste local usando o make
install comando. Na linha 11, dizemos BuildRoot passar uma opo de
configurao personalizada, que ser passado para o ./configure script
antes de configurar e construir o pacote. Na linha 12, ns
declaramos nossas dependncias, de modo que eles so construdos antes
do processo de construo do nosso pacote comea. Finalmente, na linha
linha 14, ns invocamos o AUTOTARGETS macro que gera todas as regras
Makefile que realmente permite que o pacote a ser construdo.
Makefile para pacotes autotools: referncia A macro principal da
infra-estrutura pacote autotools AUTOTARGETS . Ele tem o mesmo
nmero de argumentos eo semntico mesmo que o GENTARGETS macro, que o
principal macro da infraestrutura pacote genrico. Para pacotes
autotools, a capacidade de ter os pacotes-alvo e de acolhimento
tambm est disponvel (e na verdade amplamente utilizado). Assim como
a infra-estrutura genrica, a infra-estrutura autotools funciona
atravs da definio de uma srie de variveis antes de chamar o
AUTOTARGETS macro. Primeiro, todas as variveis do pacote de
metadados informaes que existem na infra-estrutura genrica tambm
existem no autotools A poucas variveis adicionais, especficas para
a infra-estrutura autotools, tambm pode ser definida. Muitos deles
s so teis em casos muito especficos, pacotes tpicos, portanto, usar
apenas alguns deles. LIBFOO_SUBDIR pode conter o nome de um
subdiretrio dentro do pacote que contm o script configure. Isso til
se, por exemplo, o script configure principal no est na raiz da
rvore extrada pelo tarball. Se HOST_LIBFOO_SUBDIR no especificado,
o padro LIBFOO_SUBDIR . LIBFOO_CONF_ENV , para especificar variveis
de ambiente adicionais para passar para o script configure. Por
padro, o vazio. LIBFOO_CONF_OPT , para especificar opes adicionais
do configure para passar para o script configure. Por padro, o
vazio. LIBFOO_MAKE , para especificar um suplente make de comando.
Isto tipicamente til quando paralelo fazer habilitado na configurao
(usando BR2_JLEVEL ), mas que esse recurso deve ser desativado para
o determinado pacote, por um motivo ou outro. Por padro, definido
como $(MAKE) . Se a construo paralela no suportada pelo pacote,
ento ele deve ser definido como LIBFOO_MAKE=$(MAKE1) .
LIBFOO_MAKE_ENV , para especificar variveis de ambiente adicionais
para passar a fazer na etapa de compilao. Estes so passadas antes
do make de comando. Por padro, o vazio. LIBFOO_MAKE_OPT , para
especificar variveis adicionais para passar a fazer na etapa de
compilao. Estes so passados aps a make comando. Por padro, o vazio.
LIBFOO_AUTORECONF , diz se o pacote deve ser autoreconfigured ou no
(ou seja, se o script configure e arquivos Makefile.in deve ser
re-gerado pelo re-executar autoconf, automake, libtool, etc.) Os
valores vlidos so YES e NO . Por padro, o valor NO
LIBFOO_AUTORECONF_OPT para especificar opes adicionais passados
para o programa autoreconf se LIBFOO_AUTORECONF=YES . Por padro, o
vazio. LIBFOO_LIBTOOL_PATCH diz se o patch para corrigir BuildRoot
libtool compilao cruzada questes devem ser aplicados ou no. Os
valores vlidos so YES e NO . Por padro, o valor YES
LIBFOO_INSTALL_STAGING_OPT contm opes de make usado para instalar o
pacote para o diretrio provisrio. Por padro, o valor
DESTDIR=$$(STAGING_DIR)
install , o que correto para a maioria dos pacotes autotools.
Ainda possvel substitulo. LIBFOO_INSTALL_TARGET_OPT contm opes de
make usado para instalar o pacote para o diretrio de destino. Por
padro, o valor DESTDIR=$$(TARGET_DIR) install . O valor padro
correto para a maioria dos pacotes autotools, mas ainda possvel
substitu-lo se necessrio. LIBFOO_CLEAN_OPT contm opes de make usado
para limpar o pacote. Por padro, o valor clean .
LIBFOO_UNINSTALL_STAGING_OPT , contm opes de make usado para
desinstalar o pacote do diretrio provisrio. Por padro, o valor
DESTDIR=$$(STAGING_DIR) uninstall . LIBFOO_UNINSTALL_TARGET_OPT ,
contm opes de make usado para desinstalar o pacote do diretrio de
destino. Por padro, o valor DESTDIR=$$(TARGET_DIR) uninstall .
Com a infra-estrutura autotools, todos os passos necessrios para
construir e instalar os pacotes j esto definidos, e eles geralmente
funcionam bem para a maioria dos autotools pacotes baseados. No
entanto, quando necessrio, ainda possvel personalizar o que feito
em qualquer passo particular: Pela adio de um gancho de
ps-operatrio (aps o patch extraia, configurar, construir ou
instalar). Consulte a documentao de referncia da infra-estrutura
genrica para mais detalhes. , Substituindo um dos passos. Por
exemplo, mesmo que a infra-estrutura autotools usado, se o pacote
.mk arquivo define seus prprios LIBFOO_CONFIGURE_CMDS varivel, que
ser usado em vez do padro autotools um. No entanto, usando este
mtodo deve ser restrito a casos muito especficos. No us-la no caso
geral. Makefile para CMake baseado pacotes: tutorial Primeiro,
vamos ver como escrever um .mk ficheiro de um pacote baseado em
CMake, com um exemplo:01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11:
12: 13: 14: ################################################
############# # # libfoo #
################################################ #############
LIBFOO_VERSION = 1,0 LIBFOO_SOURCE = libfoo-$ (LIBFOO_VERSION)
tar.gz. LIBFOO_SITE = http://www.foosoftware.org/download
LIBFOO_INSTALL_STAGING = YES LIBFOO_INSTALL_TARGET = YES
LIBFOO_CONF_OPT =-DBUILD_DEMOS = ON LIBFOO_DEPENDENCIES = libglib2
host-pkg-config $ (eval $ (CMAKETARGETS chamada, pacote,
libfoo))
Na linha 6, ns declaramos a verso do pacote. Na linha 7 e 8, ns
declaramos o nome do tarball e da localizao do tarball na web.
Buildroot far automaticamente o download do tarball a partir desta
localizao. Na linha 9, dizemos BuildRoot para instalar o pacote
para o diretrio teste. O diretrio provisrio, localizado na
output/staging/ o diretrio onde todos os pacotes esto instalados,
incluindo arquivos de seu desenvolvimento, etc Por padro, os
pacotes no so instalados no diretrio temporrio, pois normalmente,
apenas as bibliotecas precisam ser instalados no encenao
diretrio:
arquivos de seu desenvolvimento so necessrios para compilar
outras bibliotecas ou aplicativos, dependendo deles. Tambm por
padro, quando a instalao de teste for ativado, os pacotes so
instalados neste local usando o make install comando. Na linha 10,
dizemos BuildRoot para tambm instalar o pacote para o diretrio de
destino. Este diretrio contm o que se tornar o sistema de arquivos
raiz em execuo no alvo. Normalmente, tentamos no instalar arquivos
de cabealho e instalar verses despojado do binrio. Por padro,
instalao de destino ativado, assim, de facto, esta linha no
estritamente necessrio. Tambm por padro, os pacotes so instalados
neste local usando o make install comando. Na linha 11, dizemos
BuildRoot passar as opes personalizadas para CMake quando
configurar o pacote. Na linha 12, ns declaramos nossas dependncias,
de modo que eles so construdos antes do processo de construo do
nosso pacote comea. Finalmente, na linha linha 14, ns invocamos o
CMAKETARGETS macro que gera todas as regras Makefile que realmente
permite que o pacote a ser construdo. Makefile para pacotes CMake:
referncia A macro principal da infra-estrutura pacote CMake
CMAKETARGETS . Ele tem o mesmo nmero de argumentos eo semntico
mesmo que o GENTARGETS macro, que o principal macro da
infraestrutura pacote genrico. Para pacotes CMake, a capacidade de
ter os pacotes-alvo e de acolhimento tambm est disponvel. Assim
como a infra-estrutura genrica, a infra-estrutura CMake funciona
atravs da definio de uma srie de variveis antes de chamar o
CMAKETARGETS macro. Primeiro, todas as variveis do pacote de
metadados informaes que existem na infra-estrutura genrica tambm
existem no CMake A poucas variveis adicionais, especficas para a
infra-estrutura CMake, tambm pode ser definida. Muitos deles s so
teis em casos muito especficos, pacotes tpicos, portanto, usar
apenas alguns deles. LIBFOO_SUBDIR pode conter o nome de um
subdiretrio dentro do pacote que contm o arquivo CMakeLists.txt
principal. Isso til se, por exemplo, o arquivo CMakeLists.txt
principal no est na raiz da rvore extrada pelo tarball. Se
HOST_LIBFOO_SUBDIR no especificado, o padro LIBFOO_SUBDIR .
LIBFOO_CONF_ENV , para especificar variveis de ambiente adicionais
para passar para CMake. Por padro, o vazio. LIBFOO_CONF_OPT , para
especificar opes adicionais do configure para passar para CMake.
Por padro, o vazio. LIBFOO_MAKE , para especificar um suplente make
de comando. Isto tipicamente til quando paralelo fazer habilitado
na configurao (usando BR2_JLEVEL ), mas que esse recurso deve ser
desativado para o determinado pacote, por um motivo ou outro. Por
padro, definido como $(MAKE) . Se a construo paralela no suportada
pelo pacote, ento ele deve ser definido como LIBFOO_MAKE=$(MAKE1) .
LIBFOO_MAKE_ENV , para especificar variveis de ambiente adicionais
para passar a fazer na etapa de compilao. Estes so passadas antes
do make de comando. Por padro, o vazio. LIBFOO_MAKE_OPT , para
especificar variveis adicionais para passar a fazer na etapa de
compilao. Estes so passados aps a make comando. Por padro, o vazio.
LIBFOO_INSTALL_STAGING_OPT contm opes de make usado para instalar o
pacote para o diretrio provisrio. Por padro, o valor
DESTDIR=$$(STAGING_DIR) install , o que correto para a maioria dos
pacotes CMake. Ainda possvel substitu-lo.
LIBFOO_INSTALL_TARGET_OPT contm opes de make usado para instalar
o pacote para o diretrio de destino. Por padro, o valor
DESTDIR=$$(TARGET_DIR) install . O valor padro correto para a
maioria dos pacotes CMake, mas ainda possvel substitu-lo se
necessrio. LIBFOO_CLEAN_OPT contm opes de make usado para limpar o
pacote. Por padro, o valor clean . Com a infra-estrutura CMake,
todos os passos necessrios para construir e instalar os pacotes j
esto definidos, e eles geralmente funcionam bem para a maioria dos
pacotes baseados CMake. No entanto, quando necessrio, ainda possvel
personalizar o que feito em qualquer passo particular: Pela adio de
um gancho de ps-operatrio (aps o patch extraia, configurar,
construir ou instalar). Consulte a documentao de referncia da
infra-estrutura genrica para mais detalhes. , Substituindo um dos
passos. Por exemplo, mesmo que a infra-estrutura CMake usado, se o
pacote .mk arquivo define seus prprios LIBFOO_CONFIGURE_CMDS
varivel, que ser usado em vez do padro CMake um. No entanto, usando
este mtodo deve ser restrito a casos muito especficos. No us-la no
caso geral. Manual Makefile: tutorial NOTA: novo manual de
makefiles no deve ser criado, e manual de makefiles existentes
devem ser convertidos tanto para o genrico, autotools ou
infra-estrutura cmake. Esta seo apenas mantido para documentar o
manual de makefiles existentes e para ajudar a entender como eles
funcionam.01: ################################################
############# 02: # 03: # libfoo 04: # 05:
################################################ ############# 06:
LIBFOO_VERSION: = 1,0 07: LIBFOO_SOURCE:. = Libfoo-$
(LIBFOO_VERSION) tar.gz 08: LIBFOO_SITE: =
http://www.foosoftware.org/downloads 09: LIBFOO_DIR: = $
(BUILD_DIR) / foo-$ (foo_verso) 10: LIBFOO_BINARY: = foo 11:
LIBFOO_TARGET_BINARY: = usr / bin / foo 12: 13: $ (DL_DIR) / $
(LIBFOO_SOURCE): 14: $ (DOWNLOAD chamada, $ (LIBFOO_SITE), $
(LIBFOO_SOURCE)) 15: 16: $ (LIBFOO_DIR) / fonte:. $ (DL_DIR) / $
(LIBFOO_SOURCE) 17: $ (zcat) $ (DL_DIR) / $ (LIBFOO_SOURCE) | tar-C
$ (BUILD_DIR) $ (TAR_OPTIONS) 18: touch $ @ 19: 20:. $ (LIBFOO_DIR)
/ configurado: $ (LIBFOO_DIR) / fonte. 21: (cd $ (LIBFOO_DIR);
rm-rf config.cache; \ 22: $ (TARGET_CONFIGURE_OPTS) \ 23: $
(TARGET_CONFIGURE_ARGS) \ 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: $ (LIBFOO_DIR) / $ (LIBFOO_BINARY): $ (LIBFOO_DIR) /
configurado. 34: $ (MAKE) CC = $ (TARGET_CC)-C $ (LIBFOO_DIR) 35:
36: $ (target_dir) / $ (LIBFOO_TARGET_BINARY): $ (LIBFOO_DIR) / $
(LIBFOO_BINARY) 37: $ (MAKE) DESTDIR = $ (target_dir)-C $
(LIBFOO_DIR) install-strip 38: rm-rf $ (target_dir) / usr / man 39:
40: libfoo: ncurses uClibc $ (target_dir) / $
(LIBFOO_TARGET_BINARY) 41: 42: libfoo-source: $ (DL_DIR) / $
(LIBFOO_SOURCE) 43: 44: libfoo-clean: 45: $ (MAKE) prefix = $
(target_dir) / usr-C $ (LIBFOO_DIR) desinstalar 46: - $ (MAKE)-C $
(LIBFOO_DIR) limpa 47: 48: libfoo-dirclean: 49: rm-rf $
(LIBFOO_DIR) 50: 51:
################################################ ############# 52:
# 53: # opes de Topo Makefile 54: # 55:
################################################ ############# 56:
ifeq ($ (BR2_PACKAGE_LIBFOO), y) 57: METAS + = libfoo 58: endif
Em primeiro lugar, este exemplo Makefile trabalha para um pacote
que inclui um binrio executvel nico. Para outros softwares, como
bibliotecas ou coisas mais complexas com mltiplos binrios, deve ser
adaptado. Para exemplos olhar para o outro *.mk arquivos no package
diretrio. Nas linhas 11/06 , um par de variveis teis so definidos:
LIBFOO_VERSION : A verso do libfoo que deve ser baixado.
LIBFOO_SOURCE : O nome do tarball de libfoo no site de download ou
site FTP. Como voc pode ver LIBFOO_VERSION usado. LIBFOO_SITE : O
site HTTP ou FTP a partir do qual libfoo arquivo baixado. Ele deve
incluir o caminho completo para o diretrio onde LIBFOO_SOURCE pode
ser encontrado. LIBFOO_DIR : O diretrio no qual o software ser
configurado e compilado. Basicamente, um subdiretrio do BUILD_DIR
que criado em cima de descompresso do tarball. LIBFOO_BINARY : nome
do binrio do Software. Como disse anteriormente, este um exemplo
para um pacote com um nico binrio. LIBFOO_TARGET_BINARY : O caminho
completo do binrio dentro do sistema de arquivos-alvo. Linhas 13-14
definir um alvo que faz o download do tarball do site remoto para o
diretrio de download ( DL_DIR ). Linhas 16-18 definir um destino e
as regras associadas que descompactar o tarball baixado. Como voc
pode ver, essa meta depende do arquivo de tarball de modo que a
meta anterior (linhas 13-14 ) chamado antes de executar as regras
do alvo atual. Uncompressing seguido por tocar em um arquivo oculto
para marcar o software como tendo sido descomprimido. Este truque
usado em todos os lugares em um Makefile BuildRoot para dividir as
etapas (download, descompacte, configure, compile, install) e ainda
ter dependncias corretas. Linhas 20-31 definir um destino e as
regras associadas que configurar o software. Depende da meta
anterior (o oculto .source file) de modo que temos a certeza de que
o software foi descompactado. , A fim de configurar o pacote, que
basicamente funciona o conhecido
./configure script. Como podemos fazer compilao cruzada, target
, host e build argumentos so dadas. O prefixo tambm est definido
para /usr , no porque o software ser instalado em /usr no sistema
host, mas porque o software ser instalado em /usr no sistema de
arquivos-alvo. Finalmente ele cria um .configured arquivo para
marcar o software como configurado. Linhas 33-34 definir um destino
e uma regra que compilar o software. Esta meta ser criar o arquivo
binrio no diretrio de compilao e depende do software que est sendo
j est configurado (da a referncia ao .configured arquivo).
Basicamente, ela executa make dentro do diretrio de origem. Linhas
36-38 definir um destino e as regras associadas que instalar o
software dentro do sistema de arquivos-alvo. Eles dependem do
arquivo binrio no diretrio de origem para garantir que o software
foi compilado. Eles usam a install-strip alvo do software Makefile
passando um DESTDIR argumento para que o Makefile no tenta instalar
o software no host /usr , mas sim no alvo /usr . Aps a instalao, o
/usr/man diretrio dentro do sistema de arquivos-alvo removido para
economizar espao. Linha 40 define o alvo principal do software - o
que acabar por ser usado pelo nvel superior Makefile para fazer o
download, compilar e, em seguida, instalar este pacote. Esta meta
deve antes de tudo depende de todas as dependncias necessrias do
software (no nosso exemplo uClibc, e ncurses) e tambm dependem do
binrio final. Esta dependncia ltima vai chamar todas as dependncias
anterior na ordem correta. Linha 42 define um alvo simples que s
faz o download do cdigo fonte. Isto no usado durante a operao
normal de BuildRoot, mas necessrio se voc pretende baixar todas as
fontes necessrias a uma vez para construir mais tarde offline. Note
que se voc adicionar um novo pacote, proporcionando uma
libfoo-source alvo obrigatria para suporte a usurios que desejam
fazer offline-constri. Alm disso, facilita a verificao se todas as
fontes de pacotes so para download. Linhas 44-46 definir um alvo
fcil de limpar o software construir chamando o Makefile com as opes
apropriadas. O -clean alvo deve executar make clean em US $
(BUILD_DIR) / pacote-verso e deve desinstalar todos os arquivos do
pacote de US $ (STAGING_DIR) e de $ (target_dir). Linhas 48-49
definir um alvo fcil de remover completamente o diretrio no qual o
software foi descompactado, configurado e compilado. O -dirclean
alvo deve completamente rm $ (BUILD_DIR) / pacote-verso. Linhas
51-58 adicionar o alvo libfoo lista de metas a serem compilados por
BuildRoot, primeiro verificar se a opo de configurao para este
pacote foi ativado usando a ferramenta de configurao. Se assim for,
ento "subscreve" este pacote para ser compilado, adicionando o
pacote para a varivel de metas globais. O nome adicionado ao METAS
varivel global o nome do alvo este pacote, tal como definido na
linha 40 , que usado por BuildRoot fazer o download, compilar e
ento instalar este pacote.
Gettext integrao e interao com pacotesMuitos pacotes que a
internacionalizao apoio usar a biblioteca gettext. Dependncias para
esta biblioteca bastante complicado e, portanto, merece uma
explicao. O uClibc biblioteca C no implementa a funcionalidade
gettext, portanto, com esta biblioteca C, uma gettext separado deve
ser compilado. Por outro lado, a biblioteca glibc C se integra a
sua prpria gettext, e neste caso, a biblioteca gettext separados no
deve ser compilado, porque cria vrios tipos de falhas de
construo.
Alm disso, alguns pacotes (como libglib2) exigem gettext
incondicionalmente, enquanto outros pacotes (aqueles que apiam
--disable-nls em geral) s exigem gettext quando o suporte local
ativado. Portanto, BuildRoot define duas opes de configurao:
BR2_NEEDS_GETTEXT , o que verdade, logo que o conjunto de
ferramentas no fornece a sua implementao gettext prpria
BR2_NEEDS_GETTEXT_IF_LOCALE , o que verdade se o toolchain no
fornece a sua implementao gettext prpria e se o suporte local
ativado Portanto, pacotes que precisam incondicionalmente gettext
deve: 1. Use select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT e,
possivelmente, select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT , se
libintl tambm necessrio 2. Use $(if $(BR2_NEEDS_GETTEXT),gettext)
no pacote de DEPENDENCIES varivel Pacotes que precisam gettext
apenas quando o suporte local habilitado deve: 1. Use select
BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE e,
possivelmente, select BR2_PACKAGE_LIBINTL if
BR2_NEEDS_GETTEXT_IF_LOCALE , se libintl tambm necessrio 2. Use
$(if $(BR2_NEEDS_GETTEXT_IF_LOCALE),gettext) no pacote de
DEPENDENCIES varivel
ConclusoComo voc pode ver, acrescentando um pacote de software
para BuildRoot simplesmente uma questo de escrever um Makefile
usando um exemplo existente e modific-lo de acordo com o processo
de compilao exigidos pelo pacote. Se voc pacote de software que
podem ser teis para outras pessoas, no se esquea de enviar um patch
para os desenvolvedores BuildRoot!
Perguntas mais frequentes O boot trava aps Starting network...
module-init-tools no consegue construir com cannot find -lc
O boot trava aps Starting network...Se o processo de inicializao
parece travar aps as seguintes mensagens (mensagens no necessarly
exatamente similar, dependendo da lista de pacotes
selecionados):Liberando memria init: 3972K Inicializando gerador de
nmeros aleatrios ... feito. Comeando rede ... Comeando dropbear
sshd: gerao de chaves rsa ... gerando chave dsa ...
OK
ento isso significa que seu sistema est rodando, mas no iniciar
um shell no console serial. A fim de ter o sistema de iniciar uma
shell no seu console serial, voc tem que ir na BuildRoot
configurao, Target options , permitir Generic serial port config ,
e selecione a porta serial e velocidade que voc gostaria de usar
para o shell. Isto ir ajustar automaticamente o /etc/inittab
arquivo do sistema gerada de modo que um shell inicia-se na porta
serial correta.
module-init-tools no consegue construir com cannot find -lcSe a
compilao do module-init-tools para o host falha com:/ Usr / bin /
ld: cannot find-lc
ento provavelmente voc est executando uma distribuio Fedora (ou
similar), e voc deve instalar o glibc-static pacote. Isso ocorre
porque o module-init-tools processo de construo quer ligar
estaticamente com a biblioteca C.
RecursosPara saber mais sobre BuildRoot voc pode visitar estes
sites: http://www.uclibc.org/ http://www.busybox.net/
