App-Tel

 view release on metacpan or  search on metacpan

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/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/Module/Install/FAQ.pod  view on Meta::CPAN

Module::Install::FAQ - Frequently Asked Questions for Module::Install

=head1 DESCRIPTION

Though L<Module::Install> itself has a general FAQ section in the
pod, it's more for advocacy. Here's an incomplete and growing list of
the actual questions I have been frequently asked (or found on the
net) about L<Module::Install>.

=head2 Do I also have to update my CPAN modules every time Module::Install is updated?

The point of L<Module::Install> is let module authors take care of
everything related to updating toolchains for the sake of module
users. So, if you choose to use L<Module::Install>, it's you who
should update toolchains, i.e. L<Module::Install> and other bundled
modules. You should check if there's any significant change/fix in
your toolchains. You should check if your toolchains go along with
other tools users use to install your distributions, or with
the systems users are in, or whatever that matters. In the end,
you are expected to have much more knowledge and willingness than

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

=head2 B<scan_deps>

    $rv_ref = scan_deps(
        files      => \@files,     recurse => $recurse,
        rv         => \%rv,        skip    => \%skip,
        compile    => $compile,    execute => $execute,
    );
    $rv_ref = scan_deps(@files); # shorthand, with recurse => 1

This function scans each file in C<@files>, registering their
dependencies into C<%rv>, and returns a reference to the updated
C<%rv>.  The meaning of keys and values are explained above.

If C<$recurse> is true, C<scan_deps> will call itself recursively,
to perform a breadth-first search on text files (as defined by the
-T operator) found in C<%rv>.

If the C<\%skip> is specified, files that exists as its keys are
skipped.  This is used internally to avoid infinite recursion.

If C<$compile> or C<$execute> is true, runs C<files> in either