[Rio-pm] MakeFile

Domingo Junho 3 12:52:22 PDT 2012

2012/6/3 Stanislaw Pusep <creaktive em gmail.com>

> Concordo com ambos :)
> Alexei, o seu tutorial sobre Dist::Zilla me poupou algumas horas de
> tarefas repetitivas. Mas antes disso, eu escrevia Makefile.PL manualmente.
> Isso me fez passar menos raiva com a (falta de) documentação do
> Dist::Zilla. Ele é uma típica coisa "como não pensei nisso antes", tal qual
> "set -o vi" no Bash :P.
> É prático para quem conhece o bé-a-bá, mas pouquíssimo didático.
>

Então, ao invés de fazer as coisas como se fazia em 1997, ou se criar um
novo, por que não melhorar o que falta no Dist::Zilla (incluindo
documentação, que eu concordo, é um lixo) para podermos nos esquecer de vez
dos detalhes sórdidos?

>
> ABS()
>
>
>
>
> 2012/6/3 Alexei Znamensky <russoz em gmail.com>
>
>>
>> 2012/6/3 breno <breno em rio.pm.org>
>>
>>> Ao contrário do Stan, eu não recomendo o Dist::Zilla. Ou pelo menos
>>> não pra vc que está começando. Pode ser uma ótima ferramenta para
>>> alguns autores, mas se vc não entende a "mágica" que acontece por
>>> trás, pode se confundir e te deixar mais tempo configurando/depurando
>>> as ferramentas em vez de trabalhando no(s) seu(s) próprio(s)
>>> módulo(s).
>>>
>>
>> Ao contrário do Garu, eu não des-recomendo o Dist::Zilla. Eu acho que é
>> uma ferramenta fantástica para esconder do desenvolvedor de distribuições
>> os detalhes de um build. Ao invés de tentarmos difundir ao máximo os
>> detalhes, para que todos - teoricamente - saibam o que fazer quando houver
>> um problema, acho que é muito mais saudável para todos que os detalhes
>> sujos fiquem o mais escondidos e automatizados o possível, simplificando a
>> vida de todos, mas principalmente de quem está começando.
>>
>> Filosofando um pouco mais sobre o assunto, na rabeira de uma longa
>> conversa que eu e o Breno tivemos por telefone outro dia, eu fico pensando
>> que "More Than One Way To Do It" é muito bom como possibilidade, como para
>> ser usado em caso de exceção. Não deveria ser a regra. É muito bom que haja
>> 2,3,4, 5 formas diferentes de expressar orientação a objeto, contanto que
>> uma delas fosse uma "regra" e as outras fossem casos de exceção, aplicados
>> para necessidades específicas (e de preferência bem definidas, se não for
>> pedir muito). É muito bom estarmos todos produzindo e usando código livre,
>> e se eu quiser mudar algo eu posso simplesmente alterar e fazer o que eu
>> quiser, mas ó céus cada módulo que eu for fuçar é uma caixinha de
>> surpresas. Uns são feitos em Moose, outros em Mouse, tem um novo agora que
>> eu nem gravei o nome, tem os caras que fazem o bless na mão, e tem os caras
>> que fazem magia negra. Ou seja, se eu quiser ser um bom (=bondoso,
>> cooperativo, ativo, colaborativo, etc..) programador Perl, eu preciso ser
>> fluente em uns 5 ou 6 tipos diferentes de expressar a mesma idéia. Ao invés
>> de poder contar que algo vai ser de um jeito (ou de outro), e seguir
>> adiante, e produzir 5 ou 6 idéias novas.
>>
>> Fala-se, volta e meia, sobre produtividade em Perl e em Java, o
>> boilerplate code em Java é muito grande, etc.., mas toda vez que eles
>> (javeiros) precisam mexer em código dos outros, existe um padrão mínimo de
>> consistência esperado (claro, sempre há quem ferre com isso, em qualquer
>> idioma). Enquanto que, mexer em código dos outros, em Perl, como eu disse,
>> é um Kinder Ovo. You never know what you gonna get. Talvez esse seja o
>> motivo, na minha humirde opinião, pelo qual, eu percebo mais programadores
>> Perl no perfil "lobo solitário" do que em Java, por exemplo. É mais fácil
>> às vezes fazer um novo que entender o dialeto que o outro cara utiliza.
>>
>> my $0.02;
>>
>>
>>> Respondendo a sua pergunta, os arquivos Makefile.PL existem para a
>>> criação de "distribuições", que podem conter um ou mais módulos (além
>>> de scripts e outros arquivos). Quando vc faz uma distribuição, não tem
>>> problema se os módulos dentro dela dependerem de outro, contanto que
>>> esse outro também esteja dentro da distribuição (mas tenha cuidado com
>>> dependências circulares!).
>>>
>>> Há 3 construtores populares:
>>>
>>>  * ExtUtils::MakeMaker, a.k.a. EUMM (que vc já citou)
>>>  * Module::Build, a.k.a MB
>>>  * Module::Install, a.k.a. MI
>>>
>>> Embora o EUMM esteja no core, o M:I tem uma DSL bem fácil de usar e é
>>> utilizado em projetos de grande porte como Catalyst.
>>>
>>> Digamos que vc tenha a seguinte estrutura de módulos:
>>>
>>> lib/
>>> lib/MeuModulo.pm
>>> lib/MeuModulo
>>> lib/MeuModulo/Modulo1.pm
>>> lib/MeuModulo/Modulo2.pm
>>>
>>> e queira criar uma distribuição chamada "Minha-Dist" contendo isso
>>> tudo. A sintaxe do seu Makefile.PL é muito simples:
>>>
>>> ---------------8<---------------
>>> use inc::Module::Install;
>>>
>>> name    'Minha-Dist';
>>> all_from  'lib/MeuModulo.pm';
>>>
>>> WriteAll;
>>> --------------->8---------------
>>>
>>> Pronto. Fácil, não? Ao rodar "perl Makefile.PL" ele vai gerar alguns
>>> arquivos pra vc. Depois digite "make manifest" e "make dist" e vc terá
>>> um Minha-Dist-0.01.tar.gz te esperando, pronto pra ser instalado =)
>>>
>>> Algumas observações sobre o Makefile.PL acima:
>>>
>>> * "name" indica o nome da distribuição. A convenção é que vc use o
>>> mesmo nome do seu módulo base, o principal da sua distribuição (e que
>>> provavelmente a maioria das pessoas vai usar primeiro). No seu caso,
>>> suponho que o melhor "name" para a sua distribuição seria "MeuModulo".
>>>
>>> * "all_from" indica de onde o Makefile.PL deve extrair informações
>>> como versão, licença, autor, resumo, etc. Ele extrai essa informação
>>> de variáveis especiais de módulos (como "our $VERSION") e da
>>> documentação - então não esqueça de incluir os campos pertinentes na
>>> documentação (sempre uma boa prática!) ou terá que inclui-los
>>> explicitamente no Makefile.PL.
>>>
>>> Digamos que os módulos da sua distribuição dependam dos seguintes
>>> módulos EXTERNOS: File::Spec e Carp. Digamos ainda que, embora não
>>> seja uma dependência direta, se o usuário tiver instalado o módulo
>>> Data::Printer o seu programa consegue fazer alguma outra coisa bacana,
>>> então embora não seja obrigatório vc gostaria de recomendar o
>>> Data::Printer. Adicionar essas dependências no Makefile.PL é simples,
>>> ele fica assim:
>>>
>>> ---------------8<---------------
>>> use inc::Module::Install;
>>>
>>> name    'Minha-Dist';
>>> all_from  'lib/MeuModulo.pm';
>>>
>>> requires 'File::Spec' => 0;
>>> requires 'Carp' => 0;
>>>
>>> recommends 'Data::Printer' => 0.3;
>>>
>>> WriteAll;
>>> --------------->8---------------
>>>
>>> O número depois da "=>" indica a versão mínima do módulo, usamos zero
>>> (0) para indicar que qualquer versão serve.
>>>
>>> Com isso acho que vc já tem o suficiente. Não esqueça de criar um
>>> diretório "t" na raiz da sua distribuição para colocar os testes de
>>> seus módulos!! Mais sobre o M:I vc encontra na documentação
>>> (https://metacpan.org/module/Module::Install)
>>>
>>> Obs: quando criamos um novo módulo, há alguns "boilerplates" que criam
>>> as estruturas e documentações básicas para vc. Eu particularmente
>>> gosto do Module::Starter, com o plugin Module::Starter::PBP (mas eu
>>> modifico os templates em ~/.module-starter/PBP para conter o esqueleto
>>> que uso). Assim, basta escrever na linha de comando:
>>>
>>> $ module-starter --module="Meu::Novo::Modulo"
>>>
>>> e ele cria tudo para mim.
>>>
>>> Quando vc estiver acostumado a criar suas distribuições e entender o
>>> processo, vai começar a ficar preguiçoso. Aí sim, dê uma olhada no
>>> Dist::Zilla e veja se ele é para vc =)
>>>
>>>
>>> []s
>>>
>>> -b
>>>
>>> 2012/6/2 Stanislaw Pusep <creaktive em gmail.com>:
>>> > A resposta é: Dist::Zilla.
>>> > Pode parecer chatinho de aprender, mas, uma vez sabendo o básico, criar
>>> > módulo com Makefile.PL completo e suíte de testes é dois palitos!
>>> > Recomendo:
>>> >
>>> > http://sao-paulo.pm.org/artigo/2011/OhnoItsDistZilla
>>> > http://sao-paulo.pm.org/equinocio/2011/set/2
>>> >
>>> > ABS()
>>> >
>>> >
>>> >
>>> > 2012/6/2 Aureliano Guedes <guedes_1000 em hotmail.com>
>>> >>
>>> >> Ola,
>>> >> Monges.
>>> >>
>>> >> Eu estou tentando gerar um MakeFile.PL mas estou com um problema.
>>> >> Eu andei lendo, inclusive alguns materiais do Hernan Lopes mas ficou
>>> uma
>>> >> pergunta.
>>> >>
>>> >> Quando eu tenho varios modulos que na verdade sao dependencia de outro
>>> >> modulo.
>>> >> exemplo:
>>> >> MeuModulo.pm,
>>> >> MeuModulo/Modulo1.pm,
>>> >> MeuModulo/Modulo2.pm.
>>> >>
>>> >> Como faco?
>>> >>
>>> >> Nao achei nenhuma opcao no ExtUtils::MakeMaker.
>>> >>
>>> >> Desde ja, obrigado.
>>> >> Att,
>>> >>
>>> >> Aureliano Guedes
>>> >>
>>> >> PS: Desculpem a falta de acentos, o teclado esta desconfigurado.
>>> >>
>>> >> _______________________________________________
>>> >> Rio-pm mailing list
>>> >> Rio-pm em pm.org
>>> >> http://mail.pm.org/mailman/listinfo/rio-pm
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Rio-pm mailing list
>>> > Rio-pm em pm.org
>>> > http://mail.pm.org/mailman/listinfo/rio-pm
>>> _______________________________________________
>>> Rio-pm mailing list
>>> Rio-pm em pm.org
>>> http://mail.pm.org/mailman/listinfo/rio-pm
>>>
>>
>>
>>
>> --
>> Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org
>> GPG fingerprint = 42AB E78C B83A AE31 7D27  1CF3 C66F B5C7 71CA 9F3C
>> http://www.flickr.com/photos/alexeiz | http://github.com/russoz
>> "I don't know... fly casual!" -- Han Solo
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>

-- 
Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org
GPG fingerprint = 42AB E78C B83A AE31 7D27  1CF3 C66F B5C7 71CA 9F3C
http://www.flickr.com/photos/alexeiz | http://github.com/russoz
"I don't know... fly casual!" -- Han Solo
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120603/d7559b00/attachment.html>