Definição de um ambiente de tempo de execução

Question

Eu preciso definir um ambiente de tempo de execução para o meu desenvolvimento. A primeira idéia é, naturalmente, não reinventar a roda. Eu baixei MacPorts, easy_install usado, Fink tentou. Eu sempre tive problemas. Neste momento, por exemplo, eu não sou capaz de compilar scipy porque os MacPorts instalador quer baixar e instalar gcc43, mas isso não compila no Snow Leopard. Um bug está aberto para este problema, mas eu estou basicamente amarrado a eles para o meu tempo de execução para ser utilizável.

A técnica que eu aprendi há algum tempo atrás, era escrever um makefile para baixar e construir as runtime / libs com versões claramente especificados de bibliotecas e utilitários. Este antecede a / Fink / MacPorts abordagem apt, mas você tem muito mais controle sobre ele, embora você tem que fazer tudo à mão. Claro, isso pode se tornar um pesadelo por conta própria se o tempo de execução cresce, mas se você encontrar um problema, você pode usar patch e corrigir o problema no pacote baixado, então construí-lo.

Eu tenho várias perguntas:

• O que é a sua técnica para preparar um tempo de execução / acervo da biblioteca definida pelo bem para o seu desenvolvimento?
• MacPorts Does / Fink / whatever me permite a mesma flexibilidade de rehacking se algo der errado?
• Considerando a minha solução makefile, quando o meu software está definitivamente fora para download, quais são as suas sugestões sobre como resolver os problemas potenciais entre meu ambiente de desenvolvimento ea plataforma real em máquinas do meu usuário?

Editar : O que eu não entendo, em particular, é que outros projetos não me dê sugestões. Por exemplo, eu apenas o download scipy, uma biblioteca complexa, com muitas dependências. Os desenvolvedores devem ter toda a configuração deps antes de trabalhar nele. Apesar disso, não há nada no svn que cria esse ambiente.

Editar : Adicionado uma recompensa para a questão. Penso que esta é uma questão importante e que merece para obter mais respostas. Vou considerar melhores essas respostas com exemplos do mundo real, com especial atenção para quaisquer problemas surgiu e sua solução.

perguntas adicionais para inspirar para a Recompensa:

• Você executa testes em seu ambiente (para verificar a instalação adequada, por exemplo, em uma máquina de integração)?
• Como você incluir o seu meio ambiente em tempo de envio? Se for C, você estaticamente vinculá-lo, ou transportar a biblioteca dinâmica, mexer o LD_LIBRARY_PATH antes de executar o executável? O que sobre o mesmo assunto para Python, Perl e outras?
• Você ficar com o tempo de execução, ou atualizá-lo como o tempo passa? Você download de pacotes de "tronco" de suas bibliotecas de dependência ou uma versão corrigida?
• Como você lida com situações como: foo biblioteca precisa Python 2.5, mas você precisa desenvolver em Python 2.4, porque barra de biblioteca não funciona com o Python 2.5
?

Answer 1

Nós usamos um script CMake que gera Makefiles que download (principalmente através de SVN) / configure / construir todas as nossas dependências. Por CMake? Multi plataforma. Isso funciona muito bem, e nós apoiamos invocação de scons / autopain / cmake. À medida que construímos em várias plataformas (Windows, MacOSX, um grupo de variantes do Linux) também apoiamos diferentes sinalizadores de compilação etc baseados no sistema operacional. Normalmente uma biblioteca tem uma configuração padrão, e se encontramos um sistema que precisa de configuração especial a configuração é substituída por uma configuração especializada. Isso funciona muito bem. Nós realmente não encontrar qualquer solução pronta que se encaixam nosso propósito.

Dito isto, é um PITA para obtê-lo instalado e funcionando - há um monte de botões para ligar quando você precisa para suportar vários sistemas operacionais. Eu não acho que ele vai se tornar um maintainance-pesadelo como as dependências são bastante fixo (bibliotecas são atualizados regularmente, mas raramente introduzir um novo).

Answer 2

virtualenv é bom, mas não pode fazer mágica - por exemplo se você quiser usar uma biblioteca que só deve ter Python 2.4 e outro que necessita absolutamente de 2,5 vez, você está fora de sorte. Nem pode VIRTUALENV (ou qualquer outra ferramenta) ajuda quando há um novo lançamento de um sistema operacional e metade das ferramentas e c só não apoiá-lo, no entanto, como você mencionou para o Snow Leopard: alguns problemas são simplesmente impossível de resolver (duas bibliotecas com absolutamente conflitantes necessidades dentro da mesma compilação), outros apenas exigem paciência (até que todas as ferramentas que você precisa são portados para o lançamento do novo sistema operacional, você só precisa ficar com o lançamento oS anterior).