Eu tenho a versão mais recente e inédita doctagscódigo fonte do repositório svn usando
svn co https://ctags.svn.sourceforge.net/svnroot/ctags
Executei o ./configure
, que falhou com o seguinte erro:
config.status: creating Makefile
config.status: WARNING: 'Makefile.in' seems to ignore the --datarootdir setting
config.status: error: cannot find input file: config.h.in
[mirror@home ctags-5.7]$ echo $?
1
Então criei um arquivo vazio chamado config.h.in
e agora ./configure
consegui.
configure: creating ./config.status
config.status: creating Makefile
config.status: WARNING: 'Makefile.in' seems to ignore the --datarootdir setting
config.status: creating config.h
[mirror@home ctags-5.7]$ echo $?
0
A execução make
ainda falhou.
[mirror@home ctags-5.7]$ make
gcc -I. -I. -DHAVE_CONFIG_H -g -O2 -c args.c
In file included from args.c:17:
/usr/include/stdio.h:88: error: two or more data types in declaration specifiers
make: *** [args.o] Error 1
- Por que isso não funcionou?
- Como faço para construir ctags a partir do repositório svn?
Responder1
Ele falha porque (em contraste com os tarballs de origem preparados) o svn repositroy não contém arquivos intermediários usados peloferramentas automáticas.
Não estou muito familiarizado com AT ou ctags, mas tente correr automake
e autoconf
antes de correr ./configure
novamente. O procedimento provavelmente está localizado em algum lugar de um INSTALL
arquivo ou pasta de documentação, você pode querer procurar por isso.
Termo aditivo:
De acordo com um (não oficial)Construção do Gentoo, correr autoreconf
deve ser suficiente.
Adendo 2:
Como eu disse, não sou nenhum guru de AT, disseram-me que há apenas um número de dois dígitos no mundo.
config.h
não está incluído no repositório svn porque não foi escrito por um ser humano e depende apenas dos outros arquivos do repositório. Os desenvolvedores precisam refazê-lo com frequência, pois mudam as coisas, então seria apenas um arquivo extra para baixar e excluir imediatamente ao verificar as alterações.
Por outro lado,éincluídos nos tarballs para tornar a construção do software menos penosa. Acredito que também evita alguns problemas quando as pessoas têm versões de AT diferentes das dos desenvolvedores. Não há nenhuma desvantagem real neste caso, pois não depende de qual sistema ou arquitetura você constrói e os outros arquivos "geralmente não são" modificados ao construir a partir do tarball. Isto é, a menos que você tenha alguns patches que precisa aplicar. Então você pode precisar regenerar algo de qualquer maneira.
Minha abordagem em relação à TA é tentar coisas diferentes até que funcione ou eu desista. Arquivos diferentes surgem de comandos diferentes, e alguns dos comandos iniciam outros comandos magicamente. Na página da Wikipedia, há um fluxograma. Não acho útil, mas talvez você possa.
Eu sugiro ficar longe disso. Se você acha que precisa usá-lo em seu próprio projeto, usecmfazerouescárniosou qualquer outra coisa que funcione bem e seja simples naquele momento.
Responder2
Eu tive um problema semelhante no meu sistema Linux, que resolvi executando "autoheader" e "autoconf" (do subdiretório "trunk" do tarball descompactado)antesexecutando "./configure". As operações subsequentes de “make” e “make install” foram executadas sem problemas.
Parece que o autoconf sabe como configurar a partir do configure.at (que estava no tarball), mas você deve executar o autoheader primeiro para criar os arquivos .in que são usados pelo configurado para gerar os arquivos de cabeçalho que são usados quando você realmente executa ./configure.
Responder3
Por que você não faz $ sudo apt-get install exuberant-ctags
ou o que quer que se adapte ao seu sabor do Linux?