#12 Fixing genxref

[Peder O. Klingenberg]

Relevant exerpts of mail I sent earlier today:

Basically, finding out which versions exist is moved
into the loops,
so that the CVS backend has the ability to vary the
list of versions according to which file it's looking
at.

The cost of this is that when not using this
functionality (typically when using Plain.pm) you will
be looking up a constant value for each file.

I find that the flexibility is worth the cost, but I
may be biased. :)

With the exception of the time penalty of extra lookups
of
$config->varrange('v'), this should be exactly
equivalent to the
current version unless using closures for the range
value.

(BTW, using explicit reference to
$config->{variables}{v}{range}, like in the current
genxref, is a Bad Thing (tm). The access method has
been there forever. I only changed the access method
to accept closures, and everything magically worked.
Adding an explicit reference to the underlying hash is
bad, because that will return the
closure, not the result of calling the closure.)

[Peder O. Klingenberg]

Patch against genxref.

[Malcolm Box]

Logged In: YES
user_id=215386

Sorry, this patch won't work with the Plain.pm backend.

The difficulty is in the genindex/genrefs functions. These
start by recursing if the argument is a directory, and this
is done by calling $file->getdir($path, $version). However,
with this patch $version will be undef at this point, and
this Does Not Work with Plain.pm. CVS is the odd one out
here - the correct behaviour is that the version must be
specified when doing a getdir, since the contents of a
directory depend on the version in question.

Therefore this patch as it stands can't go into the tree.