Como alguém lidaria com dependências externas em um projeto de código aberto?

Quando alguém escreve um projeto de código aberto e usa o Google Code ou GitHub e deseja usar uma biblioteca como Lua, como fazer isso?

• A dependência deve ser incluída no repositório?
• A dependência deve ser criada a partir do mesmo script de compilação que o resto do projeto ou de um script de compilação separado?

Dado que a biblioteca não precisa de instalação antes da compilação.

Eu recomendo a leitura da documentação do Git sobre submódulos ; Ele resolve esse problema, assumindo que todas as suas fontes usem o Git. Caso contrário, você sempre pode configurar um repositório Git para fins de integração. O esforço é trivial e a recompensa é significativa.

A dependência deve ser incluída no repositório?

Eu acho que as dependências sempre devem ser incluídas no repositório, desde que incluí-las não viole nenhum termo de uso. Poucas coisas são mais irritantes do que ter que encontrar as versões corretas das dependências corretas manualmente antes de poder fazer uma compilação. Claro, isso é fácil quando você tem ferramentas automatizadas para fazer isso por você, que podem encontrar e baixar a dependência certa, mas e se você não estiver conectado à Web no momento ou se o servidor estiver inoperante ou o projeto da dependência foi descontinuado completamente e colocado offline? Sempre inclua as dependências, se possível.

A dependência deve ser criada a partir do mesmo script de compilação que o resto do projeto ou de um script de compilação separado?

A menos que haja um bom motivo para compilar a partir do código-fonte, use versões pré-compiladas.

E por que não fornecer opções no script de construção? Uma opção simples para escolher se as dependências também devem ser compiladas ou não. Se o usuário optar por compilar as dependências também, basta chamar seus próprios scripts de construção a partir do script de construção do seu produto. Assim, o usuário pode chamar os scripts de construção das dependências manualmente ou optar por criar uma construção completa de tudo. Mas eu entregaria as dependências como binários, se não houver um bom motivo para compilá-las a partir das fontes. Acho que no mundo do código aberto, algumas licenças exigem que você distribua as fontes junto com o seu produto, mas isso não significa que você não pode tê-las pré-compiladas.

Em resumo: forneça todo um pacote de trabalho independente, se possível. Isso proporcionará a maior comodidade aos seus usuários.

Isso pode ou não se aplicar ao seu caso de uso, mas o que fazemos no trabalho é incluir uma pasta "Referências" em cada ramificação. Colocamos DLLs de terceiros aqui. Isso causa muita duplicação de binários relativamente imutáveis ​​no controle de origem, mas o armazenamento é barato e a qualquer momento cada ramo e tag possui exatamente as dependências (e versão!) Que espera.

Nós pré-compilamos as dependências e movemos os binários compilados para essa pasta. Nossa própria biblioteca compartilhada interna também é tratada dessa maneira. Dessa forma, a mesma técnica funciona para bibliotecas proprietárias pré-compiladas, bibliotecas de código aberto e bibliotecas internas.

No que diz respeito a responder à sua pergunta agora que a reli, faça o mesmo e mencione apenas que o seu projeto usa uma versão 1.3.5 pré-compilada do Lua.

A dependência deve ser incluída no repositório?

Ele pode ser referenciado no repositório (por qualquer método utilizável para SCM), se essa dependência for parte integrante do produto (dependência da origem), não dependência binária, que pode ser resolvida separadamente

A dependência deve ser criada a partir do mesmo script de compilação que o resto do projeto ou de um script de compilação separado?

Não importa nada. Você pode preferir qualquer método, de acordo com seus requisitos (velocidade / transparência / capacidade de gerenciamento / etc)

Sendo uma loja Eclipse, começamos a usar o Buckminster para gerenciar nosso processo de compilação / montagem / implantação.

Nosso primeiro estágio foi retirar todas as nossas bibliotecas dependentes existentes e permitir que o buckminster cuide de materializar as corretas. Isso contribui para uma implantação muito mais rápida e menor.

O próximo passo será mover nosso svnrepositório monolítico para uma série de gitrepositórios modulares .

Não sei até que ponto o buckminster se integrava aos gitsubmódulos (ou subrepos mercuriais), mas é bom que o buckminster seja independente do VCS usado para qualquer componente.