Como sempre: garu++;<span></span><br><br>On Wednesday, May 29, 2013, breno  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Calma, não se desesperem :-)<br>
<br>
tl;dr: o Module::Build não vai morrer, só vai sair do core. Em 2015.<br>
Hoje, todos os clientes do CPAN já são capazes de fazer bootstrap do<br>
Module::Build automaticamente no sistema via "configure_requires"<br>
antes do Build.PL rodar, então essa remoção não fará nenhuma diferença<br>
prática para distribuições usando o Module::Build - apenas deixará o<br>
core do Perl mais enxuto, leve, e livre de preocupações associadas ao<br>
Module::Build. É um ganha-ganha para todos.<br>
<br>
<br>
---------[ versão "garu" ]---------<br>
<br>
Como você provavelmente já sabe, o ciclo de desenvolvimento atual do<br>
Perl 5 é de uma nova versão estável por ano. Esse mês, a versão 18 do<br>
Perl 5 foi lançada. Quase ao mesmo tempo, como de costume, foi lançada<br>
a 5.19, primeiro release de desenvolvimento do novo ciclo. Ao ser<br>
marcado para remoção, o Module::Build que vem no core do 5.19 emitirá<br>
um warning sobre isso, e esse warning continuará até a versão 5.22 -<br>
em 2015 - quando ele finalmente será completamente removido do core.<br>
Não do CPAN, apenas do core.<br>
<br>
"Mas peraí", você diz. "O Module::Build não é usado pra instalar<br>
módulos sem o 'make'? Não é um dos builders mais usados? O próprio<br>
Michael Schwern, criador do ExtUtils::MakeMaker, não disse pra todo<br>
mundo migrar do EUMM pro Module::Build? WTF?"<br>
<br>
De fato, o Module::Build foi *fundamental* para uma série de inovações<br>
que aconteceram no mundo Perl na última década(!), especialmente no<br>
que se refere ao toolchain para instalação e configuração de módulos.<br>
Entre outras, ele formalizou a especificação do Build.PL, foi o<br>
primeiro a permitir build e instalação de módulos usando apenas Perl<br>
em vez de criar Makefiles, inventou e popularizou o META.yml (que<br>
evoluiu para a especificação META oficial do CPAN), permitiu a<br>
instalação automática em diretórios personalizados de forma fácil e<br>
intuitiva (efetivamente abrindo caminho para iniciativas como<br>
local::lib e carton), tornou extremamente fácil a instalação de<br>
módulos "Alien" como o SDL e o wxWidgetse, e trouxe insights<br>
importantíssimos para a criação de uma série de soluções avançadas, do<br>
Module::Install ao Dist::Zilla.<br>
<br>
No entanto, o Module::Build em si também tem vários problemas - a<br>
maioria deles ligados à manutenção. São mais de 4K linhas de código<br>
misturadas em um arquivo só (Module::Build::Base), código super<br>
acoplado e difícil de acompanhar, depurar e extender. Por exemplo, o<br>
Build.PL executado serializa os resultados em alguns arquivos que são<br>
usados ao longo da execução do "Build" para reconstruir o objeto<br>
original, com montes de meta-opções e potenciais subclasses<br>
interferindo no processo como um todo. Uma série de features<br>
supérfluas e/ou raras foram adicionadas diretamente em seu núcleo,<br>
prejudicando ainda mais o bom entendimento e depuração do processo de<br>
montagem e instalação das distribuições. Seu sistema de dependências<br>
nunca foi realmente satisfatório, e sua geração automática de<br>
Makefile.PL trouxe como consequência a necessidade de manter<br>
compatibilidade de features (e, em muitos casos, de bugs) com o EUMM<br>
para sempre.<br>
<br>
Isso não quer dizer que o Module::Build seja um builder ruim - tanto<br>
que muitos projetos de sucesso usaram-no e continuam com ele até hoje.<br>
Mas todas as questões acima culminaram no Module::Build nunca se<br>
tornando o sucessor efetivo e incontestado do EUMM, como havia sido<br>
previsto quando ele foi colocado no core. A decisão faz parte de uma<br>
estratégia maior de remoção de módulos do core, para deixar a<br>
manutenção mais fácil e permitir que os desenvolvedores gastem seu<br>
tempo criando novas features e cuidando de bugs importantes, em vez de<br>
mantendo módulos que não são realmente essenciais. Ela foi possível<br>
graças aos avanços nos clientes de CPAN (cpan, cpanplus, cpanm) que<br>
hoje suportam o bootstraping do Module::Build via<br>
"configure_requires". Quando o cliente detecta que precisará do<br>
Module::Build, ele vai baixá-lo e instalá-lo pra vc automaticamente,<br>
antes de rodar o Build.PL. Isso já é feito quando o requisito é uma<br>
versão mais recente do M:B que a que foi instalada no core da sua<br>
versão do Perl 5. Daqui a dois anos, será a regra.<br>
<br>
Para mais detalhes (em inglês), incluindo links da discussão associada:<br>
<a href="http://www.dagolden.com/index.php/2140/paying-respect-to-modulebuild/" target="_blank">http://www.dagolden.com/index.php/2140/paying-respect-to-modulebuild/</a><br>
<br>
<br>
[]s<br>
<br>
-b<br>
_______________________________________________<br>
Brasil-PM mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'Brasil-PM@pm.org')">Brasil-PM@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/brasil-pm" target="_blank">http://mail.pm.org/mailman/listinfo/brasil-pm</a><br>
</blockquote><br><br>-- <br>Bruno C. Buss<br><a href="http://www.brunobuss.net" target="_blank">http://www.brunobuss.net</a><br>