Por que houve tão pouca inovação com autoconf configurar scripts no ecossistema Unix e Linux? [fechadas]

Question

Perde-se muito tempo no momento de ./configure; especialmente quando as dependências estão faltando e a subsequente chamada dele.

Eu li muitos tópicos sobre este assunto, citando que armazenar em cache o resultado da configuração de scripts para reutilização com outros scripts de configuração é propenso a erros devido a resultados obsoletos, coisas saindo de sincronia, e que criar uma implementação comum para compartilhar os resultados seria "muito difícil" [1] .

Eu gostaria de observar que estou ciente de que os scripts de configuração já suportam o cache, mas isso é desativado por padrão [2] .

Se as distribuições já fornecem gerenciadores de pacotes que entendem interdependências e eles mesmos já sabem o que seriam todas as dependências de fontes comuns (ou até mais comuns), por que não há um padrão para algum tipo de cache de configuração disponível na distribuição? Pode-se supor que determinadas condições, que podem ser avaliadas pelo gerenciador de pacotes, não precisem ser executadas em muitos desses testes. Ou, no mínimo, não a menos que haja uma falha durante a configuração.

Apesar de existirem vários outros sistemas concorrentes, acho que o configure ainda é o mais comum. Esses scripts são baseados em shell, single-threaded, propensos a erros, geralmente fornecem diagnósticos crípticos ou sem diagnóstico, e geralmente são extremamente lentos. Não é incomum para mim encontrar uma falha com um script de configuração ou compilação devido a uma dependência ausente que não fazia parte do configure.

Isso já foi abordado por alguma distro? Por exemplo, o Gentoo faz uma quantidade enorme de compilação local. Eles otimizam tudo isso?

Eu não estou procurando por recomendações para sistemas de compilação, mas sim uma perspectiva histórica ou cultural sobre por que as coisas continuam a depender tanto do autoconf e configurar para projetos modernos. Isso pode muito bem cair dentro dos limites da opinião, mas eu acho que este é um tópico extremamente interessante que pode ter seu quinhão de fatos baseados em convenções de construção, política da empresa e costumes de barba.

Um argumento semelhante pode ser feito de listas de discussão que são arcaicas em comparação com formas modernas de colaboração na web, mas elas também são simples e funcionam exatamente da mesma forma que sempre fizeram com pouca ou nenhuma mudança, dada sua simplicidade. Talvez autoconf segue um destino semelhante? (Disclaimer: Eu realmente amo listas de discussão com qualquer frustração sendo resultado de um fraco suporte por parte do cliente de email).

    

Answer 1

Qualquer resposta será pelo menos um pouco especulada IMO, pois o que constitui "inovação" difere de pessoa para pessoa (e se é uma coisa boa!) Porque autoconf foi projetado para ser agnóstico em termos de linguagem e arquitetura na maior parte, há muita inércia mantendo o desejo de mudar: você tem que considerar que alguns scripts de configuração provavelmente já têm décadas, e as pessoas não querem ter que reescrever coisas que funcionem.

Algumas das restrições que autoconf enfrenta são arquiteturais: por exemplo, como você pode usar o multithreading em uma etapa que verifica o multithreading? A versão 2.5 de libfoo funcionará com um programa que diz que precisa da versão 1.8? Outros problemas que você cita geralmente são devido à subespecificação de dependências: Eu tive muitos scripts de configuração que simplesmente esquecem de listar todas as suas dependências diretas. Por fim, autoconf parece ter um número bastante limitado de mantenedores, dificultando grandes mudanças.

Em alguns aspectos, os gerentes de pacotes são onde a inovação acontece. Eles podem lidar com conceitos como pacotes diferentes que precisam de versões diferentes da mesma biblioteca, identificar soluções alternativas para dependências que não estão mais disponíveis e (para distribuir fontes como o Gentoo) fornecer patches para limpar scripts de configuração e código-fonte para que funcionem corretamente .

    

Answer 2

Autoconf naturalmente armazena os resultados e, se você usá-lo corretamente, você raramente executa configure .

Meu projeto schilytools (> 4000 arquivos de código, aproximadamente 770000 linhas de código) precisa atualmente de aprox. 800 testes de autoconf. Executar todos os testes leva 28 segundos em um laptop Intel de 2,7 GHz, 2-3 horas em uma caixa de pizza HP-9000 de 1995, 4-6 horas em um Sun3 / 60 de 1996 e aprox. um dia em um Vax 11/780.

Eu ainda não tenho que me preocupar, pois o script de configuração é alterado apenas aprox. 5 vezes por ano e reexecutando configure leva 4 segundos no laptop Intel, pois todos os outros testes são armazenados em cache. É claro que tenho uma regra make que faz com que configure seja executado novamente somente se os resultados do configure estiverem desatualizados.

As pessoas a jusante têm uma visão diferente. Eles tomam o projeto como um pacote descartável e executam um% de tempo de execução completo 30 vezes por ano e isso leva 15 minutos por ano.

Eu do outro lado só tenho que esperar 25 segundos por ano ...

Então, o problema é como as pessoas a jusante usam o software.