CPAN does track the VERSION of each .pm file,
and it will not install a .pm file if it thinks
the one already installed is newer, regardless what the
version number is of the package. (In fact, as far as I
can tell, there's no relationship between the version of
the package (the number in the tar file), and the versions
of the .pm files).
As far as CPAN is concerned, all the .pm files without
a VERSION assignment in the file itself do not have a VERSION.
It'll list them as undef. Whether it will then
actually replace an already installed file with a newer one,
I do not know. For me, CPAN usually doesn't do what I mean,
so I wouldn't dare take the risk.
Abigail | [reply]
[d/l] |
| [reply] |
Not only would CPAN need to compile the file, but also
run it, as $VERSION is typically set at compile time.
CPAN is not going to run the entire file.
What I'm trying to avoid is all the CPAN problems to which you allude: all the files in my package remain in lock
step through every release (and reflect the version of the overall distribution).
Whether your files remain in lock step is not archieved by
inheriting $VERSION. What you do lose is the
ability to easily check whether your files are in lock step.
If each file has its own $VERSION, it's easy
to see if there's a mismatch. If they inherit from a single
source, there's no way to find out.
IMO, if you inherit $VERSION, you'd lose one of
major reasons to use a version number.
Abigail
| [reply]
[d/l]
[select] |
The things in PREREQ are required and then $VERSION checked for. The version specified using VERSION_FROM is retrieved by parsing the file. From the ExtUtils::MakeMaker docs:
Instead of specifying the VERSION in the Makefile.PL you can let MakeMaker parse a file to determine the version number. The parsing routine requires that the file named by VERSION_FROM contains one single line to compute the version number. The first line in the file that contains the regular expression
/([\$*])(([\w\:\']*)\bVERSION)\b.*\=/
| [reply]
[d/l] |