2.1. Escrevendo o Makefile

O Makefile minimo pareceria algo como isto:

# New ports collection makefile for:   oneko
# Date created:        5 December 1994
# Whom:                asami
#
# $FreeBSD$
#

PORTNAME=      oneko
PORTVERSION=   1.1b
CATEGORIES=    games
MASTER_SITES=  ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/

MAINTAINER=    asami@FreeBSD.org
COMMENT=       A cat chasing a mouse all over the screen

MAN1=          oneko.1
MANCOMPRESSED= yes
USE_IMAKE=     yes

.include <bsd.port.mk>

Veja se você pode comprende-lo. Não se preocupe sobre os índices da linha $FreeBSD$ , será preenchido automaticamente pelo CVS quando o port está importado a nossa arvore do ports principal. Você pode encontrar um exemplo mais detalhado na seção exemplo do Makefile.

2.2. Escrevendo o arquivos de descrição

Existem dois arquivos de descrição que são necessários para qualquer port, se eles são realmente pacotes ou não. Eles são pkg-descr e pkg-plist. Seus prefixos pkg- distingue-os de outros arquivos.

This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
 :
(etc.)

WWW: http://www.oneko.org/

- Satoshi
asami@cs.berkeley.edu

bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/oneko

2.3. Criando o arquivo de checksum

So digite make makesum. As regras do make do ports gerará automaticamente o arquivo distinfo.

2.4. Testando o port

Você deve certificar-se que a regras do port faz exatamente o que você quer que ele faça, incluindo empacotamento do port. Estes são os pontos importantes que você precisa verificar.

• pkg-plist não contém nada instalado pelo seu port

• pkg-plist contém tudo o que está instalado pelo seu port

• Seu port pode ser instalado multiplas vezes usando o reinstall target

• Seu port cleans up depois ele mesmo desinstala

Certifique-se que não ha quetões avisos em nenhum dos estágios package e deinstall. Depois do passo 3, verifique para ver se todos os novos diretórios estão corretamente apagados. Também, tente usando o software depois do passo 4, para assegurar que está funciona corretamente quando instalado de um pacote.

2.5. Verficando seu port com portlint

Por favor use portlint para ver se seu port ajusta-se ao nossas orientações. O programa portlint é parte da coleção do ports. Em particular, você pode querer verificar se o Makefile está na forma correta e o pacotee está nomeado apropriadamente.

2.6. Enviando o port

Primeiro, certifique-se de ter lido a seção FAZERes e NÃO-FAZERes.

Agora que você está feliz com seu port, a unica coisa restante é coloca-lo na arvore do ports principal do FreeBSD e fazer todos felizes sobre ele também. Nós não necessitamos seu diretório work ou o pacote pkgname.tgz, assim apague-os agora. Próximo, simplesmente inclua a saida do shar `find port_dir` em um relatório do bug e envie-o com o programa send-pr(1) (veja Relatório do Bug e Comentário Geral para mais informações sobre send-pr(1)). Se o port descomprimido é maior que 20KB, você deve comprimi-lo dentro de um arquivo tar e usar o uuencode(1) antes de inclui-lo no relatório do bug (uuencoded tarfiles são aceitáveis mesmo se o relatório do relatório do bug é menor que 20KB mas não são preferidos). Esteja certo ao classificar o relatório do bug como categoria ports e classe change-request (Não marque o relatório como confidential!). Também adicione um curta descrição do programa que você portou ao campo ``Description'' do PR e o arquivo tar do shar ou uuencoded ao campo ``Fix''. A ultima ajuda muito os committers, quem usa scripts para o ports-funcionar.

Uma vez mais, não inclua a fonte original distfile, o diretório work, ou o pacote que você construiu com make package.

Depois que você have enviou seu port, por favor seja paciente. As vezes ele pode levar a alguns meses antes que um port seja incluido no FreeBSD, embora possa somente levar alguns dias. Você pode ver a lista de ports esperando para ser committed ao FreeBSD.

Uma vez que nós olharemos seu port, retornaremos para você se necessário, e coloca-lo na arvore. Seu nome também aparecerá na lista de Contribuidores Adicionais do FreeBSD e outros arquivos. Não é ótimo?!? :-)

3.1. Como as coisas funcionam

Primeiro, esta é sequencia de eventos que ocorrem quando o usuário primeiro digita make em seu diretório do port. Você pode encontrar que contem bsd.port.mk em uma outra janela enquanto você le isto realmente ajuda compreende-lo.

Mas não se preocupe se você não entendeu realmente o que bsd.port.mk está fazendo, muitas pessoas não entendem... :->

Acima são as ações. Adicionalmente, você pode definir targets pre-something ou post-something, ou colocar os scripts com aqueles nomes, no subdiretório scripts, e eles serão executados antes ou depois das ações padrões serem feitas.

Por exemplo, se você tem um post-extract target definido em seu Makefile, e um arquivo pre-build no subdiretório scripts, the post-extract target será chamado depois das ações de extração regular, e o script pre-build será executado antes das regras de construção padrão serem feitas. É recomendavel que você use Makefile targets se as ações são simples bastante, porque será mais fácil para alguem compreender que tipo de ação não-padrão o port necessita.

As ações padrões são feitas pelos bsd.port.mk targets do-something. Por exemplo, os comandos para extrair um port estão no target do-extract. Se você não está feliz com o target padrão, você pode conserta-lo redefinindo o do-something target em seu Makefile.

Agora que você entendeu que está acontecendo quando o usuários digita make, deixe-nos ir através dos passos recomendados para criar o port perfeito.

3.2. Obtendo os fontes originais

Obter os fontes originais (normalmente) como um tarball comprimido (foo.tar.gz ou foo.tar.Z) e copie-o dentro DISTDIR. Sempre use mainstream fontes quando quando e onde você possa.

