Subject: Bugfix release: PAR 0.941 - msg#00018

Previous Message by Date: click to view message preview

Re: PAR hash computation bug fix

Chris Dolan schrieb: I just committed a bug fix for PAR which I think necessitates a new CPAN release. Because of a copy-and-paste error made in v0.94, all output files created by pp or parl get the exact same hash and consequently share cache dirs. This has lead to program crashes and lockups for PAR programs on my Mac when running one PAR program after another one without wiping /tmp/par-* in between. This bug does not affect people who only run one PAR executable. Thanks for tracking this down. I agree: A release is in order. I'll make a release as soon as I find the time. Steffen

Next Message by Date: click to view message preview

Automatically fetching binaries if no C compiler found

Hi list, as most of you probably know, during PAR build time (perl Makefile.PL), it offers to fetch a binary PAR release from CPAN if no C compiler was found. This is the case on more or less all Windows machines. Most of this behavior is implemented in a little-known (because as of yet undocumented) Module::Install extension named Module::Install::PAR. I wrote some documentation yesterday and made some trivial changes to the code. I suppose it might end up in the next release of Module::Install, but I have not gotten feedback from Audrey or Adam yet. That means if you are using Module::Install for one of your CPAN distributions, you can now add optional binary loading with just a couple of lines of code in your Makefile.PL. They could look like this: par_base 'YOUR_CPAN_ID'; unless ( can_cc() ) { # no C compiler? extract_par( fetch_par() ); } This should work with the current module install if you add arguments to fetch_par: fetch_par() becomes fetch_par('', ''). 'Work' here means that this code will fetch a file named YOUR-DISTRO-VERSION-ARCHITECTURE-PERL_VERSION.par from your CPAN directory. Of course, asking the user whether he wants to use a binary might be a good idea. For details, please look at the POD documentation in the attached, modified Module::Install::PAR.pm It is also possible to add custom logic that changes the name of the file downloaded from CPAN. When is this all a good idea? - If you have an XS module that is difficult to compile on a particular platform, you could provide binaries via CPAN. - If you need certain dynamic libraries that are difficult to install on a platform, you might be able to include them in the binary. - You are running a CPAN::Mini mirror and inject your organizations private packages, this might make deployment on a limited set of platforms much smoother. (I wish I had had that idea when I faced the deployment nightmare.) When is this not a good idea at all? - For any pure-perl module on CPAN which installs cleanly on most or all platforms anyway. - The last point covers > 98% of CPAN, of course. Do you think this would be worthwhile to extend beyond just Module::Install based distributions? (I.e. write a Module::Build subclass or similar.) Documented and fixed Module::Install::PAR attached. Thanks for reading, Steffen PAR.pm Description: Perl program

Previous Message by Thread: click to view message preview

PAR hash computation bug fix

I just committed a bug fix for PAR which I think necessitates a new CPAN release. Because of a copy-and-paste error made in v0.94, all output files created by pp or parl get the exact same hash and consequently share cache dirs. This has lead to program crashes and lockups for PAR programs on my Mac when running one PAR program after another one without wiping /tmp/par-* in between. This bug does not affect people who only run one PAR executable. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)

Next Message by Thread: click to view message preview

Automatically fetching binaries if no C compiler found

Hi list, as most of you probably know, during PAR build time (perl Makefile.PL), it offers to fetch a binary PAR release from CPAN if no C compiler was found. This is the case on more or less all Windows machines. Most of this behavior is implemented in a little-known (because as of yet undocumented) Module::Install extension named Module::Install::PAR. I wrote some documentation yesterday and made some trivial changes to the code. I suppose it might end up in the next release of Module::Install, but I have not gotten feedback from Audrey or Adam yet. That means if you are using Module::Install for one of your CPAN distributions, you can now add optional binary loading with just a couple of lines of code in your Makefile.PL. They could look like this: par_base 'YOUR_CPAN_ID'; unless ( can_cc() ) { # no C compiler? extract_par( fetch_par() ); } This should work with the current module install if you add arguments to fetch_par: fetch_par() becomes fetch_par('', ''). 'Work' here means that this code will fetch a file named YOUR-DISTRO-VERSION-ARCHITECTURE-PERL_VERSION.par from your CPAN directory. Of course, asking the user whether he wants to use a binary might be a good idea. For details, please look at the POD documentation in the attached, modified Module::Install::PAR.pm It is also possible to add custom logic that changes the name of the file downloaded from CPAN. When is this all a good idea? - If you have an XS module that is difficult to compile on a particular platform, you could provide binaries via CPAN. - If you need certain dynamic libraries that are difficult to install on a platform, you might be able to include them in the binary. - You are running a CPAN::Mini mirror and inject your organizations private packages, this might make deployment on a limited set of platforms much smoother. (I wish I had had that idea when I faced the deployment nightmare.) When is this not a good idea at all? - For any pure-perl module on CPAN which installs cleanly on most or all platforms anyway. - The last point covers > 98% of CPAN, of course. Do you think this would be worthwhile to extend beyond just Module::Install based distributions? (I.e. write a Module::Build subclass or similar.) Documented and fixed Module::Install::PAR attached. Thanks for reading, Steffen PAR.pm Description: Perl program