GNU Autotools (parte II) - Utilitários

Na continuação da apresentação dos conceitos básicos de funcionamento das Autotools, conjunto de ferramentas usadas para automatização de geração de builds de software, veremos os arquivos fundamentais presentes numa distribuição que se aproveita da infraestrutura makefile. Observando um projeto típico que usa das autoconfs, alguns arquivos são característicos, e muitos deles são de presença mandatória:


data/
debian/
m4/
samples/
src/
tests/
AUTHORS
COPYING
ChangeLog
INSTALL
Makefile.am
NEWS
README
aminclude.am
autogen.sh
configure.ac
doxygen.cfg
gmyth.pc.in


A estrutura de diretórios acima foi obtida de: http://gmyth.svn.sourceforge.net/viewvc/gmyth/trunk/gmyth/. Os arquivos com nomes em maiúsculas são documentos texto, caracteres no formato ASCII, e são descritivos do projeto, contém metadados com informações importantes, como o nome dos autores do projeto (AUTHORS) e a licença de cópia e distribuição do código (COPYING). Eles são obrigatórios, e em alguns passos de processamento, é possível que ferramentas como autoconf retornem com erro, caso não encontrem tais arquivos, apesar da aparente função de baixa prioridade que seria a de informação sobre releases de software e nomes de autores.

A seguir, por ordem de importância, temos o Makefile.am. Esse arquivo é uma espécie de Makefile, tal como visto no último post, porém em estágio de pré-processamento, ou seja, contém estruturas e macros que ainda devem ser processadas, e utiliza de variáveis definidas na sequência de montagem de build comandada pelo arquivo configure.ac (que por sua vez gera o configure). O trecho seguinte de Makefile.am apresenta algumas estruturas fundamentais:

SUBDIRS= src samples tests

(...)

if HAVE_INDENT
indent:
cd src; \
make indent; \
cd ..
endif

include aminclude.am

EXTRA_DIST = \
autogen.sh \
gmyth.pc.in \
AUTHORS \
COPYING \
README

Esse arquivo Makefile.am será utilizado como entrada no utilitário automake, as macros chamadas a partir dele serão processadas como devido, e o arquivo texto resultante será transformado no arquivo Makefile, com estruturas semelhantes àquelas vistas no post passado, porém bem mais detalhada e complexa, Por sinal, os resultados de processamento das autotools costumam ser de leitura BEM difícil para quem não estiver habituado a Makefiles e programação em Shell Script, mas depurar uma distribuição com autoconf algumas vezes necessita-se inspecionar arquivos Makefile e configure auto-gerados a fim de identificar inconsistência ou erros (como um path de biblioteca inválido, ou variável de ambiente mal definida).

Ao rodar em cima desse arquivo Makefile.am, o automake definirá, na ordem, uma variável SUBDIRS, que listará os subdiretórios do projeto que contém outras definições Makefile.am. A variável SUBDIRS é padrão, e deve sempre ser definida quando se lida com projetos mais complexos, com vários Makefiles, porque é através dele que será determinada a abrangência e a forma como o build vai ser gerado: um diretório faltando pode prejudicar a release final, bem como a inclusão de um módulo em SUBDIRS que não seja possível de ser compilado em determinada arquitetura, pode gerar problemas na execução em alguma etapa de processamento das autotools... Durante a execução, serão processados, respectivamente, arquivos Makefile.am nos subdiretórios src, samples e tests.

Pode-se, dentro de um Makefile.am, determinar a criação condicional de targets, ou adição de qualquer trecho de código, usando variáveis definidas numa etapa anterior do automake, como o uso de variáveis definidas no configure.ac (autoconf). Aqui temos que a variável HAVE_INDENT é verificada com relação ao seu valor verdade e, caso a avaliação seja positiva, o target indent é criado. Essa variável será definida TRUE caso a opção de identação de código tenha sido informada em linha de comando (durante a chamada inicial aos autotools), bem como se a ferramenta indent foi encontrada na distribuição alvo. Abaixo, vemos o trecho de código do configure.ac que cria a variável HAVE_INDENT com o valor apropriado:

