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