Commit 6fc50d9b authored by Marcelo Jorge Vieira's avatar Marcelo Jorge Vieira

Imported Upstream version 1.0.2

parents
Thiago Silva <tsilva@sourcecraft.info>
This diff is collapsed.
This diff is collapsed.
Desenvolvendo
=============
o Instalando dependências
Para desenvolver o GPT é necessário instalar os seguintes programas:
- g++
- make
- automake (v1.9 ou superior)
- autoconf
- libtool
- antlr (v2.6.x ou superior)
- pcre e pcrecpp
- nasm
Para satisfazer estas dependências no (K)Ubuntu ou Debian, pode-se executar
o seguinte comando:
# aptitude install g++ make automake1.9 autoconf libtool antlr libantlr-dev \
> libpcrecpp0 libpcre3-dev nasm
o Baixando a última versão do GPT
Para obter as últimas versões do código fonte do GPT, é necessário
fazer um checkout no repositório, utilizando o subversion. Para instala-lo, use o seguinte comando:
# aptitude install subversion
ex (checkout anônimo):
$ svn checkout svn://svn.berlios.de/gpt/trunk/gpt
Se você for um membro do projeto, deve ser autenticado.
ex (checkout autenticado):
$ svn checkout svn+ssh://username@svn.berlios.de/svnroot/repos/gpt/trunk/gpt
Maiores informações na página do projeto no BerliOS:
http://developer.berlios.de/projects/gpt
o Iniciando o desenvolvimento
Se você estiver utilizando o código fonte do repositório, é necessário
fazer o setup do sistema de construção com o seguinte comando:
$ make -f Makefile.cvs
Isto criará os Makefile.in's nescessários e o shell script "configure"
utilizado para criar os Makefile's utilizados pelo programa "make"
para automatizar a compilação do projeto.
Se estiver utilizando o código fonte de uma versão específica
(obtida por meio de um pacote tar.gz, por exemplo), o script "configure"
já estará disponível.
NOTA: se estiver obtendo erros nos arquivos Makefile.am ao executar
make -f Makefile.cvs, verifique a versão do automake sendo utilizada:
$ automake --version
Se o comando acima informar uma versão inferior à 1.9, desinstale esta versão,
execute manualmente o automake1.9 ou faça as devidas configurações para que
a versão correta seja utilizada.
o Configurando e construindo
Agora, basta seguir as instruções do arquivo INSTALL, executando o
"configure" com as opções desejadas e, em seguida, executando "make" e
"make install", se quiser instalar os arquivos no sistema.
o Realizando commits
As mensagens de commit devem, idealmente, seguir pequenas convenções:
-Toda mensagem de commit deve ser enviada utilizando ASCII, sem acentos.
(pelo menos, até termos os emails em gpt-commit exibidos corretamente)
-Toda descrição lógica deve iniciar em uma nova linha, prefixada por "-".
Ex: Duas descrições para as modificações do arquivo A.cpp :
$ svn ci A.cpp -m"-Utilizando algoritmo mais rápido para a função f()
> -Adicionado classe X para lidar com erros do usuário"
- Todas as modificações lógicas que envolvem vários arquivos devem
ser commitadas em uma mesma leva, a não ser que um ou mais arquivos
envolvidos contenham outras modificações. Neste último caso,
o arquivo poderá ser commitado separadamente, mas com a mesma
mensagem do commit da leva, além da mensagem descrevendo as
modificações específicas.
Ex 1: A.cpp e B.cpp foram modificados. A.cpp teve o nome de uma função
modificada, e B.cpp, por usar esta função, teve que ser modificado também.
Os dois arquivos, A.cpp e B.cpp devem ser commitados em conjunto:
$ svn ci A.cpp B.cpp -m"-Função func() renomeada para f()"
Ex 2: A.cpp e B.cpp foram modificados. A.cpp melhorou um algoritmo e
modificou o nome de uma função. B.cpp, por utilizar esta função, teve que
ser modificado também. Os dois arquivos, A.cpp e B.cpp podem ser
commitdos separadamente:
$ svn ci A.cpp -m"-Função func() renomeada para f()
> -Utilizando algoritmo xyz para a funcao z()"
$ svn ci B.cpp -m"-Função func() renomeada para f()"
Note que a mesma mensagem da mudança da função foi utilizada nos dois
commits.
Ou em conjunto (o que ficar mais claro para quem ler os Logs :-)
$ svn ci A.cpp B.cpp -m"-Função func() renomeada para f()
> -Utilizando algoritmo xyz para a funcao z() em A.cpp"
-Mensagens de modificações que resolvem bugs devem ser precedidos por BUGFIX:
$svn ci A.cpp -m"BUGFIX: resolvido bug ao fazer atribuição de inteiros"
-Mensagens de modificações que representam novas funcionalidades ou algo
visível/relevante para o usuário devem iniciar com NEW:
$svn ci A.cpp -m"NEW: estruturas caso/repita agora são suportados"
-Mensagens que devem ser ignoradas devem iniciar com DEVNULL
$svn ci A.cpp -m"DEVNULL: identacão de código corrigida"
Ex 3: Misturando tudo:
$ svn ci -m"-Função func() renomeada para f()
> BUGFIX:
> -Resolvido bug ao depurar arrays de literais
> -Resolvido bug ao fazer atribuição de inteiros
> NEW:
> -Adicionado suporte a estruturas caso/repita
> -Adicionado suporte a estruturas eterogêneas
> DEVNULL:
> -retirado texto commitado acidentalmente
> REGULAR:
> -Adicionado gerador de código para caso/repita"
No exemplo acima, 2 mensagens são de bugfix, 2 são de novidades,
1 será ignorada e 2 (a primeira e a última) são mensagens normais.
Portanto, todas as keywords são flags que marcam o texto a seguir em diante.
REGULAR, portanto, resolve para o default, que são mensagens normais.
Estas convenções devem ser seguidas para a geração de arquivos ChangeLog
e NEWS automatizada. ChangeLog reunirá todas as modificações feitas em um
período, ignorando mensagens marcadas com DEVNULL, e exibindo mensagens
normais e de bugfix. O arquivo NEWS conterá mensagens marcadas com NEW
e bugfixes.
Além do mais, BUGFIX pode ser seguido de um número (ie #1234), que representa
o número do bug em um sistema de gerencia de bugs, como bugzilla. Porém
ainda não usamos tal sistema.
o Unit Testing
-Todo código que pode se beneficiar de testes automatizados *devem* ter testes
automatizados. Versões de nós mesmos no futuro agradecem.
-Mensagens de commit para arquivos de testes não são tão obrigatórios.
Use o bom senso para decidir se a descrição do commit ajudaria ou não.
TODO: explicar a infraestrutura de testes (quando houver uma)
Instalação Usando os Fontes
===========================
o Pré-requisitos
- ANTLR:
Ferramenta para construção de compiladores (testado com v2.7.5).
http://www.antlr.org
- Perl Compatible Regular Expressions (testado com v6.4):
Biblioteca de expressões regulares.
http://www.pcre.org/
- NASM - The Netwide Assembler (testado com v0.89.39):
Assembler usado para compilação.
http://sourceforge.net/projects/nasm
A instalação destes componentes está além do escopo deste documento.
o Comandos para compição e instalação padrão, assumindo um ambiente
GNU (GNU/Linux, MS Windows + MingW ou Cygwin, etc):
$ tar xvfz gpt-xxx.tar.gz
$ cd gpt-xxx
$ ./configure
$ make
$ make install
Se precisar de acesso root para o diretório alvo:
$ su
# make install
o Opções de configuração
ANTLR:
Se você instalou o ANTLR em um diretório não-padrão ou se o
binário "antlr" não pode ser encontrado pela variável de
ambiente PATH, use o argumento "--with-antlr-path".
Exemplo:
$ ./configure --with-antlr=/path/to/antlr
de forma que "/path/to/antlr" seja o caminho do antlr no sistema.
Devel:
Se você deseja que a biblioteca dinâmica (.so) e headers do
compilador sejam instalados no sistema, execute o script
"configure" da seguinte forma:
$ ./configure --enable-install-devel
Essa opcao é nescessária se você deseja utilizar a opção
"análise em segundo plano" do programa GPTEditor.
Nota: para desinstalar apenas os arquivos devel (header e libs) use:
# make uninstall-devel
o Biblioteca padrão
Para utilizar a (pseudo) biblioteca padrão distribuida neste pacote
deve-se adicionar as variáveis de ambiente a variável GPT_INCLUDE
contendo o caminho do arquivo base.gpt. Exemplo (shell bash):
Adicione ao script de inicialização de ambiente:
export GPT_INCLUDE="/usr/local/lib/gpt/base.gpt"
Outros arquivos podem ser incluídos, separando os caminhos por ":".
o Outras opções
Para maiores detalhes, leia INSTALL.default
o Se o código fonte foi baixado diretamente do repositório, é necessário
gerar o script "configure", executando o seguinte comando:
$ make -f Makefile.cvs
Basic Installation
==================
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using `csh' on an old version of System V, you might need to type
`sh ./configure' instead to prevent `csh' from trying to execute
`configure' itself.
Running `configure' takes a while. While running, it prints some
messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Type `make install' to install the programs and any data files and
documentation.
4. You can remove the program binaries and object files from the
source code directory by typing `make clean'.
Compilers and Options
=====================
Some systems require unusual options for compilation or linking that
the `configure' script does not know about. You can give `configure'
initial values for variables by setting them in the environment. Using
a Bourne-compatible shell, you can do that on the command line like
this:
CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
Or on systems that have the `env' program, you can do it like this:
env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
Compiling For Multiple Architectures
====================================
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you must use a version of `make' that
supports the `VPATH' variable, such as GNU `make'. `cd' to the
directory where you want the object files and executables to go and run
the `configure' script. `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.
If you have to use a `make' that does not supports the `VPATH'
variable, you have to compile the package for one architecture at a time
in the source code directory. After you have installed the package for
one architecture, use `make distclean' before reconfiguring for another
architecture.
Installation Names
==================
By default, `make install' will install the package's files in
`/usr/local/bin', `/usr/local/man', etc. You can specify an
installation prefix other than `/usr/local' by giving `configure' the
option `--prefix=PATH'.
You can specify separate installation prefixes for
architecture-specific files and architecture-independent files. If you
give `configure' the option `--exec-prefix=PATH', the package will use
PATH as the prefix for installing programs and libraries.
Documentation and other data files will still use the regular prefix.
If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving `configure' the
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
Optional Features
=================
Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System). The
`README' should mention any `--enable-' and `--with-' options that the
package recognizes.
For packages that use the X Window System, `configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the `configure' options `--x-includes=DIR' and
`--x-libraries=DIR' to specify their locations.
Specifying the System Type
==========================
There may be some features `configure' can not figure out
automatically, but needs to determine by the type of host the package
will run on. Usually `configure' can figure that out, but if it prints
a message saying it can not guess the host type, give it the
`--host=TYPE' option. TYPE can either be a short name for the system
type, such as `sun4', or a canonical name with three fields:
CPU-COMPANY-SYSTEM
See the file `config.sub' for the possible values of each field. If
`config.sub' isn't included in this package, then this package doesn't
need to know the host type.
If you are building compiler tools for cross-compiling, you can also
use the `--target=TYPE' option to select the type of system they will
produce code for and the `--build=TYPE' option to select the type of
system on which you are compiling the package.
Sharing Defaults
================
If you want to set default values for `configure' scripts to share,
you can create a site shell script called `config.site' that gives
default values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists. Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
A warning: not all `configure' scripts look for a site script.
Operation Controls
==================
`configure' recognizes the following options to control how it
operates.
`--cache-file=FILE'
Use and save the results of the tests in FILE instead of
`./config.cache'. Set FILE to `/dev/null' to disable caching, for
debugging `configure'.
`--help'
Print a summary of the options to `configure', and exit.
`--quiet'
`--silent'
`-q'
Do not print messages saying which checks are being made.
`--srcdir=DIR'
Look for the package's source code in directory DIR. Usually
`configure' can determine that directory automatically.
`--version'
Print the version of Autoconf used to generate the `configure'
script, and exit.
`configure' also accepts some other, not widely useful, options.
# not a GNU package. You can remove this line, if
# have all needed files, that a GNU package needs
AUTOMAKE_OPTIONS = foreign 1.4
SUBDIRS = src doc exemplos lib
EXTRA_DIST = INSTALL.default ChangeLog HACKING THANKS README.en README.pt_BR
uninstall-devel:
rm -rf $(includedir)/${PACKAGE}
rm -f $(libdir)/libgportugol*
This diff is collapsed.
Sumário de mudanças
-------------------
24 de Junho de 2008 * gpt 1.0.2
* Correção de bugs relacionados à compilação com gcc 4.3
* O programa GPT agora depende da biblioteca libgportugol
18 de Março de 2008 * gpt 1.0.1
* Suporte exclusivo para arquivos fontes escritos em UTF-8.
* (Win) Adaptação do programa Notepad++ para ser usado com o compilador.
* (Win) Novo instalador para sistemas MS Windows.
* (Win) Adição do script gptshell.bat.
* Correção de bug relativo aos flags de tradução do compilador.
* Diversos outros bugs corrigidos.
08 de Abril de 2006 * gpt 1.0
* Adição de arquivo com funções básicas (base.gpt).
* Melhorias no modulo de depuração.
* Revisão e correção de mensagens de erro de compilação.
* Correção de bugs na compilação em GNU/Linux (cabeçalho ELF).
* Correção de bugs na compilação (declaração de variável local shadows variável
global indefinidamente, ocasionando possíveis crashes).
* Correção de bugs na compilação e tradução (expressões envolvendo literais).
* Correção de bugs na compilação e tradução (inicialização de matrizes de
literais).
* Correção de bugs na análise semântica (avaliação de parâmetros de função).
* Correção de bugs na compilação (parâmetros de função).
* Correção de bugs na análise sintática (expressões sem parêntesis causando
crashes).
* Correção de bugs na tradução para C (expressões faltando e/ou com
precedência incorreta).
* Correção de bugs na tradução para C (expressões envolvendo valores literais).
* Correção de bugs na interpretação (expressões envolvendo valores reais
calculadas incorretamente).
* Correção de bugs na interpretação (avaliação de diversas operações).
* Correção de bugs na interpretação (enunciado "se" entrando em loop infinito).
* Correção de bugs na interpretação (retorno de dados em funções).
* Correção de bugs na compilação (avaliação de subtração envolvendo valores
reais).
* Correção de bugs na compilação (avaliação de expressões relacionais
envolvendo valores reais).
* Correção de bugs na compilação (operador unário de negação).
* Correção de bugs na compilação (retorno de valores de tipos diferentes
sem utilizar casting).
* Correção de bugs na análise semântica (avaliação de retorno de valores
em funções).
* Correção de bugs na compilação (casting de parâmetro inteiro para
real e real para inteiro).
* Adicionado suporte a compilação de algoritmos usando mais de um arquivo.
* Adicionado suporte a variável de ambiente GPT_INCLUDE para incluir algoritmos
automaticamente.
* Revisão da man-page.
* Atualização do manual.
* Nome do algoritmo é usado para criar arquivo executável ao invés de usar
"a.exe" ou "a.out".
05 de Abril de 2006 * gpt 0.9.2
* Correção de um bug na avaliação de expressões aritméticas.
31 de Março de 2006 * gpt 0.9.1
* Correção de um bug de compilação relacionado a função "leia".
08 de Março de 2006 * gpt 0.9b
* Implementação da geração de código executável (x86, PE/ELF,
NASM como backend).
* GPT portado para MS Windows (testado com compilador MingW32).
* Vários bugfixes (ver ChangeLog).
27 de Janeiro de 2006 * gpt 0.8b
* Primeira versão publicada.
* Recursos oferecidos:
+interpretar/depurar;
+traduzir algoritmos para C;
+compilar algoritmos (traduzindo e usando o GCC como backend).
G-Portugol - version: 1.0.1
=========================
o About
G-Portugol is a structured programming language, based on the portuguese
language (therefore, targeted to the portuguese-speakers crowd) and
used mainly to teach programming. More information in the README.pt_BR file.
Website: http://gpt.berlios.de
Mailing List: https://lists.berlios.de/mailman/listinfo/gpt-usuarios
Author: Thiago Silva <tsilva@sourcecraft.info>
o Copyright
See the COPYRIGHT file
G-Portugol - versão: 1.0.1
========================
o Sobre a linguagem
G-Portugol é um dialeto da linguagem/pseudo-código portugol (ou
portugês estruturado), que é muito usada para descrever algoritmos em
português, de forma livre e espontânea. Em geral, livros dedicados ao ensino
de algoritmos, lógica e estruturas de dados utilizam alguma forma
dessa linguagem.
A proposta de G-Portugol é disponibilizar uma implementação da
linguagem portugol, fornecendo ferramentas que ofereçam recursos de edição,
compilação, execução e depuração de programas escritos nessa linguagem, de
forma a favorecer estudantes que dão os primeiros passos no aprendizado de
desenvolvimento de softwares, bem como professores que ensinam disciplinas
relacionadas a computação. Portanto, seu foco é primariamente didático.
Se encontram disponíveis atualmente um compilador, tradutor e interpretador
para a linguagem (GPT) e um ambiente visual simples (GPTEditor) que permite a
edição, execução e depuração de programas escritos em G-Portugol.
o O programa GPT
GPT é o programa que implementa a linguagem G-Portugol, permitindo:
-compilar algoritmos;
-traduzir algoritmos para C;
-executar algoritmos de forma interpretada;
-depurar algoritmos interativamente.
Embora se encontre usável, o GPT não está imune a bugs. Além do mais,
alguns recursos podem estar faltando. Portanto, convido-lhes a participar,
enviando sugestões, críticas, códigos-fonte, patches, idéias e algoritmos que
não são processados corretamente pelo GPT.
o Maiores informações
Website: http://gpt.berlios.de
Lista de discussao: https://lists.berlios.de/mailman/listinfo/gpt-usuarios
Autor: Thiago Silva <tsilva@sourcecraft.info>
o Copyright
Esse pacote é distribuído nos termos da GNU GENERAL PUBLIC LICENSE v2
(ver arquivo COPYRIGHT para maiores detalhes)
Adorilson Bezerra de Araujo <adorilson [a] gmail com>
Alex Garzão <alexgarzao [a] gmail com>
Everson Santos Araujo <everson [a] por com br>
Marcelo Jorge Vieira (metal) <metal [a] alucinados com>
This diff is collapsed.
This diff is collapsed.
/* config.h.in. Generated from configure.ac by autoheader. */
/* Define to 1 if you have the <dlfcn.h> header file. */
#undef HAVE_DLFCN_H
/* Define to 1 if you have the <inttypes.h> header file. */
#undef HAVE_INTTYPES_H
/* Define to 1 if you have the <memory.h> header file. */
#undef HAVE_MEMORY_H
/* Define to 1 if you have the <stdint.h> header file. */
#undef HAVE_STDINT_H
/* Define to 1 if you have the <stdlib.h> header file. */
#undef HAVE_STDLIB_H
/* Define to 1 if you have the <strings.h> header file. */
#undef HAVE_STRINGS_H
/* Define to 1 if you have the <string.h> header file. */
#undef HAVE_STRING_H
/* Define to 1 if you have the <sys/stat.h> header file. */
#undef HAVE_SYS_STAT_H
/* Define to 1 if you have the <sys/types.h> header file. */
#undef HAVE_SYS_TYPES_H
/* Define to 1 if you have the <unistd.h> header file. */
#undef HAVE_UNISTD_H
/* Name of package */
#undef PACKAGE
/* Define to the address where bug reports for this package should be sent. */
#undef PACKAGE_BUGREPORT
/* Define to the full name of this package. */
#undef PACKAGE_NAME
/* Define to the full name and version of this package. */
#undef PACKAGE_STRING
/* Define to the one symbol short name of this package. */
#undef PACKAGE_TARNAME
/* Define to the version of this package. */
#undef PACKAGE_VERSION
/* Define to 1 if you have the ANSI C header files. */
#undef STDC_HEADERS
/* Version number of package */
#undef VERSION
This diff is collapsed.
This diff is collapsed.
#Nota windows:
#aclocal do cygwin fica feliz somente
#tiver quebra de linha no format UNIX
AC_PREREQ(2.60)
AC_INIT(gpt, 1.0.2)
AM_INIT_AUTOMAKE(gpt, 1.0.2)
AC_CONFIG_HEADER([config.h])
AC_LANG(C++)
AC_PROG_CXX
AM_PROG_LIBTOOL
dnl------------------------------
dnl debug options
dnl------------------------------
AC_ARG_ENABLE(debug,
AC_HELP_STRING([--enable-debug=ARG],[enables debug symbols (yes|no|full) [default=no]]),
[
case $enableval in
yes)
use_debug_code="yes"
use_debug_define=yes
;;
full)
use_debug_code="full"
use_debug_define=yes
;;
*)
use_debug_code="no"
use_debug_define=no
;;
esac
],
[use_debug_code="no"
use_debug_define=no
])
CXXFLAGS=
if test "$use_debug_code" != "no"; then
if test $use_debug_code = "full"; then
CXXFLAGS="-g3 $CXXFLAGS"
else
CXXFLAGS="-g -O2 $CXXFLAGS"
fi
else
CXXFLAGS="-O2 $CXXFLAGS"
fi
if test "$use_debug_define" = "yes"; then
CXXFLAGS="-DDEBUG $CXXFLAGS"
fi
dnl------------------------------
dnl Check SO
dnl------------------------------
if test $version_type = "windows"; then
SO_WINDOWS="yes"
else
SO_WINDOWS="no"
fi
AM_CONDITIONAL(BUILD_DEBUGGER, test x$SO_WINDOWS = xno)
dnl------------------------------
dnl Checks for ANTLR
dnl------------------------------
AC_PATH_PROG(ANTLR_BIN, antlr)
if test "x${ANTLR}" = "x"; then
AC_PATH_PROG(ANTLR_BIN, runantlr)
fi