App-SimpleBackuper

 view release on metacpan or  search on metacpan

local/lib/perl5/Dist/CheckConflicts.pm  view on Meta::CPAN

=head1 DESCRIPTION

One shortcoming of the CPAN clients that currently exist is that they have no
way of specifying conflicting downstream dependencies of modules. This module
attempts to work around this issue by allowing you to specify conflicting
versions of modules separately, and deal with them after the module is done
installing.

For instance, say you have a module C<Foo>, and some other module C<Bar> uses
C<Foo>. If C<Foo> were to change its API in a non-backwards-compatible way,
this would cause C<Bar> to break until it is updated to use the new API. C<Foo>
can't just depend on the fixed version of C<Bar>, because this will cause a
circular dependency (because C<Bar> is already depending on C<Foo>), and this
doesn't express intent properly anyway - C<Foo> doesn't use C<Bar> at all. The
ideal solution would be for there to be a way to specify conflicting versions
of modules in a way that would let CPAN clients update conflicting modules
automatically after an existing module is upgraded, but until that happens,
this module will allow users to do this manually.

This module accepts a hash of options passed to its C<use> statement, with
these keys being valid:

local/lib/perl5/Module/Build.pm  view on Meta::CPAN

The default value of C<installdirs> is "site".  If you're creating
vendor distributions of module packages, you may want to do something
like this:

  perl Build.PL --installdirs vendor

or

  ./Build install --installdirs vendor

If you're installing an updated version of a module that was included
with perl itself (i.e. a "core module"), then you may set
C<installdirs> to "core" to overwrite the module in its present
location.

(Note that the 'script' line is different from C<MakeMaker> -
unfortunately there's no such thing as "installsitescript" or
"installvendorscript" entry in C<Config.pm>, so we use the
"installsitebin" and "installvendorbin" entries to at least get the
general location right.  In the future, if C<Config.pm> adds some more
appropriate entries, we'll start using those.)

local/lib/perl5/Module/Build.pm  view on Meta::CPAN

C<Module::Build> does not, nor do other pure-perl installers following the
F<Build.PL> spec such as L<Module::Build::Tiny>. In practice, this is usually
not an issue for the end user, as C<make> is already required to install most
CPAN modules, even on Windows.

=item *

L<ExtUtils::MakeMaker> has been a core module in every version of Perl 5, and
must maintain compatibility to install the majority of CPAN modules.
C<Module::Build> was added to core in Perl 5.10 and removed from core in Perl
5.20, and (like L<ExtUtils::MakeMaker>) is only updated to fix critical issues
and maintain compatibility. C<Module::Build> and other non-core installers like
L<Module::Build::Tiny> are installed from CPAN by declaring themselves as a
C<configure> phase prerequisite, and in this way any installer can be used in
place of L<ExtUtils::MakeMaker>.

=item *

Customizing the build process with L<ExtUtils::MakeMaker> involves overriding
certain methods that form the F<Makefile> by defining the subs in the C<MY::>
namespace, requiring in-depth knowledge of F<Makefile>, but allowing targeted

local/lib/perl5/Module/Build/Base.pm  view on Meta::CPAN

      $meta_obj = eval { CPAN::Meta->load_file($file, { lazy_validation => 0 }) };
      last if $meta_obj;
    }
  }

  # maybe get a copy in spec v2 format (regardless of original source)

  my $mymeta_obj;
  if ($meta_obj) {
    # if we have metadata, just update it
    my %updated = (
      %{ $meta_obj->as_struct({ version => 2.0 }) },
      prereqs => $self->_normalize_prereqs,
      dynamic_config => 0,
      generated_by => "Module::Build version $Module::Build::VERSION",
    );
    $mymeta_obj = CPAN::Meta->new( \%updated, { lazy_validation => 0 } );
  }
  else {
    $mymeta_obj = $self->_get_meta_object(quiet => 0, dynamic => 0, fatal => 1, auto => 0);
  }

  my @created = $self->_write_meta_files( $mymeta_obj, 'MYMETA' );

  $self->log_warn("Could not create MYMETA files\n")
    unless @created;

local/lib/perl5/Package/Stash.pm  view on Meta::CPAN

will create C<%Foo::foo>.

Valid options (all optional) are C<filename>, C<first_line_num>, and
C<last_line_num>.

C<$opts{filename}>, C<$opts{first_line_num}>, and C<$opts{last_line_num}> can
be used to indicate where the symbol should be regarded as having been defined.
Currently these values are only used if the symbol is a subroutine ('C<&>'
sigil) and only if C<$^P & 0x10> is true, in which case the special C<%DB::sub>
hash is updated to record the values of C<filename>, C<first_line_num>, and
C<last_line_num> for the subroutine. If these are not passed, their values are
inferred (as much as possible) from C<caller> information.

=head2 remove_glob $name

Removes all package variables with the given name, regardless of sigil.

=head2 has_symbol $variable

Returns whether or not the given package variable (including sigil) exists.

local/lib/perl5/Tie/IxHash.pm  view on Meta::CPAN

=item FETCH, STORE, DELETE, EXISTS

These standard C<TIEHASH> methods mandated by Perl can be used directly.
See the C<tie> entry in perlfunc(1) for details.

=item Push, Pop, Shift, Unshift, Splice

These additional methods resembling Perl functions are available for
operating on key-value pairs in the IxHash. The behavior is the same as the
corresponding perl functions, except when a supplied hash key already exists
in the hash. In that case, the existing value is updated but its order is
not affected.  To unconditionally alter the order of a supplied key-value
pair, first C<DELETE> the IxHash element.

=item Keys

Returns an array of IxHash element keys corresponding to the list of supplied
indices.  Returns an array of all the keys if called without arguments.
Note the return value is mostly only useful when used in a list context
(since perl will convert it to the number of elements in the array when
used in a scalar context, and that may not be very useful).