Por que eu falhei em construir ctags para o vim?

Question

Eu obtive a versão mais recente e inédita do código-fonte ctags do repositório svn usando

svn co https://ctags.svn.sourceforge.net/svnroot/ctags

Eu corri ./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

Em seguida, criei um arquivo vazio chamado config.h.in e agora ./configure foi bem-sucedido.

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 de 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 eu construo ctags do repositório svn?

Answer 1

Ele falha porque (ao contrário dos tarballs de origem preparados) o svn repositroy não contém arquivos intermediários usados por autotools .

Não estou muito familiarizado com AT ou ctags, mas tente executar automake e autoconf antes de executar ./configure novamente. O procedimento provavelmente está localizado em algum lugar em um arquivo INSTALL ou em uma pasta de documentação, você pode querer procurar por isso.

Adendo:

De acordo com um (não oficial) ebuild do Gentoo , executando autoreconf deve ser o suficiente.

Adendo 2:

Como eu disse, eu não sou nenhum guru, sou informado de 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 é escrito por um humano e depende apenas dos outros arquivos no repositório. Os desenvolvedores têm que refazê-lo frequentemente de qualquer maneira, já que eles mudam as coisas, então seria apenas um arquivo extra para baixar e, em seguida, excluir imediatamente ao verificar as alterações.

Por outro lado, ele é incluído nos tarballs para tornar a construção do software menos dolorosa. Eu acredito que também evita alguns problemas quando as pessoas têm diferentes versões de AT do que os desenvolvedores. Não há uma verdadeira parte de trás para ele neste caso, pois não depende de qual sistema ou arquitetura você construir e os outros arquivos "não são" modificados ao construir a partir do tarball. Ou seja, a menos que você tenha alguns patches, você precisa se inscrever. Então você pode precisar regenerar algo de qualquer maneira.

Minha abordagem para o TA é tentar coisas diferentes até que funcione ou eu desisto. Arquivos diferentes saem de comandos diferentes, e alguns dos comandos iniciam outros comandos magicamente. Na página da Wikipedia, há um fluxograma. Eu não acho útil, mas talvez você possa.

Eu sugiro ficar longe disso. Se você acha que precisa usá-lo para seu próprio projeto, use cmake ou scons ou qualquer outra coisa que funcione bem e seja simples nesse momento.

    

Answer 2

Eu tive um problema semelhante no meu sistema linux, que resolvi executando "autoheader" e "autoconf" (do subdiretório "trunk" do tarball descompactado) antes executando "./configure ". As operações subseqüentes "make" e "make install" foram executadas sem problemas.

Parece que o autoconf sabe como fazer o configure a partir do configure.at (que estava no tarball), mas você precisa 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 então usado quando você realmente executa ./configure.

    

Answer 3

Por que você não faz $ sudo apt-get install exuberant-ctags ou o que mais combina com seu sabor no Linux?