Automagic revision numbers with Perl Modules and SVN
steve at ibctech.ca
Thu Jun 11 12:21:28 UTC 2009
Matthew Seaman wrote:
> Steve Bertrand wrote:
>> Any guidance to fix the version numbering (especially to fix the FreeBSD
>> package db) to make it automagic again, is very welcome:
>> %svn diff -r56 EagleUser.pm
>> Index: EagleUser.pm
>> --- EagleUser.pm (revision 56)
>> +++ EagleUser.pm (working copy)
>> @@ -13,7 +13,7 @@
>> @EXPORT = qw(
>> -$VERSION = sprintf "%d.%03d", q$Revision: 1.9 $ =~ /: (\d+)\.(\d+)/;
> ^^^^ This takes a version number like 1.9 (ie. a string of digits
> one decimal point) and converts it to 1.009
>> +$VERSION = (q$Revision: 1.9 $ =~ /: (\d+)\.(\d+)/;
> ^^^^ whereas this just extracts the number from the revision string and
> uses it as is -- ie. 1.9
> I believe that svn will update $Revision$ keywords in source files (or it
> has some similar function which only differs in the details), but I
> could be
> wrong, and it is entirely possible that the revision numbers will behave
> differently -- svn keeping a repository wide version and cvs keeping a
> per file. Consult the svn documentation on how to embed the version number
> into the file -- once that is working, producing a perl one-liner to
> $VERSION will be pretty easy.
> Assuming this is from a standard module using Module::Build or
> ExtUtils::MakeMaker you should check the Makefile.PL at the top
> level. In there if you're using Module::Build it should say something
> version_from lib/EagleUser.pm
> (although the path may differ). This extracts the value of $VERSION
> from the named .pm file and uses it as the overall module version. Assuming
> your second line, you'll end up with a package name like
> (ExtUtils::MakeMaker works similarly). If you're desperate, you can
> override the setting by patching the Makefile but that doesn't help at all
> in your aim of having the version number update dynamically.
> The convention about padding version strings with leading zeros seems
> to have come and gone in the perl world. I'm not at all sure what the
> current recognised best practice is.
Thanks Matthew for such a detailed and informative response.
I'll look into this today, and report back to the list for archive
purposes if I get this to work.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20090611/522dcd10/smime.bin
More information about the freebsd-questions