# checks if the indent tool can be found
AC_CHECK_PROG(HAVE_INDENT, indent, [Found!])
if test -n "$HAVE_INDENT"; then
AC_DEFINE(HAVE_INDENT, 1, [AutoIndent found!])
fi

AM_CONDITIONAL(HAVE_INDENT, test -n "$HAVE_INDENT")

A macro M4 "AC_CHECK_PROG" funciona da seguinte forma: a variável HAVE_INDENT será declarada caso o aplicativo indent possa ser executado com sucesso em prompt de comando, imprimindo uma mensagem "Found!" em caso afirmativo. A macro AM_CONDITIONAL faz com que a variável HAVE_INDENT seja visível em escopo de arquivos de entrada Automake (Makefile.am), o que a torna passível de ser usada em expressões condicionais, como o trecho de avaliação do if no Makefile.am.

Na sequência, e voltando ao arquivo Makefile.am, temos a definição da macro EXTRA_DIST, que irá informar ao utilitário automake quais os arquivos que devem ser disponibilizados quando da geração do build de distribuição (aquele que fará parte do pacote de distribuição ao usuário do sistema de software). No caso da biblioteca GMyth acima, os arquivos distribuídos são aqueles que incorporam meta-dados de informação ao pacote (AUTHORS, COPYING), além de scripts úteis à geração do build (autogen.sh) e um arquivo de configuração para resolução de dependências (gmyth.pc.in), que serve como arquivo de entrada para o utilitário pkg-config, que procura resolver as dependências de biblioteca no ambiente constante à distribuição. Detalharemos depois o uso dessas outras ferramentas.

No próximo post, detalharei mais a respeito do processamento do configure.ac através do autotools...

Iniciando com GNU Autotools

Muita gente procura em sites para desenvolvedores informações sobre como usar as ferramentas da GNU para gerenciamento de compilação de código-fonte, library linking com os binários, geração de bibliotecas e distribuição de código executável. Essas ferramentas são amplamenta conhecidas como "autotools" (automake, autoconf, libtool, etc.), e são usadas com frequência em projetos de software livre. E encontrar tais informações de uso, de forma simples e resumida, é tarefa que demanda a busca em inúmeros sites, bem como experimentações em linha de comando. Pra piorar, o mecanismo de funcionamento das autotools não é simples. Portanto, qual a real necessidade delas? Definindo da forma mais simples possível, autotools são aplicativos e scripts de linha de comando que facilitam o trabalho do desenvolvedor de aplicativos e bibliotecas no trabalho de gerar e linkar um código binário, por dinamizar a forma como esse produto vai ser disponibilizado em produção. Tal recurso provê meios de, automaticamente, buscar pela versão de uma biblioteca necessária para um determinado módulo do aplicativo, por exemplo. Isso é particularmente importante quando o projeto de software é uma atividade desenvolvida através da participação de membros em ambientes heterogêneos de desenvolvimento, facilitando o trabalho do programador no momento em que ele se vê, por exemplo, com uma dependência recém adicionada de biblioteca.

Vou tentar mostrar aqui como iniciar o uso dos Makefiles. A princípio, não abordarei como se cria um Makefile, porque esse vem sendo continuamente um trabalho menos necessária, uma vez que ferramentas como o automake/autoconf já facilitam muita coisa, através de inúmeras macros de automação pré-definidas em M4, uma espécie de meta-linguagem funcional usada para adicionar recursos de configuração e busca aos Makefiles, tal como a macro M4 chamada AC_CHECK_LIB, que checa no sistema de execução por uma biblioteca especificada, necessária para a distribuição. Me limitarei aqui a detalhar como começar um projeto em autoconf, que abstrai muitas das demandas de projetos complexos em Makefile.

