# from Boyd Duffee on Thursday 11 October 2012:
>When I run
>perl Build.PL
>I get
>Can't use string as a HASH ref while "strict refs" in use
>when I call the create_build_script() method. I've attached the
>Build.PL file. What am I doing wrong?
Hi Boyd,
I get `Can't use string (
# from David Golden
# on Saturday 04 February 2012 17:23:
>It doesn't help with optional, dynamic prereqs so those have to be
>specified manually, but that's unavoidable I think.
I've experimented with detecting those using my Devel::TraceDeps on the
running test suite. It is possible to see th
# from Alberto Simões
# on Saturday 12 June 2010 07:01:
>I am preparing a package that has some C code that needs a full path
>compiled in.
>
>I am using, during Build.PL first run,
> $builder->install_destination("bin");
>
>But, if the user issues a build install with a different installbase,
# from Elliot Shank
# on Thursday 27 May 2010 05:46:
>it uses Storable, which wasn't in core until 5.7.3
>+ $tap_harness_args = dclone($tap_harness_args);
>+ $orig_tap_harness_args = dclone($tap_harness_args);
>+ my $switches = $tap_harness_args->{switches} || [];
>+ push @{$switches}
# from David Golden
# on Friday 16 April 2010 10:54:
>On Fri, Apr 16, 2010 at 1:47 PM, Eric Wilhelm
wrote:
>> Or, dirty hacks:
>>
>> my $orig = \&ExtUtils::Manifest::maniskip;
>> local *ExtUtils::Manifest::maniskip = sub {
>
>-1 Dirty hacks lead to
# from David Golden
# on Friday 16 April 2010 07:00:
>I'm wondering if the "answer" is to generate MANIFEST.SKIP for the
>duration of distcheck and related activities *only* and not let it
>hang around all the way to be cleaned later. That would avoid all the
>confusion, I think.
Or replace ExtU
Hi Alberto,
# from Alberto Simões
# on Tuesday 02 March 2010 13:55:
>Some users of my Text::BibTeX module requested me to include some
>modules that are only required for the build process into the inc/
>directory.
Why? Are they having trouble satisfying configure_requires or
build_requires?
# from David Golden
# on Tuesday 23 February 2010 17:17:
>> The easy thing would be to remove the Build.PL from
>> ExtUtils::ParseXS, ExtUtils::CBuilder, etc (but only because we have
>> comaint on those.)
>
>We know who the maintainers are and can encourage them. Test::Harness
>is already done.
Hi all,
We've run into a Build.PL vs Makefile.PL problem with cpanminus. The
situation is that if M::B requires anything with a Build.PL file, that
it becomes impossible to bootstrap.
The easy thing would be to remove the Build.PL from ExtUtils::ParseXS,
ExtUtils::CBuilder, etc (but only beca
# from David Golden
# on Tuesday 23 February 2010 12:05:
>> So, the default MANIFEST.SKIP should contain MYMETA.yml?
>M::B does and the latest ExtUtils::Manifest does.
I think that will have to be enough.
>But a MANIFEST.SKIP is only created for "Build manifest" or "Build
>distcheck", so it does
# from Michael G Schwern
# on Tuesday 23 February 2010 01:02:
>BTW Eric, I didn't notice that Module::Signature was complaining about
>MYMETA.yml not being in the MANIFEST. I puzzled out why its doing
> that. Module::Signature appears to assume that anything in the
> directory at the point of "bu
# from Andreas J. Koenig
# on Tuesday 23 February 2010 05:17:
>This is quite a different argumentation than it was at the beginning
> of this thread, and I have no problem with that. We will agree that
> 'dropped for end user' is not the same as 'removed'. And it's
> actually what Module::Signatur
# from David Golden
# on Monday 22 February 2010 20:26:
>>> But I'm curious about how the automatic addition of MYMETA.yml to
>>> MANIFEST.SKIP (as shown in the output) didn't keep you from running
>>> into this. (I'm mostly concerned about whether it might cause
>>> problems for more valid use-c
# from Hinnerk Altenburg
# on Monday 22 February 2010 06:29:
> $master:~/cpan/perlids>./Build disttest
> Creating Makefile.PL
> Creating META.yml
> *File 'MANIFEST.SKIP' does not include 'MYMETA.yml'. Adding it now.*
>...
> *t/00-signature.t . Not in MANIFEST: MYMETA.yml
> ==> MISMATCHED conte
# from Michael G Schwern
# on Friday 19 February 2010 16:45:
>> Is *not* using version.pm an option?
>
>For once, I really need x.y.z versions.
>http://search.cpan.org/~mschwern/perl5i-v0.2.2/lib/perl5i.pm#VERSIONING
I'll continue to hold the opinion that vX.Y.Z versions don't strictly
require v
# from Marvin Humphrey
# on Saturday 13 February 2010 13:12:
>> But if I want to use c_source or xs_files and the build for these
>> elements depend on a build element, how can I force the order?
>
>Use Module::build's actions.
>
> sub ACTION_code {
> my $self = shift;
> $self->
# from Marvin Humphrey
# on Sunday 24 January 2010 06:15:
>> hard place: old client invents Makefile.PL from thin air
>
>Probably the fact that we require Perl 5.8.3 or above spares us from
> some of those.
Only if the super-retro users know that you require 5.8.3, which they
don't unless the
# from David Golden
# on Saturday 23 January 2010 15:11:
># from Marvin Humphrey
>>I've got ... a passthrough Makefile.PL. Should I zap it?
>To clarify - the real issue with M::B::Compat in passthrough mode is
> that we have to emulate the api perfectly and that's a big source of
> bugs.
Passth
# from Tim Landscheidt
# on Tuesday 29 December 2009 20:03:
>> You're looking for File::ShareDir and the share_dir parameter, which
>> was added in the just-released Module::Build 0.36.
>
>As Module::Build is a core module, it is quite a pain to up-
>date in my distribution.
Would it be easier if
# from David Golden
# on Wednesday 02 December 2009 16:37:
>> We can't really draw a line between "core" and "author support" --
>> only between "core" and "not core" (because what was once in "core"
>> is
>
>Sorry. I was imprecise. I was not saying "core" to mean "Perl core".
> Just what is *es
# from David Golden
# on Wednesday 02 December 2009 14:59:
>Anyway, when that's done, I think I'll have a clearer sense of what in
>M::B is really "core" and what is "author support". That said,
>plugins are probably not on my radar in the next year.
We can't really draw a line between "core" an
# from John Peacock
# on Wednesday 02 December 2009 11:05:
>Sounds like you need something like a metafile for each plugin (a mini
>manifest) which M::B can use to resolve which plugin is needed at that
>point.
Perhaps, but I was saying that this info should be provided as part of
the Build.PL c
# from David Golden
# on Thursday 26 November 2009 05:10:
>How about this:
>
>(1) We add a "testrelease" action that sets RELEASE_TESTING and calls
>a list of other testing actions
>
>(2) We add a 'testxt' action that runs tests in xt/; this is common
>enough now that we might as well make it easy
# from David Golden
# on Wednesday 18 November 2009 03:46:
>EekBoek bundles Module::Build 0.28 in inc.
>
>This is the issue that the new experimental inc/ bundling with
>inc::latest is intended to avoid.
>
>I don't know how CPANPLUS should deal with this. Maybe if
>"prereq_data" fails, you have t
# from pe...@penma.de
# on Thursday 22 October 2009 10:17:
> sbin_files => { 'myapp_admin' => 'sbin/myapp_admin' },
>but it (M::B 0.35) just doesn't install myapp_admin, it doesn't
> mention it, just skips.
No, there isn't an sbin_files property defined, so that parameter is
ignored.
>So wh
# from Christopher J. Madsen
# on Friday 02 October 2009 14:20:
>I think MB ought to be split up into the "build/test/install module"
>part and the "tools for distribution authors" part. MakeMaker
> combined the two, and MB followed suit, but I don't think it was a
> good idea.
It has the benefi
# from Christopher J. Madsen
# on Friday 02 October 2009 11:31:
>As an install tool, MB must have minimal requirements. Since it only
>creates distributions, Dist::Zilla can have much steeper requirements
I've been thinking of some way to separate the minimal parts.
But orthogonal to that:
>1.
# from brian d foy
# on Tuesday 29 September 2009 17:19:
>> eval "require $build_class; 1" or
>> die "Failed to re-load '$build_class': $@";
>
>Well, that bit is the problem. If I got past that I wouldn't have a
>problem.
But wait, you said you called Module::Build->resume() and got back th
# from brian d foy
# on Monday 28 September 2009 11:24:
>What is resume() for, then?
That's an excellent question. The docs say: "You'll probably never
call this method directly ...", so you've won the obscurity prize. ;-)
Seriously though, you've left the realm of test coverage and mainstre
# from brian d foy
# on Tuesday 22 September 2009 13:44:
>When I use Module::Build->resume to pick up where a build left off,
>I'm not getting the @INC originally declared in the Build.PL. I think
>I'm doing something wrong.
>
>I'm working on a continuous integration and deployment system. For
> p
# from Petar Shangov
# on Wednesday 23 September 2009 09:30:
>I was hoping there was some way
>to automate this since the files in the directory in question are
>likely to change in the future and I would rather not edit the
> MANIFEST manually every time.
If you run `./Build manifest`, it will r
# from John Peacock
# on Wednesday 23 September 2009 07:23:
>When an
>underbar/underscore is encountered, that is used as an additional
> split character and the is_alpha flag set, so that the last "digit"
> of the version is the "alpha release".
Why is the underscore treated as a split character
# from Petar Shangov
# on Wednesday 23 September 2009 03:14:
>What is the best way to add a whole directory with various files to a
> distribution - I want all of these files to be in their own "example"
> directory in the root directory of the tarball.
If you add files to the MANIFEST, they will
# from dagol...@cvs.perl.org
# on Saturday 12 September 2009 21:42:
>+ # We're in author mode if inc::latest is loaded, but not from cwd
>+ return unless $INC{'inc/latest.pm'} && ! -e 'inc/latest.pm';
I think this can be
return unless inc::latest->can('loaded_modules');
--Eric
--
The r
# from David Golden
# on Friday 11 September 2009 20:05:
>Uh, huh. How about all that platform specific code that doesn't get
>loaded? E.g. Module::Build::Platform::VMS.
packlists.
>Having an 02packages file from a CPAN to map from a requested module
>to a distribution and then interrogating t
# from David Golden
# on Friday 11 September 2009 19:19:
>Like I said, ScanDeps/TraceDeps should work most of the time.
Devel::TraceDeps is very different from Module::ScanDeps. There's
no "most of the time" about it -- it tells you everything that got
loaded via require() or use().
--Eric
--
# from David Golden
# on Friday 11 September 2009 17:39:
>> o Off-line: For those of us who work on machines with no mini CPAN
>> and no internet access,...
>
>As an end-user, it will "work"
No, you're going to run into troubles with dependencies just like you
would with an EU::MM-based Makefile
# from Dave Rolsky
# on Friday 11 September 2009 11:03:
>In theory, it sounds good. I do wonder if this would require _always_
>generating the manifest a the same time though.
>
>I do find having the generated files in the regular dir annoying,
> because then I have to tell my VCS to ignore them.
Elaborating on what I said in the other mail and trying to put it mostly
together in one place:
# from David Golden
# on Thursday 10 September 2009 12:57:
>(1a) Should bundling modules into inc/ happen in $source or $distdir?
$distdir
>(1b) For either choice in #1a, how should the behavior of
# from David Golden
# on Thursday 10 September 2009 12:57:
>(1b) For either choice in #1a, how should the behavior of “bundle_inc”
>change depending on whether $source/inc exists or is missing?
I think this asks the wrong question, but all of the questions are
somewhat tangled-up around what or
# from David Golden
# on Wednesday 09 September 2009 03:50:
>> And anything you bundle automatically goes in configure_requires.
>
>Or perhaps the reverse -- anything you put in configure_requires would
>be bundled.
No, because then we have to check whether you've got a
'use inc::latest ...' for
# from David Golden
# on Tuesday 08 September 2009 21:26:
>There's no more risk in using a newer M::B over a bundled one than
>there is upgrading M::B in the first place.
Exactly. And if a client supports configure_requires they might get an
updated M::B installed before Build.PL runs anyway (s
# from John Peacock
# on Tuesday 08 September 2009 09:10:
>I don't see #2 as necessarily being /more/ correct; the author has
>[presumably] tested with the packages installed in the current Perl
>library path.
Yes. An author should always have the same thing on their system that
they're putting
# from David Golden
# on Monday 07 September 2009 17:00:
>As to how to trigger the bundling, I'd suggest adding a "bundle_inc"
>parameter. Authors can either set it in Build.PL or just tack it onto
>the command line: Build dist --bundle_inc
But that leaves the possibility that your Build.PL won'
# from David Golden
# on Monday 07 September 2009 14:40:
>> use lib 'inc';
>> use latest 'Module::Build';
>...
>M::I installs an "inc::Module::Install" into the normal @INC libraries
>that allows bootstrapping the inc/ directory. It might be worth
>exploring that kind of approach.
I would pref
# from Nicholas Clark
# on Monday 07 September 2009 11:11:
>I believe (but I may be wrong) that the plan with bundling was to use
> the newer of the bundled and any installed version, to avoid the
> problem that has happened with M::I whereby a bug fix in M::I means
> that module authors need to u
# from Nicholas Clark
# on Monday 07 September 2009 08:39:
>Is getting M::B bundling working anyone's itch?
Bundling "works" in that the inc/latest.pm scheme works.
Bundling "can be done" if you run the bundle.pl script from the dist and
change your Build.PL to look in inc and use the latest.pm
# from David Golden
# on Sunday 06 September 2009 21:53:
>> I would be very sad to see a runtime module requirement just to
>> declare some rarely-used meta info. Ditto for requiring a new Perl.
>
>POD? Hell, no.
Why not? If it's properly specified and pod-renderable, things like the
distribu
# from David Golden
# on Sunday 06 September 2009 07:03:
>> allow us to eliminate the whole eval($VERSION) thing
>"foolish consistency" line comes to mind...
Yes, the computer has a very little mind.
>While it relates to source rather than Meta, it intersects because
>"-TRIAL" wouldn't be in dis
Hi all,
Here's a patch of an idea I've been toying with: the ability to publish
an alpha version using the little-known "-TRIAL" string in the tarball
name.
The trigger mechanism is to have the string "# ALPHA" on your $VERSION
line. That might have drawbacks, but is also 1) very simple and
Hi all,
This patch starts the ball rolling for adding an 'installdeps' action.
The basic idea is to prompt about whatever optional modules, then run
the user's choice of program with the needed modules as arguments.
David Golden mentioned the issue of what if the perl that runs Build.PL
is no
# from Ron Savage
# on Monday 31 August 2009 18:04:
>Is there a program/module which will scan all *.pm files in a dir, and
>extract what version.pm thinks are version numbers?
Have you looked at Perl::Version (and perl-reversion)?
See also: all of the caveats David mentioned.
--Eric
--
Issues
# from David Golden
# on Friday 28 August 2009 03:31:
>* ensure_blib doesn't sound like a test function even though it is.
>That's a nit, but could confuse someone trying to count tests. That
>could be fixed with a big find/replace commit, but I just haven't
>gotten around to it.
I think we coul
# from David Golden
# on Friday 28 August 2009 09:09:
>Could have DistGen create a tmp dir that doesn't set CLEANUP and
>records initial directory.
It already records the initial directory from chdir_in().
>Then DistGen's DESTROY could chdir to the
>original and remove the temp. That keeps it
# from David Golden
# on Friday 28 August 2009 03:31:
>Looking at MBTest, it has an END block to chdir so the END in my
>example isn't really necessary. But it's a code smell to me to rely
>on such action at a distance to do the right thing.
But remember it used to be that same END block which w
# from David Golden
# on Thursday 27 August 2009 19:08:
>> I think this END block is redundant given a temp dir with CLEANUP =>
>> 1.
>
>remove() does a chdir out of the directory. That's important or the
>tempdir can't be removed on Windows. At least, that's my best take on
>the situation.
Ah.
# from dagol...@cvs.perl.org
# on Thursday 27 August 2009 14:08:
>+ my $dist = DistGen->new( dir => MBTest->tmpdir );
>+
>+ # generate the skeleton files and also schedule cleanup
>+ $dist->regen;
>+ END{ $dist->remove }
I think this END block is redundant given a temp dir with CLEANUP => 1
# from dagol...@cvs.perl.org
# on Tuesday 25 August 2009 13:30:
>Log:
>Fix t/destinations.t segfault on 5.6.2
>- local $mb->install_sets->{site} = \%test_config;
>+ my $old = $mb->install_sets->{site} = \%test_config;
...
>+$mb->install_sets->{site} = $old;
Hi David,
Is that really w
# from David Golden via RT
# on Sunday 23 August 2009 20:41:
>* In have_c_compiler, cache the results in the stash, not the
>properties, because it isn't actually a property, but we do want it to
>persist per session
I'm not sure what you mean by "per session", but $self->{stash} is not
persiste
# from David Golden
# on Sunday 09 August 2009 05:25:
>Remember, this is Module::Build saying: "You're too lazy to specify
>what version of me you need, so I guess I have to read your mind or
>come up with some reasonably sane fallback to protect your from
>yourself."
>
>In that context "0" means
# from David Golden
# on Tuesday 04 August 2009 13:05:
>I will, in time, do similar conversions for ExtUtils::CBuilder and
>Module::Build. The latter will probably not happen until the release
>tools are fixed up for git instead of subversion.
Michael Schwern did some work on VCfs (at svn.scratc
# from David Golden
# on Wednesday 15 July 2009 14:53:
>> our $VERSION = do { use version 1.00; version->declare("v1.2.3")
>> };
>
>I almost hate to say it, but I actually kind of like that. It's
>really, really clear in the intent.
I'm going to keep doing what I've been doing:
our $VERSION
Hi all,
It's been brought to my attention that our 'inc/latest.pm' might cause
some confusion with:
http://search.cpan.org/~andya/latest-0.02/lib/latest.pm
Particularly, if anyone wants to use that in their tests and is running
through the Test::Harness API, we'll have potential confusion if
# from Ron Savage
# on Sunday 05 July 2009 23:56:
>The subject says it all.
up-to-date with regard to what? Internally, M::B just uses stat() to
check the timestamp of Build vs Build.PL.
--Eric
--
The only thing that could save UNIX at this late date would be a new $30
shareware version that
# from David Golden
# on Friday 26 June 2009 13:56:
>If a module is listed in configure_requires, should it be listed again
>under build_requires?
Here's the last context I know of regarding that.
http://www.nntp.perl.org/group/perl.module.build/2007/06/msg733.html
Basically, some historical i
# from Curtis Jewell
# on Wednesday 17 June 2009 16:10:
>> Same deal with every other tool I looked at though.
>Will https posting to pause do?
>
>If you can live without scp (and config overlaying, although you may
>want to politely poke BDFOY to add that in - it's something that's I'm
>starting
# from Michael G Schwern
# on Wednesday 17 June 2009 12:19:
>Oh god, if anything screams for subclassing its VCfs. Its got SVN and
> SVK and darcs all tangled up in one set of routines with lots of if
> statements. And there's SVN commands inside CPDK!
>
Quite.
>This doesn't look like too much
# from Michael G Schwern
# on Tuesday 16 June 2009 16:47:
>Where's the release script? I see devtools/release_instructions.pod
> but no script.
It's:
http://svn.scratchcomputing.com/CPDK/trunk/
There might still be some dependencies which aren't released (if so,
they're found in the same sv
# from Michael G Schwern
# on Saturday 13 June 2009 21:33:
>+MAX_INT
>
>I can do it, I've done it often enough and I think the MB repo is
> pretty simple
My concern is still for the release process. I need to be able to
easily pull a sequential log of commit messages since the last release
tag
# from Ken Williams
# on Wednesday 10 June 2009 20:14:
>Is anyone interested in switching the M::B repository from SVN to Git?
My release tool isn't git-enabled, so it won't help me much.
I'm still of the belief that what we need is more automated smoke
testing (which would allow more confidenc
# from Elliot Shank
# on Sunday 17 May 2009:
>Adam's response:
>> This is a bug in Module::Build, it forgot to serialize the version
>> object in configure_requires before writing it into the META.yml.
>>
>> Module::Build should probably do this in the general case anyway,
>> objects shouldn't be
# from Yitzchak Scott-Thoennes
# on Sunday 03 May 2009 20:32:
>My first reaction: whu...? version is still at 0.76.
Yeah. I suppose there's context. Except there's the recent context
about version.pm. haha. :-D
--Eric
--
"Matter will be damaged in direct proportion to its value."
--Murphy's
Hi all,
0.33 is shipped. Supposedly just in time for perl 5.10.1.
We might have even managed to close more tickets than were opened
between 0.32 and 0.33. Yay.
Big thanks to David Golden for his efforts with the testing.
--Eric
--
We who cut mere stones must always be envisioning cathedrals
# from Adam Kennedy
# on Thursday 23 April 2009 19:48:
>> I would like to see #3, and I suspect that it could be implemented
>> in 5.12.0, excepting certain caveats for last-century compatibility,
>> but maybe if it changes now, it could make some sense in 9 more
>> years.
>
>You mean 6.2.0 right?
# from John M. Gamble
# on Thursday 23 April 2009 12:47:
>we should be aiming for:
>
>1) there is one, and only one, format for a version number in META.yml.
>2) CPAN packages are named using that number in META.yml. See above.
...and everyone who uses float versions will now scream bloody murder
# from Adam Kennedy
# on Wednesday 22 April 2009 20:33:
>2009/4/23 Eric Wilhelm :
>> I think this comes at it from the wrong end. You have to go from
>> floats to tuples to compare between them. So, 1.0101 -> 1.10.1.
>
>You didn't zero-pad to the nearest trip
# from Austin Schutz
# on Wednesday 22 April 2009 16:42:
>1.1.1 -> 1.01.01
>
>
>This could be directly compared with: 1.0101
I think this comes at it from the wrong end. You have to go from floats
to tuples to compare between them. So, 1.0101 -> 1.10.1.
>and would solve the case where: 1.9.1
# from David E. Wheeler
# on Wednesday 22 April 2009 14:04:
>> It should have been 1.0.6. Just adding a dot at every digit would
>> actually have been somewhat obvious.
>
>Yes, but look at this:
>
> 1.9 => 1.9.0
> 1.10 => 1.1.0
>
>Doesn't really do the trick.
What? Why not? What compa
# from Michael G Schwern
# on Wednesday 22 April 2009 13:38:
>>> Class::Delegation went from 1.06 to 1.7.1. That's 1.60.0 to 1.7.1
>> Of course that's what it means. The fact you don't have to type the
>> last zero is just a convenience...
>
>Of course.
>
>Of course, it could be 1.6.0. Or 1.60.0
# from Yitzchak Scott-Thoennes
# on Wednesday 22 April 2009 13:05:
>> It's quite acceptable for the value in META.yml to be a normalised
>> different string to what is in the module.
>
>the two possible purposes are 1) comparison ... and 2) display.
Yes. META.yml should be a very convenient way
# from David Golden
# on Tuesday 21 April 2009 13:34:
>Because perldelta implies that v-strings aren't supposed to be used
>for version numbers. It's pretty explicit for Perl version numbers
>and even has a warning for 'use v5.10'.
v-string in use/require is non-portable
Perl w
# from Eric Wilhelm
# on Tuesday 21 April 2009 13:23:
>No, it is not ok to get success from 'use foo v1.2.10' when foo's
>$VERSION is v1.2.3_1 -- especially when a version.pm comparison would
>tell you that v1.2.10 > v1.2.3_1.
Oh, whatever. I give up.
$ perl
# from Yitzchak Scott-Thoennes
# on Tuesday 21 April 2009 13:02:
>> I don't "dislike" the underscore. It _does_ _not_ _work_ as a
>> delimiter in a version number because perl does not treat it as
>> such.
>
>Yes, it does, wearing its version object (aka version.pm) hat.
>
>perl does not treat vs
# from David Golden
# on Tuesday 21 April 2009 11:19:
>Leading "v" AND two separators (period or the hated underscore).
I don't "dislike" the underscore. It _does_ _not_ _work_ as a delimiter
in a version number because perl does not treat it as such.
And, since perl 5.10.0 cannot be fixed, ve
# from John Peacock
# on Tuesday 21 April 2009 03:35:
>You aren't using version.pm comparisons in both cases, so it shouldn't
> be all that surprising that it doesn't work the way you'd expect it.
I think you need to treat it as a version.pm bug. The comparisons don't
match perl's.
$ perl -e
# from Jan Dubois
# on Monday 20 April 2009 16:05:
>On Mon, 20 Apr 2009, Eric Wilhelm wrote:
>> Except that we have to somehow have a single, definitive indicator
>> to take the place of the underscore.
>
>There is one reason I *do* like the underscore to indicate
> non-
# from Yitzchak Scott-Thoennes
# on Monday 20 April 2009 18:53:
>> Form (a) is recommended for all new version numbers. Form (b) is
>> allowed for compatibility with legacy version numbering.
>
>Use a triple tuple if you like, but I want my versions to be a number
>and only a number.
>
>I'm baffl
# from Ken Williams via RT
# on Monday 20 April 2009 19:01:
>I like it. Any objections from the other maintainers?
Only that we need to get 0.33 out.
--Eric
--
"...the bourgeoisie were hated from both ends: by the proles, because
they had all the money, and by the intelligentsia, because of th
# from David Golden
# on Monday 20 April 2009 14:59:
>(a) A tuple of at least three integers, prefixed with a leading "v".
>Tuples may be separated by either periods (".") or underscores ("_").
>Examples: "v1.2.3", "v3.14.0", "v1.2.3.4", "v1.2.3_4".
I'm very troubled by any inclusion of underscor
# from David Golden
# on Monday 20 April 2009 14:29:
>(a) how someone should convert from a numeric versions to vX.Y.Z
>without screwing up their ascending sequence
perl -Mversion -E 'say version->new("1.13")->normal'
>(b) how to compare vX.Y.Z to a legacy X.YYZZ
You mean X.YYY.Z -- it's alwa
# from David E. Wheeler
# on Monday 20 April 2009 14:12:
>> Sure, you can't just treat a float as a tuple without fixing the
>> width of the second column. I imagine this is where everybody gets
>> confused and I think all we need to do is explain that.
>>
>> X convert to vX
>> X.Y
# from Michael G Schwern
# on Monday 20 April 2009 13:05:
>> Sure, you can't just treat a float as a tuple without fixing the
>> width of the second column. I imagine this is where everybody gets
>> confused and I think all we need to do is explain that.
>>
>> X convert to vX
>> X.Y
# from John Peacock
# on Monday 20 April 2009 04:16:
>> All of the trouble we've ever had is just that X.Y happens to look
>> like some kind of a number and like a dotted 2-tuple. But instead
>> of perl version 5.564.0 or 6.0.x, it was 5.5.640.
>
>X.Y is a [floating point] number and is in fact d
# from Michael G Schwern
# on Sunday 19 April 2009 13:42:
>X sort as a number
>X.Y sort as a number
>X.Y.Z sort as dotted tuple (allowing X.Y.Z.A.B... if you like)
>
>And that's that. Have version.pm *always* output at least X.Y.Z. X.Y
> becomes X.Y.0 or is simply disallowed. Then t
# from Michael G Schwern
# on Sunday 19 April 2009 13:42:
>1.234 <=> 1.2.3 becomes 1.234.0 <=> 1.2.3 which is >
What about 1.2345? IME, main trouble with mixing is that there's a
3-digit padding convention (required for compatibility with some
ancient perl?)
--Eric
--
"It works better if you
# from John Peacock
# on Sunday 19 April 2009 03:41:
>However, using $version->stringify() instead would be better than
> having META.yml contain an object dump for $VERSION. The version.pm
> object is guaranteed to stringify to the same form as was original
> present in the source file, which is
# from Nicholas Clark
# on Saturday 18 April 2009 13:14:
>On Sat, Apr 18, 2009 at 11:35:17AM -0700, Jan Dubois wrote:
>> On Sat, 18 Apr 2009, Michael G Schwern wrote:
>> > Let's count the different ways we might have to parse a version.
>> >
>> > X ok, sort it as a number.
>> > X.Yhopeful
# from David Golden
# on Saturday 18 April 2009 04:08:
>> Module::Build::Functions, anybody? *grin* [Thinking of the module
>> purpose as being analogous to the differences in use between
>> File::Spec and File::Spec::Functions]
>
>It really wouldn't be very hard to crib the easy style of M::I for
# from ericwilh...@cvs.perl.org
# on Tuesday 14 April 2009 17:16:
>tagging Module-Build release 0.32_01
Hi all,
It's about time for an 0.33 release. Please put this alpha in your
pipes and smoke it.
Meanwhile, committers should refrain from any code changes which would
invalidate the smokes u
# from David E. Wheeler
# on Thursday 02 April 2009 10:41:
> create_makefile_pl => 'passthrough',
>
>In most of my modules. I get the impression that this is no longer
>recommended, however. So what is?
What gives you that impression?
The only thing *I* would recommend over passthrough is
1 - 100 of 529 matches
Mail list logo
