Project

General

Profile

Statistics
| Branch: | Revision:

automacao-labi / documento.tex @ 6b9d7df1

History | View | Annotate | Download (16.4 KB)

1
\documentclass{report}
2
\usepackage[T1]{fontenc} % Fontes T1
3
\usepackage[utf8]{inputenc} % Input UTF8
4
\usepackage[backend=biber, style=ieee]{biblatex} % para usar bibliografia
5
\usepackage{csquotes}
6
\usepackage{blindtext} % Gerar texto automáticamente
7
\usepackage[printonlyused]{acronym}
8
\usepackage{hyperref} % para autoref
9
\usepackage{color}
10
\usepackage{acronym}
11
\usepackage{graphicx}
12
\usepackage{verbatim}
13
\setcounter{tocdepth}{3}
14
\setcounter{secnumdepth}{3}
15

    
16

    
17

    
18
\bibliography{bibliografia}
19

    
20

    
21
\begin{document}
22
%%
23
% Definições
24
%
25
\def\titulo{Ferramentas de automação}
26
\def\data{Entregue dia 29/11/2015}
27
\def\autores{Manuel Costa, Henrique Ferreira}
28
\def\autorescontactos{manuel.alejandro@ua.pt, henriqueferreira@ua.pt}
29
\def\versao{v1.0}
30
\def\departamento{DETI}
31
\def\logotipo{UA.jpg}
32
\def\uc{LABI}
33
\def\local{Aveiro}
34
%
35
%% CAPA %%
36
%
37
\begin{titlepage}
38

    
39
\begin{center}
40
%
41
\vspace*{50mm}
42
%
43
{\Huge \titulo}\\ 
44
{\Large \uc}\\
45
%
46
\vspace{10mm}
47
%
48
{\LARGE \autores}\\ 
49
%
50
\vspace{30mm}
51
\end{center}
52
%
53
\begin{flushright}
54
\end{flushright}
55
\end{titlepage}
56

    
57
%
58
%
59
%%  Página de Título %%
60
%
61
%
62
\title{%
63
{\Huge\textbf{\titulo}}\\
64
{\Large \departamento}
65
}
66
%
67
\author{%
68
    \autores \\
69
    \autorescontactos
70
}
71
%
72
\date{\data}\\
73
%
74
\maketitle
75

    
76
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
77
% RESUMO
78
%
79
%
80
\pagenumbering{roman}
81

    
82
\begin{abstract}
83

    
84
resumo de 200-300 palavras.
85
\end{abstract}
86

    
87

    
88
\tableofcontents
89

    
90

    
91
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
92
\clearpage
93
\pagenumbering{arabic}
94

    
95
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
96
\chapter{Introdução}
97
\label{chap.introducao}
98

    
99
Este trabalho surge no âmbito da Unidade Curricular \ac{LABI} do primeiro ano do \ac{miect}
100
Entre os temas disponíveis, optámos por este uma vez que iremos abordar, ainda este ano, estes conteúdos em outras unidades curriculares.
101

    
102
Este documento está dividido em quatro capítulos. Depois desta introdução, no \autoref{chap.descricao} será descrito o trabalho, no \autoref{chap.metodologia} é apresentada a metodologia seguida, no \autoref{chap.resultados} são apresentados os resultados obtidos, sendo estes discutidos no \autoref{chap.analise}. Finalmente, no \autoref{chap.conclusao} são apresentadas as conclusões do trabalho.
103

    
104
\part{GNU \textit{Autotools}}
105
\label{part.gnu}
106
\chapter{GNU}
107
\label{chap.gnu}
108
\section{Apresentação}
109
\subsection{O que é?}
110
\ac{GNU} é um sistema operacional tipo UNIX que está aberto a qualquer utilizador (\textit{open-source}) iniciado por Richard Stallman em 1984. O projecto foi crescendo e eventualmente surgiram novas ferramentas associadas como compiladores, editores de texto, etc.
111
\section{GNU Build System}
112
\label{s.gnubs}
113
Uma das ferramentas mais populares associadas ao projecto \ac{GNU} é o \textit{GNU Build System}. Também conhecido como \textit{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 \ac{GNU} \textit{Autotools} faz parte de um outro projecto chamado \textit{\ac{GNU} Toolchain}. 
114
\subsection{GNU Make}
115
\label{ss.gnumake}
116
Para compreender melhor o que são e qual o potencial das \textit{Autotools}, temos que perceber o conceito duma outra ferramenta: o \textit{\ac{GNU} Make}.
117
\textit{Make} é um utilitário que compila automaticamente programas e bibliotecas do código fonte através de um ficheiro \textit{Makefile} que contém uma série de instruções dadas pelo utilizador. 
118
Se tivermos um projecto de grandes dimensões torna-se um desafio compilar todos os ficheiros 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 eficaz compilar o projecto através de um \textit{Makefile}.
119
\subsubsection{Exemplo}
120

    
121
\begin{verbatim}[h]
122
.PHONY: all clean cleanall
123
files =  *.class
124

    
125
all: $(files)
126

    
127
%.class: %.java
128
	@javac $^
129
	@echo "Compiling java files..."
130
clean: 
131
	@rm -f *.tmp *.java~
132
	@echo "Cleaning temporary files..."
133
cleanall: clean
134
	@rm -f *.class
135
	@echo "Cleaning .class files..."	
136
\end{verbatim}
137

    
138
Neste exemplo muito básico, podemos verificar que:
139
\begin{enumerate}
140
\item É possível declarar variáveis dentro de um \textit{Makefile} como fazemos,por exemplo,em JAVA. No nosso caso estámos a indicar que qualquer ficheiro do tipo .class fica armazenado na variável \textit{files}
141
\item Existem regras e dependências. Neste caso, para gerar qualquer ficheiro do tipo .class é preciso que existam ficheiros fonte .java.
142
\item As instruções são dadas por comandos \textit{bash} iguais aos que são utilizados no terminal. Neste caso, para um ficheiro qualquer .java vai ser gerado um ficheiro .class com o mesmo nome através da execução do comando javac. A instrução \textit{echo} funciona como um \textit{print} para saber que a instrução está a correr (opcional).
143
\item Além de comandos \textit{bash}, os \textit{Makefile} têm instruções e sintaxe própria como por exemplo \$, *. etc.
144
\end{enumerate}
145
As possibilidades são muito mais extensas podendo um \textit{Makefile} conter livrarias ou até métodos próprios.
146
\subsection{GNU Autotools}
147
\label{ss.gnuautotools}
148
Como referido em \autoref{ss.gnumake} 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 dificuldades. Podemos, ainda assim, lidar com isto: código condicional. É possível que, ao compilar um projecto, seja feita uma verificação prévia de determinados pré-requisitos nos sistemas e, caso seja necessário, é também possível ajustar o Makefile para o sistema em que está a ser corrido. Este processo já requer a introdução a dois novos conceitos fundamentais:
149
\begin{enumerate}
150
\item \textit{Autoconf}
151
\item \textit{Automake}
152
\end{enumerate}
153
Existem, porém, mais conceitos associados mas para o nosso caso será suficiente explorar estes dois, como por exemplo \textit{Autoscan} ou \textit{Libtool}.
154
\subsubsection{\textit{Autoconf}}
155
\label{sss.autoconf}
156
Com base num ficheiro configure.ac (ac de auto-config) escrito pelo programador, \textit{autoconf} irá gerar um \textit{script} chamado \textit{configure}. Quando corremos esse \textit{script} é gerado um outro \textit{script} chamado config.status que transforma ficheiros .in (de input) em \textit{Makefiles}. De seguida, \textit{make} utiliza esses \textit{Makefiles} para gerar executáveis.
157
\subsubsection{\textit{Automake}}
158
\textit{Automake} recebe um ficheiro config.h.in e outro chamado \textit{Makefile.am} (am de \textit{auto-make}) e gera o \textit{Makefile.in} mencionado em \autoref{sss.autoconf}. O \textit{automake} também faz verificações a determinadas dependências (como por exemplo \textit{header files}). 
159
\subsubsection{Gerar \textit{Makefiles} utilizando \textit{Autotools}}
160
Em primeiro lugar, é necessário saber quais são os ficheiros que o programador vai modificar manualmente:
161
\begin{enumerate}
162
\item \textit{configure.ac}
163
\item \textit{Makefile.am}
164
\end{enumerate}
165
Correndo o \textit{autoscan} são gerados dois ficheiros: \textit{autoscan.log} e \textit{configure.scan}. Altera-se o nome do \textit{configure.scan} para \textit{configure.ac} e este será um dos ficheiros no qual o programador irá escrever. Alternativamente pode-se criar o ficheiro \textit{configure.ac}, fica a critério do programador. Neste ficheiro é possível, por exemplo, introduzir ordens através de macros para verificar a existência de determinado(s) programa(s) no sistema. A macro AC\textunderscore CHECK\textunderscore PROG(variável,programa,yes) irá verificar se existe o programa. Esse resultado irá ficar armazenado numa variável com o valor especificado. Isto é, AC\textunderscore CHECK\textunderscore PROG(JAVAEX,javac,yes) irá verificar se existe o Java no sistema, fica 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 verificar a versão do java para garantir que o programa corre com todas as suas funcionalidades, caso o Java esteja desatualizado pode até nem correr. Existem outras macros que analisam a existência de livrarias específicas 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 \textit{configure.ac} é indicado onde vão ser gerados os \textit{Makefiles} (em que diretórios/sub-diretórios). 
166
Tendo o \textit{configure.ac} criado e com as devidas instruções, criam-se o(s) ficheiro(s) \textit{Makefile.am}(am de \textit{auto-make}).
167
\begin{figure}[h]
168
\includegraphics[scale=0.5]{Imagem1.png}
169
\caption{Pasta com o projecto e os ficheiros configure.ac/Makefile.am}
170
\end{figure}
171
A pasta contém \textit{configure.ac} e \textit{Makefile.am}. Ainda assim é preciso criar o \textit{Makefile.am} em todos os diretórios (neste caso nos sub-diretórios src e doc). Executa-se \textit{automake} para gerar os ficheiros restantes e o \textit{script configure}já irá gerar ficheiros \textit{Makefile} mas que ainda não fazem praticamente nada pois não tem nenhuma indicação nos ficheiros \textit{Makefile.am}. Em cada um destes ficheiros é que serão indicadas as regras para quando forem solicitados, executar determinados comandos (como por exemplo javac).
172
\begin{figure}[h]
173
\includegraphics[scale=0.5]{Autotools.png}
174
\caption{Diagrama do funcionamento das \textit{Autotools}}
175
\end{figure}
176

    
177

    
178
%
179
%
180
%
181
%
182
%
183
%
184

    
185
\part{ANT Tools}
186
\label{part.ant}
187
\chapter{Apache Ant}
188
\section{Apresentação}
189
\subsection{O que é?}
190
Da mesma forma que \textit{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 \textit{Apache Ant Tools}, que surgem enquadradas no projecto \textit{Apache Tomcat} em 2000. Criada por James Duncan Davidson, também autor do projecto \textit{Apache Tomcat}.
191

    
192

    
193
\section{Ant vs \textit{make} - Diferenças e similaridades}
194

    
195
É uma ferramenta também \textit{open-source} que serve para compilar projectos de programação. Como é natural, tem diferenças relativamente ao \textit{make}:
196
\begin{enumerate}
197
\item Apache Ant usa a linguagem Java e é especializada em compilar projectos em Java. 
198
\item Utiliza \textit{build files} em \textit{XML} nquanto que o \textit{make}, como descrito em \autoref{ss.gnumake}, depende dos \textit{Makefiles}. 
199
\item Para projectos Java, os \textit{Makefiles} não eram 100\% portáteis. Isto é, quando se mudava entre sistemas operativos, existiam alguns problemas trabalhosos de resolver. 
200
\item Os \textit{Makefiles} tinham problemas de compatibilidade com sistemas Windows enquanto que os \textit{build files} são mais independentes das plataformas.
201
\item Para projectos Java, os \textit{Makefiles} eram demasiado complexos. Como o \textit{Ant} é orientado a projectos Java, contém processos internos que libertam o programador para este não precisar de especificar tudo ao pormenor.
202
\end{enumerate}
203

    
204
\subsection{Contras à utilização do \textit{Ant}}
205
Como todas as ferramentas, o \textit{Ant} tem as suas próprias complicações. Uma delas é o facto de os \textit{build files} serem em \textit{XML}, que por si só tem uma complexa síntaxe que torna os ficheiros menos legíveis e compreensíveis. Apesar dos IDE's (como o Eclipse ou NetBeans) gerarem automaticamente os \textit{build files}, caso a versão do IDE mude ou se queira mudar de IDE, é conveniente para o programador criar o seu próprio \textit{build file}.	
206
\subsubsection{Exemplos}
207
\begin{figure}[h]
208
\includegraphics[scale=0.5]{ANT.png}
209
\caption{Exemplo de condicional utilizado num \textit{build file}}
210
\end{figure}
211
\begin{verbatim}[h]
212
$ cat > build.xml
213
<project default="hello">
214
  <target name="hello">
215
    <javac srcdir="."
216
           includeantruntime="false"
217
           destdir="."/>
218
  </target>
219
</project>
220

    
221
$ cat > Hello.java
222
public class Hello {
223
  public static void
224
  main(String[] args) {
225
    String msg = "Hello, World!";
226
    System.out.println(msg);
227
  }
228
}
229
\end{verbatim}
230
Da mesma forma que nos \textit{Makefiles}, existe um \textit{target} e uma instrução associada. Tem semelhanças ao uso do \LaTeX ou do \ac{HTML} na medida em que é indicado um \textit{begin} e um \textit{end} para cada \textit{target/project}, etc. 
231
É também vísivel a  possibilidade de programar utilizando a linguagem Java dentro dum ficheiro \textit{build.xml}.
232

    
233
\subsection{Conclusão - Ant}
234
Para lidar com projectos Java, o \textit{Ant build} é superior ao \textit{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 \textit{Ant build} sempre que seja relativo a projectos Java.
235
Por outro lado, a síntaxe dos \textit{build files} é mais complexa e menos legível. Em projectos muito grandes isto pode ser um grande contra à utilização do \textit{Ant build}. 
236

    
237
%
238
%
239
%
240
%
241
\part{CMake}
242
\label{part.cmake}
243
\chapter{Cmake}  %Explicar quem é o pessoal do cmake
244
\section{Apresentação} %Pegar no cmake propriamente dito e por aí fora
245
\subsection{O que é?}
246

    
247
Outra alternativa às \texit{Apache Ant Tools} e o \textit{GNU Make}, é o \texit{CMake}, software open-source, que nasceu da necessidade de um sistema de compilaçao multiplataforma e o seu autor foi Bill Hoffman, da Kitware. O \texit{CMake} é usado em conjunto com a ferramente de compilação de cada sistema.
248
\section{Cmake vs GNU Make} % Comparar com enumerate
249

    
250
Também é uma ferramente open-source à semelhança do \texit{make}, mas obviamente têm as suas diferenças:
251
\begin{enumerate}
252
\item Nao compila o código, mas sim gera os buildfiles de acordo com a plataforma aonde está a correr, por exemplo, Makefiles no UNIX.
253
\item É uma ferramente mais apropriada a projectos multiplataforma, enquanto que no \texit{make} teriamos de criar um Makefile por plataforma.
254
\item O CMake consegue lidar bem com hierarquias de directórios complexas e aplicaçoes que dependem de várias librarias.
255
\item Requer menos código para tarefas mais triviais.
256
\end{enumerate}
257

    
258
\subsection{Contras à utilizaçao do \texit{CMake}}
259

    
260
Uma das maiores dificuldades na utilizaçao do \texit{CMake} é o facto de ter a sua própria linguagem, não tão intuitiva como outras ferramentas como por exemplo as \texit{AutoTools}. O facto do \texit{CMake} não compilar mas sim gerar os builfiles 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 tenho \texit{CMake} instalado.
261

    
262
\subsubsection{Exemplos} %Imagens exemplo a explicar a comparação feita antes
263
\begin{figure}[h]
264
\includegraphics[scale=0.5]{cmake.jpg}
265
\caption{Exemplo de código \texit{CMake}}
266
\end{figure}
267

    
268
O código compila o ficheiro HelloWorld.java num ficheiro HelloWord.jar e executa o .jar usando o JVM. A variável CMAKE_JAVA_COMPILE_FLAGS pode ser usada para especificar \texit{compile flags}.
269

    
270
\subsection{Conclusão - CMake} %Conclusão do CMake comparado com GNU
271

    
272
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 \texit{build-files} necessários à compilaçao do projecto de acordo com o sistema aonde estamos a trabalhar.
273
%
274
\chapter{Metodologia}
275
\label{chap.metodologia}
276
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íficas: \ac{GNU} Make e \ac{GNU} auto-tools.
277
Foi frequente a utilização de fóruns informáticos e web-sites informativos.
278

    
279
\chapter{Conclusões}
280
\label{chap.conclusao}
281
Apresenta conclusões
282

    
283
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
284
\chapter*{Acrónimos}
285
\begin{acronym}
286
\acro{ua}[UA]{Universidade de Aveiro}
287
\acro{miect}[MIECT]{Mestrado Integrado em Engenharia de Computadores e Telemática}
288
\acro{glisc}[GLISC]{Grey Literature International Steering Committee}
289
\acro{GNU}[GNU]{GNU's Not Unix!}
290
\acro{LABI}[LABI]{Laboratórios de Informática}
291
\acro{HTML}[HTML]{\textit{HyperText Markup Language}}
292
\end{acronym}
293

    
294

    
295

    
296
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
297
\printbibliography
298

    
299
\end{document}