1package ExtUtils::MakeMaker::Tutorial;
2
3our $VERSION = '7.62';
4$VERSION =~ tr/_//d;
5
6
7=head1 NAME
8
9ExtUtils::MakeMaker::Tutorial - Writing a module with MakeMaker
10
11=head1 SYNOPSIS
12
13    use ExtUtils::MakeMaker;
14
15    WriteMakefile(
16        NAME            => 'Your::Module',
17        VERSION_FROM    => 'lib/Your/Module.pm'
18    );
19
20=head1 DESCRIPTION
21
22This is a short tutorial on writing a simple module with MakeMaker.
23It's really not that hard.
24
25
26=head2 The Mantra
27
28MakeMaker modules are installed using this simple mantra
29
30        perl Makefile.PL
31        make
32        make test
33        make install
34
35There are lots more commands and options, but the above will do it.
36
37
38=head2 The Layout
39
40The basic files in a module look something like this.
41
42        Makefile.PL
43        MANIFEST
44        lib/Your/Module.pm
45
46That's all that's strictly necessary.  There's additional files you might
47want:
48
49        lib/Your/Other/Module.pm
50        t/some_test.t
51        t/some_other_test.t
52        Changes
53        README
54        INSTALL
55        MANIFEST.SKIP
56        bin/some_program
57
58=over 4
59
60=item Makefile.PL
61
62When you run Makefile.PL, it makes a Makefile.  That's the whole point of
63MakeMaker.  The Makefile.PL is a simple program which loads
64ExtUtils::MakeMaker and runs the WriteMakefile() function to generate a
65Makefile.
66
67Here's an example of what you need for a simple module:
68
69    use ExtUtils::MakeMaker;
70
71    WriteMakefile(
72        NAME            => 'Your::Module',
73        VERSION_FROM    => 'lib/Your/Module.pm'
74    );
75
76NAME is the top-level namespace of your module.  VERSION_FROM is the file
77which contains the $VERSION variable for the entire distribution.  Typically
78this is the same as your top-level module.
79
80
81=item MANIFEST
82
83A simple listing of all the files in your distribution.
84
85        Makefile.PL
86        MANIFEST
87        lib/Your/Module.pm
88
89File paths in a MANIFEST always use Unix conventions (ie. /) even if you're
90not on Unix.
91
92You can write this by hand or generate it with 'make manifest'.
93
94See L<ExtUtils::Manifest> for more details.
95
96
97=item lib/
98
99This is the directory where the .pm and .pod files you wish to have
100installed go.  They are laid out according to namespace.  So Foo::Bar
101is F<lib/Foo/Bar.pm>.
102
103
104=item t/
105
106Tests for your modules go here.  Each test filename ends with a .t.
107So F<t/foo.t>  'make test' will run these tests.
108
109Typically, the F<t/> test directory is flat, with all test files located
110directly within it. However, you can nest tests within subdirectories, for
111example:
112
113    t/foo/subdir_test.t
114
115To do this, you need to inform C<WriteMakeFile()> in your I<Makefile.PL> file
116in the following fashion:
117
118    test => {TESTS => 't/*.t t/*/*.t'}
119
120That will run all tests in F<t/>, as well as all tests in all subdirectories
121that reside under F<t/>. You can nest as deeply as makes sense for your project.
122Simply add another entry in the test location string. For example, to test:
123
124    t/foo/bar/subdir_test.t
125
126You would use the following C<test> directive:
127
128    test => {TESTS => 't/*.t t/*/*/*.t'}
129
130Note that in the above example, tests in the first subdirectory will not be
131run. To run all tests in the intermediary subdirectory preceding the one
132the test files are in, you need to explicitly note it:
133
134    test => {TESTS => 't/*.t t/*/*.t t/*/*/*.t'}
135
136You don't need to specify wildcards if you only want to test within specific
137subdirectories. The following example will only run tests in F<t/foo>:
138
139    test => {TESTS => 't/foo/*.t'}
140
141Tests are run from the top level of your distribution.  So inside a test
142you would refer to ./lib to enter the lib directory, for example.
143
144
145=item Changes
146
147A log of changes you've made to this module.  The layout is free-form.
148Here's an example:
149
150    1.01 Fri Apr 11 00:21:25 PDT 2003
151        - thing() does some stuff now
152        - fixed the wiggy bug in withit()
153
154    1.00 Mon Apr  7 00:57:15 PDT 2003
155        - "Rain of Frogs" now supported
156
157
158=item README
159
160A short description of your module, what it does, why someone would use it
161and its limitations.  CPAN automatically pulls your README file out of
162the archive and makes it available to CPAN users, it is the first thing
163they will read to decide if your module is right for them.
164
165
166=item INSTALL
167
168Instructions on how to install your module along with any dependencies.
169Suggested information to include here:
170
171    any extra modules required for use
172    the minimum version of Perl required
173    if only works on certain operating systems
174
175
176=item MANIFEST.SKIP
177
178A file full of regular expressions to exclude when using 'make
179manifest' to generate the MANIFEST.  These regular expressions
180are checked against each file path found in the distribution (so
181you're matching against "t/foo.t" not "foo.t").
182
183Here's a sample:
184
185    ~$          # ignore emacs and vim backup files
186    .bak$       # ignore manual backups
187    \#          # ignore CVS old revision files and emacs temp files
188
189Since # can be used for comments, # must be escaped.
190
191MakeMaker comes with a default MANIFEST.SKIP to avoid things like
192version control directories and backup files.  Specifying your own
193will override this default.
194
195
196=item bin/
197
198
199=back
200
201=head1 SEE ALSO
202
203L<perlmodstyle> gives stylistic help writing a module.
204
205L<perlnewmod> gives more information about how to write a module.
206
207There are modules to help you through the process of writing a module:
208L<ExtUtils::ModuleMaker>, L<Module::Starter>, L<Minilla::Tutorial>,
209L<Dist::Milla::Tutorial>, L<Dist::Zilla::Starter>
210
211=cut
212
2131;
214