|
|
Subject: Bugfix release: PAR 0.941 - msg#00018
List: lang.perl.par
Hi list,
after Chris Dolan's error report, I did a quick PAR release. PAR 0.941
should be available on CPAN by now and Win32 binaries are available from
CPAN (5.8.8) or from the bribes repository.
Steffen
Was this page helpful?
Thread at a glance:
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
|
|