Um arquivo de configuração GNU Make (Makefile) simplesmente especifica regras (tasks, ou tarefas) de compilação e geração de código com bibliotecas. Por exemplo, no arquivo Makefile abaixo:


%.o: %.c
  $(CXX) -c $(CFLAGS) $(INCLUDES) $< -o $@  


OBJ_FILES = gmu_dragwin.o gmu_dragwin_module.o  

TARGET = gmu_dragwin.so  

build: $(OBJ_FILES)      

     $(CXX) $(LDFLAGS) $(INCLUDES) $(LIBSPATH) $(OBJ_FILES) $(LIBS) -o $(TARGET)  


all: build

Aí vemos alguns conceitos importantes na definição de Makefiles: o conceito fundamental é o de tasks (tarefas) de manutenção, que são especificadas no texto acima por identificadores alfanuméricos seguidos de dois pontos. Daí temos a definição de 2 tasks básicas: build e all. A task build é simplesmente a que define a geração do produto específico do Makefile, a meta básica decorrente da execução deste. Tanto que é ela que vai especificar como parâmetro último na geração a variável $(TARGET), que está definida mais acima como sendo o nome de arquivo de biblioteca, "gmu_dragwin.so", que é o nome do nosso componente. A task (ou target) "all" é simplesmente uma conveniência do Makefile para que, caso não seja especificada taks alguma em momento de execução do procedimento de make, a taks build será a chamada default. A linha seguinte ao símbolo ":" de definição do target é chamada de pré-requisito, porque a realização dessa task depende da execução sem erros de cada um dos pré-requisitos determinados. Portanto, digitar em linha de comando o comando make, no mesmo nível de diretório em que se encontra o arquivo Makefile acima, irá resultar na geração dos códigos objetos e o arquivo gmu_dragwin.so, que se refere à biblioteca:

# cd drawin_library
# ls
Makefile     gmu_dragwin.c    gmu_dragwin_module.c
# make
# ls
Makefile      gmu_dragwin.c    gmu_dragwin_module.c
gmu_dragwin.o    gmu_dragwin_module.o    gmu_dragwin.so

A chamada a make sem task nenhuma, faz com que a task all seja buscada como a padrão, que por sua vez em nosso Makefile redireciona a tarefa para a build. Na chamada a make, poderia-se ter especificado a task desejada diretamente, tal como em: make build. O resultado seria exatamente o mesmo.

A terceira task no Makefile exemplo do texto acima é mais aprimorada, e admite um critério dinâmico para a necessidade de recompilação dos códigos-objeto dos arquivos fontes em linguagem C. A task %.o diz que toda referência no texto a qualquer pré-requisito, em qualquer target, que tenha um nome definido por uma sequência qualquer de caracteres alfanuméricos, seguido por uma string ".o" (por sinal, uma extensão de arquivo objeto), fará com que seja automaticamente chamada essa task, que por sua vez verificará a efetividade de cada um dos pré-requisitos. O primeiro pré-requisito será encontrar um arquivo de código-fonte com o mesmo nome do target, mas com extensão ".c":

%.o: %.c
  $(CXX) -c $(CFLAGS) $(INCLUDES) $< -o $@  

No pré-requisito seguinte, será chamado o compilador GCC (cujo caminho no sistema de arquivos é apontado pela variável $(CXX)) com os parâmetros detalhados no target acima como sendo $<, que se refere ao nome do arquivo-fonte (por exemplo, gmu_dragwin.c); e a variável $@ aponta para o valor corrente do nome do target (p.e., gmu_dragwin.o). Esses recursos de substituição são amplamente utilizados, uma vez que permitem que o Makefile defina dinamicamente suas próprias regras, e são chamados de "regras de substituição" (pattern rules).

Uma vez tendo fundamentado os conceitos básicos de Makefile, veremos na sequência os detalhes de como as ferramentas de autotools criam tudo isso de forma mais prática, permitindo a definição de regras mais avançadas de configuração.