Ferramentas de automação
LABI
Ferramentas de automação
DETI
Manuel Costa, Henrique Ferreira
[email protected], [email protected]
Entregue dia 29/11/2015
Contents
1 Resumo 1
2 Introdução 2
I GNU Build System
3
3 GNU 4
3.1 Apresentação . . . 4
3.1.1 O que é? . . . 4
3.2 GNU Build System . . . 4
3.2.1 GNU Make . . . 4
3.2.1.1 Exemplo . . . 5
3.2.2 GNU Autotools . . . 5
3.2.2.1 Autoconf . . . 6
3.2.2.2 Automake . . . 6
3.2.2.3 Gerar Make les utilizando Autotools . . . 6
II ANT Tools
9
4 Apache Ant 10 4.1 Apresentação . . . 104.1.1 O que é? . . . 10
4.2 Ant vs make - Diferenças e similaridades . . . 10
4.2.1 Contras à utilização do Ant . . . 11
4.2.1.1 Exemplos . . . 11 4.2.2 Conclusão - Ant . . . 12
III CMake
13
5 CMake 14 5.1 Apresentação . . . 14 5.1.1 O que é? . . . 145.2 Cmake vs GNU Make . . . 14
5.2.1 Contras à utilizaçao do CMake . . . 14
5.2.1.1 Exemplos . . . 15 5.2.2 Conclusão - CMake . . . 15 6 Metodologia 16 7 Conclusões 17 8 Bibliogra a 18 9 Acrónimos 19
Chapter 1
Resumo
Este trabalho, no âmbito da Unidade Curricular Laboratórios de Informática (LABI) do primeiro ano do Mestrado Integrado em Engenharia de Computa-dores e Telemática (MIECT), aborda 3 ferramentas de automaçao de projectos, nomeadamente as GNU Autotools, ANT Tools e o CMake. As 3 ferramentes são brevemente exploradas e analisadas, apresentando-se as suas vantagens e desvantagens em relação a outras ferramentas e ao âmbito do seu uso. São ainda apresentados alguns exemplos para cada ferramenta abordada neste trabalho. Comparamos também as ANT Tools e o CMake ao GNU Make uma vez que foi a ferramente que exploramos na aula de LABI. Posteriormente apresentamos as nossas conclusões sobre o tema, Ferramentas de automação.
Chapter 2
Introdução
Este trabalho surge no âmbito da Unidade Curricular LABI do primeiro ano do MIECT. Entre os temas disponíveis, optámos por este uma vez que iremos abor-dar, ainda este ano, estes conteúdos em outras unidades curriculares. É também um tema com várias opiniões distintas na informática, portanto achamos inter-essante analisar algumas das ferramentas de automação existentas para melhor entendermos as várias ferramentas.
Este documento está dividido em quatro capítulos. Depois desta introdução, no chapter 3 são aboradas as GNU autotools, no chapter 4 são abordadas as ferramentas Ant, no chapter 5 é abordado o CMake.
Part I
Chapter 3
GNU
3.1 Apresentação
3.1.1 O que é?
GNU's Not Unix! (GNU) é um sistema operacional tipo UNIX que está aberto a qualquer utilizador (open-source) iniciado por Richard Stallman em 1984. O projecto foi crescendo e eventualmente surgiram novas ferramentas associadas como compiladores, editores de texto, etc.
3.2 GNU Build System
Uma das ferramentas mais populares associadas ao projecto GNU é o GNU Build System. Também conhecido como Autotools, são uma série de utencílios de programação que permite aos utilizadores transportar mais facilmente o seu código fonte para outros sistemas UNIX. O GNU Autotools faz parte de um outro projecto chamado GNU Toolchain.
3.2.1 GNU Make
Para compreender melhor o que são e qual o potencial das Autotools, temos que perceber o conceito duma outra ferramenta: o GNU Make. Make é um utilitário que compila automaticamente programas e bibliotecas do código fonte através de um cheiro Make le que contém uma série de instruções dadas pelo utilizador. Se tivermos um projecto de grandes dimensões torna-se um desa o compilar todos os cheiros manualmente. É um processo repetitivo e cansativo além de estar sujeito a condicionantes dos sistemas operativos. Por exemplo, compilar um determinado projecto pode requerer variáveis do sistema que,possivelmente, variam entre sistemas operativos. Desta forma, é muito mais prático e e caz compilar o projecto através de um Make le.
3.2.1.1 Exemplo [h]
.PHONY: all clean cleanall files = *.class
all: $(files) %.class: %.java @javac $^
@echo "Compiling java files..." clean:
@rm -f *.tmp *.java~
@echo "Cleaning temporary files..." cleanall: clean
@rm -f *.class
@echo "Cleaning .class files..."
Neste exemplo muito básico, podemos veri car que:
1. É possível declarar variáveis dentro de um Make le como fazemos,por exemplo,em JAVA. No nosso caso estámos a indicar que qualquer cheiro do tipo .class ca armazenado na variável les
2. Existem regras e dependências. Neste caso, para gerar qualquer cheiro do tipo .class é preciso que existam cheiros fonte .java.
3. As instruções são dadas por comandos bash iguais aos que são utilizados no terminal. Neste caso, para um cheiro qualquer .java vai ser gerado um cheiro .class com o mesmo nome através da execução do comando javac. A instrução echo funciona como um print para saber que a instrução está a correr (opcional).
4. Além de comandos bash, os Make le têm instruções e sintaxe própria como por exemplo $, *. etc.
As possibilidades são muito mais extensas podendo um Make le conter livrarias ou até métodos próprios.
3.2.2 GNU Autotools
Como referido em subsection 3.2.1 o processo de compilar um projecto varia entre sistema operativos. Os compiladores de C são diferentes, assim como algumas livrarias podem não estar presentes em determinados sistemas entre outras di culdades. Podemos, ainda assim, lidar com isto: código condicional. É possível que, ao compilar um projecto, seja feita uma veri cação prévia de determinados pré-requisitos nos sistemas e, caso seja necessário, é também pos-sível ajustar o Make le para o sistema em que está a ser corrido. Este processo já requer a introdução a dois novos conceitos fundamentais:
1. Autoconf 2. Automake
Existem, porém, mais conceitos associados mas para o nosso caso será su ciente explorar estes dois, como por exemplo Autoscan ou Libtool.
3.2.2.1 Autoconf
Com base num cheiro con gure.ac (ac de auto-con g) escrito pelo programador, autoconf irá gerar um script chamado con gure. Quando corremos esse script é gerado um outro script chamado con g.status que transforma cheiros .in (de input) em Make les. De seguida, make utiliza esses Make les para gerar executáveis.
3.2.2.2 Automake
Automake recebe um cheiro con g.h.in e outro chamado Make le.am (am de auto-make) e gera o Make le.in mencionado em subsubsection 3.2.2.1. O au-tomake também faz veri cações a determinadas dependências (como por exem-plo header les).
3.2.2.3 Gerar Make les utilizando Autotools
Em primeiro lugar, é necessário saber quais são os cheiros que o programador vai modi car manualmente:
1. con gure.ac 2. Make le.am
Correndo o autoscan são gerados dois cheiros: autoscan.log e con gure.scan. Altera-se o nome do con gure.scan para con gure.ac e este será um dos cheiros no qual o programador irá escrever. Alternativamente pode-se criar o cheiro con gure.ac, ca a critério do programador. Neste cheiro é possível, por exem-plo, introduzir ordens através de macros para veri car a existência de determi-nado(s) programa(s) no sistema. A macro AC_CHECK_PROG(variável,programa,yes) irá veri car se existe o programa. Esse resultado irá car armazenado numa var-iável com o valor especi cado. Isto é, AC_CHECK_PROG(JAVAEX,javac,yes) irá veri car se existe o Java no sistema, ca armazenado na variável JAVAEX e esta terá valor de yes(equivalente a true) caso exista. É possível inclusive criar uma condição (if) que irá correr determinados comandos caso a variável seja true ou false. Pode-se também veri car a versão do java para garantir que o programa corre com todas as suas funcionalidades, caso o Java esteja desatu-alizado pode até nem correr. Existem outras macros que analisam a existência de livrarias especí cas no sistema. Se um programa precisa duma determinada livraria para correr certas texturas, então essa livraria tem que estar presente no sistema para compilar o projecto. Ainda no con gure.ac é indicado onde vão ser
gerados os Make les (em que diretórios/sub-diretórios). Tendo o con gure.ac criado e com as devidas instruções, criam-se o(s) cheiro(s) Make le.am(am de auto-make). A pasta contém con gure.ac e Make le.am. Ainda assim é preciso
Figure 3.1: Pasta com o projecto e os cheiros con gure.ac/Make le.am criar o Make le.am em todos os diretórios (neste caso nos sub-diretórios src e doc). Executa-se automake para gerar os cheiros restantes e o script con g-urejá irá gerar cheiros Make le mas que ainda não fazem praticamente nada pois não tem nenhuma indicação nos cheiros Make le.am. Em cada um destes cheiros é que serão indicadas as regras para quando forem solicitados, executar determinados comandos (como por exemplo javac).
Part II
Chapter 4
Apache Ant
4.1 Apresentação
4.1.1 O que é?
Da mesma forma que developers encontraram uma solução para automatizar os processos de compilação, outras alternativas foram surgindo que, à partida, se distinguem em determinadas áreas. São um exemplo as Apache Ant Tools, que surgem enquadradas no projecto Apache Tomcat em 2000. Criada por James Duncan Davidson, também autor do projecto Apache Tomcat.
4.2 Ant vs make - Diferenças e similaridades
É uma ferramenta também open-source que serve para compilar projectos de programação. Como é natural, tem diferenças relativamente ao make:
1. Apache Ant usa a linguagem Java e é especializada em compilar projectos em Java.
2. Utiliza build les em XML nquanto que o make, como descrito em subsec-tion 3.2.1, depende dos Make les.
3. Para projectos Java, os Make les não eram 100% portáteis. Isto é, quando se mudava entre sistemas operativos, existiam alguns problemas trabal-hosos de resolver.
4. Os Make les tinham problemas de compatibilidade com sistemas Windows enquanto que os build les são mais independentes das plataformas. 5. Para projectos Java, os Make les eram demasiado complexos. Como o
Ant é orientado a projectos Java, contém processos internos que libertam o programador para este não precisar de especi car tudo ao pormenor.
4.2.1 Contras à utilização do Ant
Como todas as ferramentas, o Ant tem as suas próprias complicações. Uma delas é o facto de os build les serem em XML, que por si só tem uma complexa síntaxe que torna os cheiros menos legíveis e compreensíveis. Apesar dos IDE's (como o Eclipse ou NetBeans) gerarem automaticamente os build les, caso a versão do IDE mude ou se queira mudar de IDE, é conveniente para o programador criar o seu próprio build le.
4.2.1.1 Exemplos
Figure 4.1: Exemplo de condicional utilizado num build le
[h] $ cat > build.xml <project default="hello"> <target name="hello"> <javac srcdir="." includeantruntime="false" destdir="."/> </target> </project> $ cat > Hello.java public class Hello {
public static void main(String[] args) {
String msg = "Hello, World!"; System.out.println(msg);
} }
Da mesma forma que nos Make les, existe um target e uma instrução associada. Tem semelhanças ao uso do LATEXou do HyperText Markup Language (HTML)
na medida em que é indicado um begin e um end para cada target/project, etc. É também vísivel a possibilidade de programar utilizando a linguagem Java dentro dum cheiro build.xml.
4.2.2 Conclusão - Ant
Para lidar com projectos Java, o Ant build é superior ao GNU make mas, como em tudo na Informática, existe muito debate entre os programadores. Também parece ser mais fácil lidar com dependências entre sistemas operativos utilizando o Ant build sempre que seja relativo a projectos Java. Por outro lado, a síntaxe dos build les é mais complexa e menos legível. Em projectos muito grandes isto pode ser um grande contra à utilização do Ant build.
Part III
Chapter 5
CMake
5.1 Apresentação
5.1.1 O que é?
Outra alternativa às Apache Ant Tools e o GNU Make, é o CMake, software open-source, que nasceu da necessidade de um sistema de compilaçao multi-plataforma e o seu autor foi Bill Homan, da Kitware. O CMake é usado em conjunto com a ferramente de compilação de cada sistema.
5.2 Cmake vs GNU Make
Também é uma ferramente open-source à semelhança do make, mas obviamente têm as suas diferenças:
1. Nao compila o código, mas sim gera os build les de acordo com a plataforma aonde está a correr, por exemplo, Make les no UNIX.
2. É uma ferramente mais apropriada a projectos multiplataforma, enquanto que no make teriamos de criar um Make le por plataforma.
3. O CMake consegue lidar bem com hierarquias de directórios complexas e aplicaçoes que dependem de várias librarias.
4. Requer menos código para tarefas mais triviais.
5.2.1 Contras à utilizaçao do CMake
Uma das maiores di culdades na utilizaçao do CMake é o facto de ter a sua própria linguagem, não tão intuitiva como outras ferramentas como por exemplo as AutoTools. O facto do CMake não compilar mas sim gerar os build les também pode ser visto como uma desvantagem uma vez que continuamos a ter de executar o comando make para compilar o projecto. É necessário ainda que o sistema aonde trabalhamos tenha o CMake instalado.
5.2.1.1 Exemplos
Figure 5.1: Exemplo de código CMake
O código compila o cheiro HelloWorld.java num cheiro HelloWord.jar e executa o .jar usando o JVM. A variável CMAKE_JAVA_COMPILE_FLAGS pode ser usada para especi car compile ags.
5.2.2 Conclusão - CMake
Podemos concluir então que, apesar de ter a sua própria linguagem, não muito intuitiva, o CMake é uma ferramenta de extrema utilidade se prentendemos que o nosso projecto seja multiplataforma uma vez que se adapta ao sistema em que está e gera os build- les necessários à compilaçao do projecto de acordo com o sistema aonde estamos a trabalhar.
Chapter 6
Metodologia
A pesquisa baseou-se numa primeira fase em resolver exercício do guião para compreender melhor o que são ferramentas de automação. Ao mesmo tempo, foram adquiridos conhecimentos em duas ferramentas especí cas: GNU Make e GNU auto-tools. Foi frequente a utilização de fóruns informáticos e web-sites informativos.
Chapter 7
Conclusões
Para automatizar o processo de compilação de projetos de programação, foram aparecendo ferramentas para rentabilizar tempo ao programador e para tornar a tarefa mais e caz e menos suscetível a erros. Neste trabalho são avaliadas duas ferramentas partindo como base de comparação o GNU Make: Ant e CMake. As três têm como principais objetivos:
1. Lidar com o repetitivo processo de compilação, ainda que cada uma delas tenha os seus próprios métodos.
2. Facilitar a portabilidade dos projetos entre Sistemas Operativos. Neste ponto depende muito do tipo de projeto, por exemplo num projeto em Java é mais e caz a utilização do Ant.
3. Lidar com as dependências de cada projeto.
Conclui-se que estas ferramentas são fundamentais na hora da realização de um projeto em programação. Elas são utilizadas pelos programadores desde muito cedo, ainda que estes não estejam conscientes disso graças aos IDE's que es-tão programados para lidar com este processo. Contudo programadores mais experientes recomendam que, em projetos mais elaborados, sejam os próprios a lidar com a compilação através destas ferramentas. Não existem apenas três ferramentas de automação pois para cada uma delas existem debilidades que,posteriormente, são melhoradas e que fomentam o aparecimento de novas ferramentas.
Chapter 8
Bibliogra a
1. http://ant.apache.org 2. https://en.wikipedia.org/wiki/Ant 3. https://en.wikipedia.org/wiki/CMake 4. https://cmake.org 5. http://www.tutorialspoint.com/ant/ant_introduction.html 6. Guião prático de LABIChapter 9
Acrónimos
MIECT Mestrado Integrado em Engenharia de Computadores e Telemática GNU GNU's Not Unix!
LABI Laboratórios de Informática HTML HyperText Markup Language
Chapter 10
Contribuição dos Autores
O trabalho foi dividido em três partes principais : , e .
1. Part I e Part II que foram elaboradas por Manuel Costa. 2. Part III realizada por Henrique Ferreira.
No restante relatório, os capítulos foram dívidos de forma igual. Cada elemento elaborou uma parte e analisou o trabalho do colega para aperfeiçoamento do mesmo.
