Como devo distribuir um módulo Perl pré-construído e para qual versão do Perl eu construo?

Question

Esta é provavelmente uma pergunta de várias partes. Antecedentes: temos uma biblioteca nativa (C ++) que faz parte do nosso aplicativo e conseguimos usar o SWIG para gerar um invólucro Perl para esta biblioteca. Agora gostaríamos de distribuir este módulo Perl como parte de nosso aplicativo.

Minha primeira pergunta - como devo distribuir este módulo? Existe uma maneira padrão de empacotar módulos Perl pré-construídos? Eu sei que há PPM para a distro Activestate, mas também preciso distribuir isso para os sistemas Linux. Não tenho certeza de quais arquivos são necessários para distribuir, mas acho que são os arquivos PM e, portanto, no mínimo.

Minha próxima pergunta - parece que talvez eu precise criar meu projeto de módulo para cada versão do Perl que eu quero apoiar. Como sei para quais versões Perl devo construir? Existem diretrizes padrão ... ou melhor ainda, uma maneira de construir um pacote que funcione com várias versões do Perl?

Desculpe se minhas perguntas não fazem sentido - sou bastante novo nos aspectos do módulo compilado de Perl.

Esclarecimento: a fonte compilada subjacente é Proprietário (Fonte fechado), por isso não posso simplesmente enviar o código -fonte e os artefatos apropriados para o pacote. Gostaria de poder, mas isso não vai acontecer neste caso. Assim, preciso de um esquema SANE para embalar arquivos binários pré -construídos para o meu módulo.

Answer 1

Eu cuido do DBD :: Informix, um dos módulos de driver do banco de dados PERL que funcionam com o DBI (interface do banco de dados PERL). As bibliotecas subjacentes usadas para se conectar ao IBM Informix Dynamic Server (IDs) são proprietárias, mas o código DBD :: Informix em si não é. Distribuo esse código na CPAN, da mesma forma que qualquer outro módulo Perl. As pessoas podem fazer o download dessa fonte e (desde que tenham o Informix ClientDK instalado em sua máquina - e Perl e DBI e assim por diante), elas podem criar DBD :: Informix para trabalhar com o Perl instalado.

Eu aconselharia fortemente que você organize que seu código de interface Perl seja disponibilizado em forma de origem, mesmo que a biblioteca que ele interface seja proprietária. Isso permite que as pessoas instalem o código com qualquer versão do Perl que elas possuam - sem exigir que você lide com inconsistências.

Se você ainda deseja fornecer suporte binário, precisará descobrir quais plataformas deseja suportar e criar o módulo com a versão padrão do Perl em cada uma dessas plataformas. Isso fica confuso. Você precisa de acesso a uma instância de cada máquina. É verdade que as máquinas virtuais facilitam isso, mas ainda é complicado e o número de plataformas e versões só cresce. Mas você ainda precisa apoiar pessoas que não usam a versão padrão do Perl em sua máquina - é por isso que a interface Perl Wrapper precisa ser fornecida no formulário de origem.

Answer 2

AVISO LEGAL: Não tenho experiência em criar pacotes binários que podem ser facilmente instalados. Portanto, estou fazendo este post CW para facilitar a adição de seus conselhos.

Você deve disponibilizar a distribuição no formulário de origem para que ela possa ser compilada em cada sistema adaptado de acordo com as especificidades desse sistema. Eu realmente gosto Módulo :: Build para aquele propósito.

Para usuários do Activestate no Windows, você provavelmente deseja ter quatro ou seis PPMs com base se deseja apoiar 5.6. Empacote versões de 32 e 64 bits para cada um dos 5.6, 5.8 e 5.10. Use a versão de mingw você pode instalar usando ppm Para compilar os módulos para preservar a compatibilidade binária.

Outra opção é usar PAR :: Packer e distribua sua aplicação em um arquivo par. Nesse contexto, Par :: webstart Pode ser útil, embora eu não tenha tentado. Eu tive sucesso com os arquivos do PAR no passado, no entanto.