Se você não pode encontrar um site FTP/HTTP que está bem-conectado a rede, ou pode somente encontrar sites que tenham irritantemente formatos não-padrão, você pode querer colocar uma copia em um confiavel servidor FTP ou HTTP que você controle (ex., sua home page). Certifique-se de definir MASTER_SITES a refletir sua escolha.

Se você não pode encontrar algo conveniente e confiavel para colocar o distfile nós podemos ``house'' it nos mesmos no ftp.FreeBSD.org. O distfile tem que colocado dentro ~/public_distfiles/ da conta de alguem da freefall. Pergunte as pessoa quem commits seu port para fazer isto. Esta pessoa também definirá MASTER_SITES ao MASTER_SITE_LOCAL e MASTER_SITE_SUBDIR ao seu freefall username.

Se seu distfile do port muda todo tempo por isso não é boa razão, considere colocando o distfile em sua home page e listando-o como o primeiro MASTER_SITES. Isto empedirá usuários de obterem erros checksum mismatch, e também reduzir a carga de trabalho dos mantedores de nosso site ftp. Também, se há somente um site master para o port, é recomendado que você aloje um backup em seu site e liste-o como segundo MASTER_SITES.

Se seu port necessita alguns `patches' adicionais que estão disponíveis na Internet, busque-os também e coloque-os em DISTDIR. Não se preocupe se eles virem de um outro site de que onde você obteve o tarball do fonte principal, nós temos um meio para manusear estas situações (veja a descrição do PATCHFILES abaixo).

3.3. Modificando o port

Desempacote uma copia do tarball em um diretório privado e faça quaisquer mudaças que são necessárias para fazer o port compilar corretamente sob the versão atual do FreeBSD. Keep careful track de tudo que você fez, assim você estará automatizando o processo logo. Tudo, incluindo o exclusão, adição, ou modificação dos arquivos deve ser feita usando um arquivo script ou patch automatizado quando seu port é finalizado.

Se seu port necessita significantes interação/customização para compilar ou instalar, você deve procurar um dos scripts clássicos do Larry Wall Configure scripts e talvez faz algo similar si mesmo. A meta das novas coleção de ports é fazer cada port como ``plug-and-play'' assim possivel para o usuário-final enquanto usando o minimo de espaço de disco.

3.4. Patching

Na preparação do port, arquivos que foram adicionados ou mudados podem ser picked up com um recursivo diff(1) para depois feeding to patch(1). Cada conjunto de patches que você deseja aplicar deve ser coletado um arquivo chamado patch-* onde * denotas a sequencia em qual os patches serão aplicados -- estes são feitos em ordem alfabetica, assim aa primeiro, ab segundo e assim por diante. Se você deseja, você pode usar nomes que indicam os pathnames dos arquivos que são patched, como patch-Imakefile ou patch-src-config.h. Estes arquivos devem ser armazenados em PATCHDIR, de onde eles serão automaticamente aplicados. Todos patches devem ser relativos ao WRKSRC (normalmente o diretório que seu tarball do port se desempacota dentro, que estando onde a construção é feita). Para fazer consertos e melhorias facilmente, você deve evitar ter mais de um patch de conserto do mesmo arquivo (ex., patch-aa e patch-ab ambos mudando WRKSRC/foobar.c).

Não coloque RCS strings nos patches. O CVS mutilará-los quando nós colocamos os arquivos dentro da arvore do ports, e quando nós verificamos-as saídas novamente, eles sairão diferentes e o patch falhará. As strings RCS são cercadas por sinais de dollar ($), e tipicamente inicia com $Id ou $RCS.

Usando o recurso opção (-r) para diff(1) gerar patches é sutil, mas por favor de olhe os patches resultantes para certificar-se que você não tem nada desnecessário junk em lá. Em particular, diffs entre dois arquivos backup, Makefiles quando o port usa Imake ou GNU configure, etc., são desnecessários e devem ser apagados. Se você teve que editar configure.in e executar autoconf para gerar configure, não pegue os diffs faça configure (frequentemente cresce algumas milhares de linhas!); defina USE_AUTOCONF=yes e pegue os diffs do configure.in.

Também, se você teve que apagar um arquivo, então você pode faze-lo no post-extract target melhor que como parte do patch. Uma vez você está feliz com o diff resultante, por favor divida-o dentro de um arquivo fonte por arquivo patch.

3.5. Configurando

Inclua quaisquer comandos adicionais de customizações em seu script configure e salve-o no subdiretório scripts. Como mencionado acima, você pode também fazer isto com Makefile targets e/ou scripts com o nome pre-configure ou post-configure.

3.6. Manuseando a entrada do usuário

Se seu port necessita de entrada do usuário para construir, configurar, ou instalar, então defina IS_INTERACTIVE em seu Makefile. Isto permitirá ``overnight builds'' para pular seu port se as definições do usuário variável BATCH em seu ambiente (e se o usuário define a variável INTERACTIVE, então somente aqueles ports necessintando interação são construido).

É também recomendado que se há respostas padrões razoáveis para as perguntas, você deve verificar a variável PACKAGE_BUILDING e desativar o iscript interativo quando ele é definido. Isto permitirá-nos construir os pacotes aos CDROMs e FTP.

4.1. O fonte original

Ele mora em DISTDIR como em um padrão gzip'd tarball chamado algo como foozolix-1.2.tar.gz? Se sim, você pode ir ao ao próximo passo. Se não, você deve olhar em sobrescrevendo qualquer das variáveis DISTNAME, EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, ou DISTFILES, dependendo em como alien um formato a seu arquivo distribuição é. (O mais caso comum é EXTRACT_SUFX=.tar.Z, quando o tarball está condensado regularmente compress, não gzip.)

No pior caso, você pode simplesmente criar seu próprio do-extract target para sobrescrever o padrão, embora este deve ser raramente, se for, necessário.

4.2. Nomeando

A primeira parte do Makefile do port nomeia o port, descreve seu número da versão, e lista-os na categoria correta.

PORTNAME=      gtkmumble
PORTVERSION=    0.10

PORTNAME=      gtkmumble
PORTVERSION=    0.10
PORTREVISION=   1

PORTNAME=      gtkmumble
PORTVERSION=    0.2
PORTEPOCH=      1

PORTNAME=      gtkmumble
PORTVERSION=    0.3
PORTEPOCH=      1

4.3. Categorização

4.4. Os arquivos de distribuição

A segunda parte do Makefile descreve os arquivos que tem que ser obtidos em ordem para construir o port, e de onde eles podem ser obtidos.

MASTER_SITES=         ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR=   applications

DISTNAME=      foo
EXTRACT_SUFX=  .tgz

DISTFILES=     source1.tar.gz source2.tar.gz

DISTFILES=     source.tar.gz manual.html
EXTRACT_ONLY=  source.tar.gz

EXTRACT_ONLY=

DISTFILES=      alpha:0 beta:1

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
                ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
                source2.tar.gz:source2

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
                ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
                source2.tar.gz:source2 \
                source3.tar.gz:source2

4.5. MANTEDOR

Defina seu endereço de mail aqui. Por favor. :-)

Para uma descrição detalhada das responsabilidades dos mantedores, consulte a seção Makefiles o MANTEDOR.

Note que somente um único endereço sem comentário part é permitido como um valor MAINTAINER.

Se o mantedor de um port não responder a um pedido de atualização de um usuário após duas semanas (excluindo principais feriados públicos), então that is considered a maintainer timeout, and the update pode ser feito sem aprovação explícita do mantedor. Se o mantedor não responder dentro de três meses, então esse mantedor é considerado ausente without leave, e pode ser substituído como o mantedor do particular port em questão. Exceções a isto são qualquer coisa mantida pelos Ports Management Team <portmgr@FreeBSD.org>, ou o Security Officer Team <security-officer@FreeBSD.org>. Nenhum desautorizado commits pode ser feito aos ports mantidos por aqueles grupos.

O Ports Management Team <portmgr@FreeBSD.org> reserva o direito para revogar ou sobrescrever qualquer maintainership por qualquer razão, e o Security Officer Team <security-officer@FreeBSD.org> reserva o direito para revogar ou sobrescrever maintainership por razões da segurança.

4.6. COMENTÁRIO

Esta é uma descrição de um-linha do port. Por favor não inclua o nome do pacote (ou o número versão do software) no comentário. O comentário deve começar com um capital, e o final sem um período. Aqui está um exemplo:

COMMENT=       A cat chasing a mouse all over the screen

A variável COMMENT deve imediatamente seguir a variável MAINTAINER no Makefile.

4.7. Dependências

Muitos ports dependem de outros ports. Há cinco variáveis que você pode usar para assegurar de que todos necessários bits estarão na máquina do usuário. Há também algum variáveis da dependencia pre-suportadas para casos comuns, mais alguns mais para controlar o comportamento das dependências.

 LIB_DEPENDS=
              jpeg.9:${PORTSDIR}/graphics/jpeg:install

RUN_DEPENDS=   ${LOCALBASE}/etc/innd:${PORTSDIR}/news/inn \
               wish8.0:${PORTSDIR}/x11-toolkits/tk80

 BUILD_DEPENDS=
              unzip:${PORTSDIR}/archivers/unzip

 FETCH_DEPENDS=
              ncftp2:${PORTSDIR}/net/ncftp2

BUILD_DEPENDS=   ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract

4.8. Especificando o diretório de funcionamento

Cada port é extraído dentro a um diretório de funcionamento, qual tem que ser gravável. O sistema de ports supõe que os DISTFILES unpack dentro um diretório chamado ${DISTNAME}. Em outras palavras, se você definiu:

PORTNAME=      foo
PORTVERSION=   1.0

então os arquivos de distribuição do port contém um diretório top-level, foo-1.0, e o resto dos arquivos estão situados sob aquele diretório.

Há um número de variáveis que você pode definir se aquilo não for o caso.

WRKSRC=      ${WRKDIR}/foo

WRKSRC=      ${WRKDIR}/${PORTNAME}

NO_WRKSUBDIR= yes

4.9. CONFLITOS

Se seu pacote não puder coexistir com outros pacotes (por causa de conflitos de arquivos, runtime incompatibilidade, etc.), liste os outros nomes dos pacotes na variável CONFLICTS. Você pode usar shell globs como * e ? aqui. Os nomes dos pacotes devem ser enumerados da mesma maneira que aparecem em /var/db/pkg.

4.10. Mecanismos de Construção

Se seu pacote usa GNU make, defina USE_GMAKE=yes. Se seu pacote usa configure, defina HAS_CONFIGURE=yes. Se seu pacote usa GNU configure, defina GNU_CONFIGURE=yes (this implies HAS_CONFIGURE). Se você quiser dar alguns argumentos extras para configure (a lista padrão de argumentos --prefix=${PREFIX} para GNU configure e vazia para não-GNU configure), defina aqueles argumentos extras em CONFIGURE_ARGS. Se seu pacote usar o GNU autoconf, defina USE_AUTOCONF=yes. Isto implica GNU_CONFIGURE, e fará autoconf ser executado antes de configure.

Se seu pacote for uma aplicação X que cria o Makefiles de Imakefiles usando imake, então defina USE_IMAKE=yes. Isto fará o estágio de configurar para automaticamente fazer um xmkmf -a. Se o -a flag for um problema para seu port, defina XMKMF=xmkmf. Se seu port usa imake mas não compreende o install.man target, NO_INSTALL_MANPAGES=yes deve ser definido. Em adição, o autor do port original deve ser shot. :->

Se seu fonte do port Makefile tem algo mais do que all assim a construção principal target, defina ALL_TARGET accordingly. Mesmo vai para install e INSTALL_TARGET.

5.1. Bibliotecas Compartilhadas

Se seu port instala uma ou mais bibliotecas compartilhadas, defina um INSTALLS_SHLIB make variable, qual instruirá um bsd.port.mk a executar ${LDCONFIG} -m no diretório onde a nova biblioteca for instalada (geralmente PREFIX/lib) durante post-install target para registra-lo dentro do cache da biblioteca compartilhada. Esta variável, quando definida, também facilitará a adição de um apropriado @exec /sbin/ldconfig -m e @unexec /sbin/ldconfig -R pair dentro de seu aerquivo pkg-plist, assim que um usuário que instalou o pacote possa começar usar a biblioteca compartilhada imediatamente e a desinstalação não fará o sistema ainda acreditar que a biblioteca está lá.

Se você necessitar, você pode sobrescrever a location padrão onde a nova biblioteca for instalada definindo LDCONFIG_DIRS make variable, qual deve conter uma lista de diretórios dentro da qual as bibliotecas compartilhadas serão instaladas. Por exemplo se seu port instala bibliotecas compartilhadas dentro dos diretórios PREFIX/lib/foo e PREFIX/lib/bar você pode usar as seguintes em seu Makefile:

INSTALLS_SHLIB= yes
LDCONFIG_DIRS=  %%PREFIX%%/lib/foo %%PREFIX%%/lib/bar

Note que indice de LDCONFIG_DIRS é passado através do sed(1) só como o resto do pkg-plist, assim substituições do PLIST_SUB também aplica aqui. É recomendado que você use %%PREFIX%% para PREFIX, %%LOCALBASE%% para LOCALBASE e %%X11BASE%% para X11BASE.

5.2. Ports com restrições de distribuição

As licenças variam, e algumas delas colocam restrições em como a aplicação pode ser empacotada, whether it possa ser vendido por lucro, e assim por diante.

Nas situações como esta, as seguintes variáveis pode ser definidas. Em adição, ports/LEGAL deve tamém ser atualizado.

5.3. Usando o perl

5.4. Usando o X11

5.5. Usando o automake, autoconf, e libtool

5.6. Usando o GNOME

O projeto FreeBSD/GNOME usa um sistema chamado GNOMENG para definir quais componentes do GNOME um particular port usa. Uma compreensiva lista destas variáveis existe com a homepage do projeto do FreeBSD/GNOME.

5.7. Usando o KDE

5.8. Usando Bison

5.9. Usando Java

5.10. Usando Python

5.11. Usando Emacs

5.12. Usando Ruby

9.1. USE_MOTIF

Se seu port necessita o Motif, defina esta variável no Makefile. Isto impedirá pessoas que não possui uma cópia do Motif de mesmo que tentando construí-lo.

9.2. MOTIFLIB

Esta variável será definida pelo bsd.port.mk para ser a referência apropriada a biblioteca do Motif. Por favor patch o fonte para usar isto onde quer que a biblioteca do Motif está referênciada no Makefile ou Imakefile.

Há dois casos comuns:

• Se o port refere a biblioteca do Motif assim -lXm em seu Makefile ou Imakefile, simplesmente substitua ${MOTIFLIB} para ele.

• Se o port usa XmClientLibs em seu Imakefile, mude-o para ${MOTIFLIB} ${XTOOLLIB} ${XLIB}.

Note que MOTIFLIB (geralmente) expande a -L/usr/X11R6/lib -lXm ou /usr/X11R6/lib/libXm.a, assim não há nenhuma necessidade para adicionar -L ou -l na frente.

12.1. pkg-message

Se você necessitar indicar uma mensagem ao instalador, você pode colocar a mensagem em pkg-message. Esta capability é frequentemente útil mostrar as etapas adicionais da instalação a ser feitas após um pkg_add(1) ou mostrar informação de licenceamento.

12.2. pkg-install

Se seu port necessitar executar comandos quando o pacote binário está instalado com pkg_add(1) você pode fazer isto através do script pkg-install. Este script automaticamente será adicionado ao pacote, e será executado duas vezes pelo pkg_add(1). A primeira vez como ${SH} pkg-install ${PKGNAME} PRE-INSTALL e a segunda vez como ${SH} pkg-install ${PKGNAME} POST-INSTALL. $2 podem ser testados para determinar qual modo o script está sendo executado. A variável ambiental PKG_PREFIX será definida o diretório de instalação do pacote. Veja pkg_add(1) para informação adicional.

12.3. pkg-deinstall

Este script executa quando um pacote é removido.

Este script será executado duas vezes pelo pkg_delete(1). A primeira vez como ${SH} pkg-install ${PKGNAME} DEINSTALL e a segunda vez como ${SH} pkg-install ${PKGNAME} POST-DEINSTALL.

12.4. pkg-req

Se seu port precisa determinar se ele deve instalar ou não, você pode criar um script das ``necessidades'' do pkg-req. Será invocado automaticamente no tempo de instalação/desinstalação para determinar se ou não a instalação/desinstalação deve proseguir.

O script será executado no tempo instalação pelo pkg_add(1) como pkg-req ${PKGNAME} INSTALL. No tempo da desinstalação será executado pelo pkg_delete(1) como pkg-req ${PKGNAME} DEINSTALL.

12.5. Mudando o pkg-plist baseado nas variáveis do make

Alguns ports, particularmente os ports p5-, precisam mudar seus pkg-plist dependendo de que opções eles são configurados com (ou versão do perl, neste caso do ports p5-). Para fazer isto fácil, quaisquer instancias no pkg-plist do %%OSREL%%, %%PERL_VER%%, e %%PERL_VERSION%% será substituida apropriadamente. O valor de %%OSREL%% é a revisãso numérica do sistema operacional (ex., 2.2.7). %%PERL_VERSION%% é o numero da versão completa do perl (ex., 5.00502) e %%PERL_VER%% é o numero da versão do perl menos o patchlevel (ex., 5.005).

Se você precisar fazer outras substituições, você pode definir a variável PLIST_SUB com uma lista de pares VAR=VALUE e exemplos de %%VAR%% será substituída com o VALUE no pkg-plist.

Por exemplo, se você tiver um port que instale muitos arquivos no subdiretório da específica-versão, você pode colocaralgo como

OCTAVE_VERSION= 2.0.13
PLIST_SUB=      OCTAVE_VERSION=${OCTAVE_VERSION}

Esta substituição (assim bem como adição de alguns manual pages) serão feitas entre o pre-install e do-install targets, lendo de PLIST e escrevendo ao TMPPLIST (default: WRKDIR/.PLIST.mktmp). Assim se seu port construir PLIST on the fly, faça assim ou antes de pre-install. Também, se seu port precisa de editar o arquivo resultante, faça assim que o post-install a um arquivo chamado TMPPLIST.

12.6. Mudando os nomes dos arquivos pkg-*

Todos os nomes dos arquivos pkg-* são definidos usando variáveis assim você pode mudá-las em seu Makefile se mprecisar ser. Isto é especialmente útil quando você está compartilhando os mesmos arquivos pkg-* entre diversos ports ou ter que escrever a um dos arquivos acima (veja escrevendo a outros lugares que WRKDIR for porque ele é uma má idéia escrever diretamente dentro do subdiretório pkg-*).

Aqui está uma lista de nomes de variáveis e seus valores padrões. (PKGDIR defaults to ${MASTERDIR}.)

Por favor mude estas variáveis melhor que sobrescrevendo PKG_ARGS. Se você mudar PKG_ARGS, aqueles arquivos não serão corretamente instalados sobre /var/db/pkg instale de um port.

13.1. Portlint

Verifique seu trabalho com o portlint antes que você o envie ou commit.

13.2. PREFIX

Tente fazer seu port instalar relativo ao PREFIX. (O valor desta variável seá definida ao LOCALBASE (default /usr/local), ao menos USE_X_PREFIX ou USE_IMAKE é definido, em qual caso ele será X11BASE (default /usr/X11R6).

Não hard-coding /usr/local ou /usr/X11R6 qualquer lugar no fonte fará o port muito mais flexivel e capaz de atender as necessidades dos outros locais. Para ports do X que usam imake, isto é automático; caso contrário, isto pode frequentemente ser feito simplesmente substituindo as ocorrências de /usr/local (ou /usr/X11R6 para ports do X que não usam imake) nos vários scripts/Makefiles no port para ler PREFIX, assim esta variável é automaticamente passada abaixo a todo estágio do processo de construção e instalação.

Certifique-se que sua aplicação não está instalando coisas em /usr/local ao invés de PREFIX. Um teste rápido para isto é fazer isto:

# make clean; make package PREFIX=/var/tmp/port-name

Se qualquer coisa for instalada fora do PREFIX, fazendo o processo da criação do pacote queixará que ele não pode encontrar os arquivos.

Isto não testa a existência de referências internas, ou corrige o uso de LOCALBASE a referências ao files from other ports. Testing the installation in /var/tmp/port-name para fazer que enquanto você tenha-o instalado faria aquilo.

Não defina USE_X_PREFIX ao menos que seu port verdadeiramente necessite-o (ex., ele linka contra libs do X ou ele precisa referenciar arquivos em X11BASE).

A variável PREFIX pode ser reassigned em seu Makefile ou no ambiente do usuário. Entretanto, ele é fortemente desencorajado a ports individuais para definir esta variável explicitamente no Makefiles.

Também, refer aos programas/arquivos de outros ports com as variáveis mencionadas acima, não explicita pathnames. Por exemplo, se seu port necessita de um macro PAGER para ser o pathname completo do less, use a flag do compilador:

-DPAGER=\"${PREFIX}/bin/less\"

-DPAGER=\"${LOCALBASE}/bin/less\"

13.3. Teste de sanidade do FreshPorts

O FreshPorts tem uma caracterisca teste de sanidade qual automaticamente testa cada commit a arvore do ports do FreeBSD. Se subscribed to este serviço, você será notificado de quaisquer erros qual o FreshPorts detecta durante o teste de sanidade de seus commits.

Se você desejar usar este serviço, tudo que você necessita é uma conta do FreshPorts. Se seu endereço de email registrado é @FreeBSD.org, você verá o link opt-in no no lado da mão direta das páguina da web. Para aqueles como você que já tem uma conta do FreshPorts, mas não estão usando seu endereço de email @FreeBSD.org, só mude seu email para @FreeBSD.org, subscribe, então mude-o de volta novamente.

15.1. Binários Stripping

Não strip binários manualmente ao menos que você tenha. Todos binários devem ser stripped, mas o macro INSTALL_PROGRAM instalará e strip um binário ap mesmo tempo (veja a próxima seção).

Se você necessitar strip um arquivo, mas não deseje usar o macro INSTALL_PROGRAM, ${STRIP_CMD} will strip seu programa. Isto é feito tipicamente com o post-install target. Por exemplo:

post-install:
        ${STRIP_CMD} ${PREFIX}/bin/xdl

Use o comando file(1) nos executáveis instalados para verificar se o binário está stripped ou não. Se ele não diz not stripped, ele está stripped. Adicionalmente, strip(1) will not strip um programa anteoriormente previously stripped; ele ao invés sairá claramnete.

15.2. INSTALL_* macros

Use os macros fornecidos em bsd.port.mk para assegurar modos corretos e ownership dos arquivos em seu próprio *-install targets.

• INSTALL_PROGRAM é um comando para instalar executáveis binários.

• INSTALL_SCRIPT é um comando para instalar scripts executáveis.

• INSTALL_DATA é um comando para instalar dados compartilhaveis.

• INSTALL_MAN é um comando para instalar manpages e outras documentações (ele não comprime qualquer coisa).

Estes são basicamente o comando install com todos flags apropriadas. Veja abaixo para um exemplo em como usá-los.

15.3. WRKDIR

Não escreva qualquer coisa aos arquivos do lado de fora do WRKDIR. WRKDIR é o único lugar que é garantido para ser gravável durante a construção do port (veja compilando ports do CDROM para um exemplo de construção de ports de uma arvore somente-leitura). Se você necessitar modificar um dos arquivos pkg-*, faça assim redefinindo a variável, não escrevendo sobre ele.

15.4. WRKDIRPREFIX

Certifique-se que seu port honors WRKDIRPREFIX. A maioria dos ports não têm que preocupar-se sobre isto. Em particular, se você está referindo a um WRKDIR de um outro port, note que a posição correta é WRKDIRPREFIXPORTSDIR/subdir/name/work not PORTSDIR/subdir/name/work ou .CURDIR/../../subdir/name/work or some such.

Também, se você está definindo WRKDIR você mesmo, certifique-se que você prepend ${WRKDIRPREFIX}${.CURDIR} in the front.

15.5. Diferenciando sistemas operacionais e versões de OS

Você pode vir através do código que necessita as modificações ou a compilação condicional baseadas em que versão do Unix está executando sobre. Se você necessitar fazer tais mudanças ao código para a compilação condicional, certifique-se que você fez as mudanças tanto geral quanto possível assim que nós podemos back-port code aos sistemas FreeBSD 1.x e cross-port a outros sistemas BSD como 4.4BSD de CSRG, BSD/386, 386BSD, NetBSD, e OpenBSD.

A maneira preferida para dizer 4.3BSD/Reno (1990) e novas versões do código BSD code apart é usando o BSD macro definido no <sys/param.h>. Hopefully that arquivo está já incluido; se não, adicione o código:

#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif

ao lugar apropriado no arquivo .c. Nós acreditamos que cada sistema que define estes dois símbolos tem sys/param.h. Se você encontrasse um sistema que não, nós gostaríamos de saber. Por favor envie o mail ao lista de discussão sobre FreeBSD ports e o sistema de ports FreeBSD.

Uma outra maneira é usar o estilo GNU Autoconf de fazer isto:

#ifdef HAVE_SYS_PARAM_H
#include <sys/param.h>
#endif

Não se esqueça de adicionar -DHAVE_SYS_PARAM_H ao CFLAGS no Makefile para este método.

Uma vez que você tenha sys/param.h incluído, você pode usar:

#if (defined(BSD) && (BSD >= 199103))

para detectar se o código é being compilado em um código base do 4.3 Net2 ou mais novo (ex. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 e acima).

Use:

#if (defined(BSD) && (BSD >= 199306))

para detectar se o código está sendo compilado em um código base do 4.4 ou mais novo (ex. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 ou acima).

O valor do macro BSD é 199506 para código base do 4.4BSD-Lite2. Isto é indicado para propósitos informacionais somente. Ele não deve ser usado para distinguição entre versões do FreeBSD baseado somente no 4.4-Lite vs. versões que tenham unido-se em mudanças do 4.4-Lite2. O macro do __FreeBSD__ deve ser usado ao invés.

Use sparingly:

• __FreeBSD__ é definido em todas versões do FreeBSD. Use-o se a mudança que você está fazendo somente afetará o FreeBSD. Porting gotchas como o use de sys_errlist[] vs strerror() são Berkeley-isms, não mudanças do FreeBSD.

• No FreeBSD 2.x, __FreeBSD__ é definido ser 2. Em mais novas versões, ele é 1. Ultaimas versões will bump it to match seu numero de versão principal.

• Se você necessita dizer as diferenças entre um sistema FreeBSD 1.x e um sistema FreeBSD 2.x ou 3.x, usually a resposta certa é para usar os macros BSD descrito acima. Se há atualmente uma mudança específica de FreeBSD (tal como opções especiais da biblioteca compartilhada ao usar ld) então está OK para usar __FreeBSD__ e #if __FreeBSD__ > 1 para detectar um FreeBSD 2.x e sistemas posteriores. Se você necessitar mais granularidade em detectar sistemas do FreeBSD desde 2.0-RELEASE você pode usar o seguinte:

  #if __FreeBSD__ >= 2
  #include <osreldate.h>
  #    if __FreeBSD_version >= 199504
           /* 2.0.5+ release specific code here */
  #    endif
  #endif
  

Nas centenas de ports que feitos, houve somente um ou dois casos onde __FreeBSD__ devia ser usado. Só porque um port anterior screwed up e usou-o no lugar errado não significa que você deve fazer assim também.

15.6. Valores de __FreeBSD_version

15.7. Escrevendo algo após bsd.port.mk

Não escreva qualquer coisa após a linha do .include <bsd.port.mk>. Geralmente pode ser evitada incluindo bsd.port.pre.mk em algum lugar no meio de seu Makefile e bsd.port.post.mk no fim.

O bsd.port.pre.mk define somente algumas variáveis, que podem ser usadas em testes no Makefile, bsd.port.post.mk define o descanso.

Aqui estão algumas variáveis importantes definidas no bsd.port.pre.mk (esta não é a lista completa, por favor leia bsd.port.mk para a lista completa).

Estão aqui alguns exemplos das coisas que você pode escrever após o bsd.port.pre.mk:

# no need to compile lang/perl5 if perl5 is already in system
.if ${OSVERSION} > 300003
BROKEN= perl is in system
.endif

# only one shlib version number for ELF
.if ${PORTOBJFORMAT} == "elf"
TCL_LIB_FILE=  ${TCL_LIB}.${SHLIB_MAJOR}
.else
TCL_LIB_FILE=  ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
.endif

# software already makes link for ELF, but not for a.out
post-install:
.if ${PORTOBJFORMAT} == "aout"
       ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
.endif

15.8. Instale a documentação adicional

Se seu software tiver alguma documentação outra que o man padrão e páginas de info que você pense que é útil ao usuário, instale-o sob PREFIX/share/doc. Isto pode ser feito, como o item anterior, no post-install target.

Críe um novo diretório para seu port. O nome do diretório deve refletir o que o port é. Isto significa geralmente PORTNAME. Entretanto, se você pensa que o usuário pôde querer versões diferentes do port para ser instalado ao mesmo tempo, você pode usar o PKGNAME inteiro.

Facá as dependências da instalação a variável NOPORTDOCS assim que os usuários podem disabilitá-lo no /etc/make.conf, como este:

post-install:
.if !defined(NOPORTDOCS)
        ${MKDIR} ${DOCSDIR}
        ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR}
.endif

Aqui estão algumas variáveis e como elas são expandidas quando usadas no Makefile:

• ${DATADIR} começa expandido a ${PREFIX}/share/${PORTNAME}.

• ${DOCSDIR} começa expandido a ${PREFIX}/share/doc/${PORTNAME}.

• ${EXAMPLESDIR} começa expandido a ${PREFIX}/share/examples/${PORTNAME}.

Todos arquivos de documentação e diretórios instalados devem ser incluídos no pkg-plist com o prefixo %%PORTDOCS%%, por exemplo:

%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
%%PORTDOCS%%%%DOCSDIR%%/CONTACT
%%PORTDOCS%%@dirrm %%DOCSDIR%%

Você pode também usar o arquivo pkg-message para mostrar mensagens sobre instalação. Veja a seção usando o pkg-message para detalhes.

15.9. Subdiretórios

Tente deixar o port colocar coisas no subdiretórios certos do PREFIX. Alguns ports lump tudo e colocam ele no subdiretório com o nome do port, qual está incorreto. Também, muitos ports colocam tudo exceto binários, arquivos header e páginas do manual e um subdiretório do lib, qual não faz bode bem com o paradigma do BSD. Muitos dos arquivos devem ser movidos a um dos seguintes: etc (arquivos de setup/configuração), libexec (executáveis iniciados internamente), sbin (executáveis para superusuários/gerenciadores), info (documentação para navegadores de info) ou share (arquivos independentes de arquitetura). Veja hier(7) para detalhes; as regras governando o /usr muito aplicável ao /usr/local também. A exceção são ports concordam com USENET ``news''. Eles podem usar PREFIX/news como um destino para seus arquivos.

15.10. Cleaning up dos diretórios vazios

Faça seus ports clean up após eles mesmos quando eles são desinstalados. Isto é geralmente acomplished pelo adicionando linhas @dirrm para todos diretórios que são especificamente criados pelo port. Você necessita apagar subdiretórios antes que você possa apagar os diretórios pais.

 :
lib/X11/oneko/pixmaps/cat.xpm
lib/X11/oneko/sounds/cat.au
 :
@dirrm lib/X11/oneko/pixmaps
@dirrm lib/X11/oneko/sounds
@dirrm lib/X11/oneko

Entretanto, as vezes @dirrm dará a você erros porque outros ports também compartilham o mesmo subdiretório. Você pode chamar o rmdir de @unexec para remover somente diretórios vazios sem avisos.

@unexec rmdir %D/share/doc/gimp 2>/dev/null || true

Isto will neither imprimir any mensagens de erro nor cause pkg_delete(1) para sair abnormally even senão está vazio due para outros ports instalando alguns arquivos lá.

15.11. UIDs

Se seu port necessita de um determinado usuário para ser no sistema instalado, deixe o script pkg-install chamar o pw para cria-lo automaticamente. Olhe em net/cvsup-mirror para um exemplo.

Se seu port tem que usar o mesmo numero de ID do usuário/grupo quando ele é instalado como pacote binário como quando ele foi compilado, então você tem que escolher um UID livre de 50 a 999 e registrá-lo abaixo. Olhe em japanese/Wnn para um exemplo.

Certifique-se que você não usa um UID usado já pelo sistema ou outros ports. Esta é a lista atual de UIDs entre 50 e 999.

majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent
cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent
gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh
proxy:*:62:62:Packet Filter pseudo-user:/nonexistent:/nonexistent
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent
pop:*:68:6:Post Office Owner (popper):/nonexistent:/sbin/nologin
wnn:*:69:7:Wnn:/nonexistent:/nonexistent
pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh
oracle:*:71:71::0:0:Oracle:/usr/local/oracle7:/sbin/nologin
ircd:*:72:72:IRC daemon:/nonexistent:/nonexistent
ircservices:*:73:73:IRC services:/nonexistent:/nonexistent
ifmail:*:75:66:Ifmail user:/nonexistent:/nonexistent
www:*:80:80:World Wide Web Owner:/nonexistent:/sbin/nologin
alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent
qmaild:*:82:81:QMail user:/var/qmail:/nonexistent
qmaill:*:83:81:QMail user:/var/qmail:/nonexistent
qmailp:*:84:81:QMail user:/var/qmail:/nonexistent
qmailq:*:85:82:QMail user:/var/qmail:/nonexistent
qmailr:*:86:82:QMail user:/var/qmail:/nonexistent
qmails:*:87:82:QMail user:/var/qmail:/nonexistent
msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh
mysql:*:88:88:MySQL Daemon:/var/db/mysql:/sbin/nologin
vpopmail:*:89:89:VPop Mail User:/usr/local/vpopmail:/nonexistent
smmsp:*:90:90:Sendmail Queue:/nonexistent:/nonexistent
mailman:*:91:91:Mailman User:/usr/local/mailman:/sbin/nologin
gdm:*:92:92:GDM Sandbox:/:/sbin/nologin
jabber:*:93:93:Jabber Daemon:/nonexistent:/nonexistent
p4admin:*:94:94:Perforce admin:/usr/local/perforce:/sbin/nologin
interch:*:95:95:Interchange user:/usr/local/interchange:/sbin/nologin
squeuer:*:96:96:SQueuer Owner:/nonexistent:/bin/sh
mud:*:97:97:MUD Owner:/usr/local/share/dgd:/bin/sh
rscsi:*:99:99:Remote SCSI:/usr/local/rscsi:/usr/local/sbin/rscsi
fido:*:111:111:Fido System:/usr/local/fido:/bin/sh
ldap:*:389:389:OpenLDAP Server:/nonexistent:/sbin/nologin
drweb:*:426:426:Dr.Web Mail Scanner:/nonexistent:/sbin/nologin
bacula:*:910:910:Bacula Daemon:/var/db/bacula:/sbin/nologin

Por favor inclua uma observação quando você enviar um port (ou um upgrade) que reserve um novo UID ou GID nesta escala. Isto permite-nos manter a lista de IDs reservados atualizados.

15.12. Faça coisas racionalmente

O Makefile deve fazer coisas simples e razoavelmente. Se você pode faze-lo um couple de linhas mais curto ou mais legível, então faça assim. Exemplos incluem usando uma construção do .if do make ao invés de uma construção do if do shell, não redefinindo do-extract se você pode redefinir EXTRACT* ao invés, e usando GNU_CONFIGURE ao invés de CONFIGURE_ARGS += --prefix=${PREFIX}.

15.13. Respeite ambos CC e CXX

O port deve respeitar ambos variáveis CC e CXX. Se ele não faz, por favor adicione NO_PACKAGE=ignora ambos cc ou cxx ao Makefile.

Um exemplo de um Makefile respeitando ambas seguintes variáveis CC e CXX. Note que o ?=:

CC ?= gcc

CXX ?= g++

Aqui está um exemplo qual não respeita as variáveis CC nem CXX:

CC = gcc

CXX = g++

Ambas variáveis CC e CFLAGS podem ser definidas no sistema do FreeBSD no /etc/make.conf. O primeiro exemplo define um valor se ele não foi anteriormente definido no /etc/make.conf, preservando quaisquer definições system-wide. O segundo exemplo clobbers quaisquer coisas anteriormente definidas.

15.14. Respeite as CFLAGS

O port deve respeitas as variáveis CFLAGS. Se ele não faz, por favor adicione NO_PACKAGE=ignores cflags ao Makefile.

Um exemplo de um Makefile respeitando a seguinte variável CFLAGS. Note o +=:

CFLAGS += -Wall -Werror

Aqui está um exemplo qual não respeita a variável CFLAGS:

CFLAGS = -Wall -Werror

A variável CFLAGS é definida no sistema do FreeBSD no /etc/make.conf. O primeiro exemplo appends adicinais flags a variável CFLAGS, preservando quaisquer definições system-wide. O segundo exemplo clobbers quaisquer anteriormente definidos.

15.15. Arquivos de Configuração

Se seu port necessita alguns arquivos de configuração no PREFIX/etc, do not just instale-os e liste-os no pkg-plist. Aquilo fará pkg_delete(1) apagar arquivos cuidadosamente editados pelo usuário e uma nova instalação para wipe them out.

Ao invés, instale arquivos de exemplos com um sufixo (filename.sample funcionará bem) e imprima uma mensagem indicando out que o usuário tem que copiar e editar os arquivos antes que o software possa ser feito para executar.

15.16. Feedback

Envie mudanças/patches aplicáveis ao autor/mantedor original para inclusão no próxima release do código. Isto somente fará seu trabalho muito mais fácil a próxima release.

15.17. README.html

Não inclua o arquivo README.html. Este arquivo não é parte da coleção do cvs mas é gerado usando o comando make readme.

15.18. Marcando um port como BROKEN, FORBIDDEN, ou de outra maneira

Invariavelmente there will come a time quando um port particular conterá uma vulnerabilidade de segurança, será radical broken e necessita de muitas horas de tender loving care, ou está geralmente obsoleto, mas por uma razão ou uma outra deve remain na arvore (e ser consertada, certo?). Para designar um port como broken, há três variáveis make que podem ser usadas em um Makefile do port. O valor das seguintes variáveis do make serão a razão que é given back aos usuários para porque o port foi marcado como broken. Por favor use a variável correta do make assim cada variável do make conveys radicalmente diferentes significados a ambos usuários, e para sistemas automatizados que analise o Makefiles.

• O BROKEN é reservado para os ports que não funcionam e não devem ser instalados pelos usuários. Isto will prevent usuários de instalarem o port, entretanto, o ports foi marcado como BROKEN ainda será construido pelo Bento cluster. Marque os ports como BROKEN se você quer que os usuários não instalem este port, mas você ainda quer te-lo construido pelo Bento.

• O FORBIDDEN é usado para os ports que contém uma vulnerabilidade de segurança ou induzir grave interesse a respeito da segurança de um sistema FreeBSD com um given port instalado (ex: a reputably insecure program ou um programa que disponibiliza facilmente serviços exploitáveis). Os ports devem ser marcados como FORBIDDEN assim que um peça particular do software tenha uma vulnerabilidade e não há released upgrade. Idealmente ports devem ser upgraded assim que possível quando uma vulnerabilidade de segurança é discoberta so as to reduce the numero de vulnerabilidades do hosts FreeBSD (nós gostamos de saber para estar seguro), entretanto as vezes há uma noticeable time gap entre descoberta de uma vulnerabilidade e uma release de software atualizado de uma peça do software vulnerável. Não marque um port FORBIDDEN por quaisquer razão outra que segurança.

• O IGNORE é reservado para ports que não devem ser construidos por uma razão ou uma outra. Usuários e o Bento cluster cluster não farão, sob quaisquer circunstâncias, os ports construidos marcados como IGNORE. Se em dúvida, use IGNORE para prevent um port de ser construido.

Lembre que estas variáveis são para ser usadas como um ultimo recurso se um port não é upgradeable. Permanentemente broken ports devem ser removidos da arvore inteiramente.

15.19. Miscellanea

Os arquivos pkg-descr e pkg-plist cada seve ser verificados-em-dobro. Se você está revendo um port e sente que eles podem ser expremido melhor, faça assim.

Não copie mais copias da Licença Pública Geral do GNU dentro de nosso sistema, por favor.

Por favor seja cuidadoso para anotar quaisquer legal issues! Não deixe-nos distribuir software ilegalmente!

15.20. If you are stuck...

Olhe em exemplos existentes e o arquivo bsd.port.mk antes de nos perguntar! ;-)

Pergunte nos se você tenha qualquer problema! Não só bata sua cabeça contra a parede! :-)