[p5sagit/p5-mst-13.2.git] / lib / ExtUtils / MakeMaker / FAQ.pod

package ExtUtils::MakeMaker::FAQ;

use vars qw($VERSION);
$VERSION = '1.11_04';

1;
__END__

=head1 NAME

ExtUtils::MakeMaker::FAQ - Frequently Asked Questions About MakeMaker

=head1 DESCRIPTION

FAQs, tricks and tips for C<ExtUtils::MakeMaker>.


=head2 Module Installation

=over 4

=item How do I install a module into my home directory?

If you're not the Perl administrator you probably don't have
permission to install a module to its default location.  Then you
should install it for your own use into your home directory like so:

    perl Makefile.PL INSTALL_BASE=~

This will put modules into F<~/lib/perl5>, man pages into F<~/man> and
programs into F<~/bin>.

To ensure your Perl programs can see these newly installed modules,
set your C<PERL5LIB> environment variable to F<~/lib/perl5> or tell
each of your programs to look in that directory with the following:

    use lib "$ENV{HOME}/lib/perl5";


=item How do I get MakeMaker and Module::Build to install to the same place?

Module::Build, as of 0.28, supports two ways to install to the same
location as MakeMaker.

1) Use INSTALL_BASE / C<--install_base>

MakeMaker (as of 6.31) and Module::Build (as of 0.28) both can install
to the same locations using the "install_base" concept.  See
L<ExtUtils::MakeMaker/INSTALL_BASE> for details.  To get MM and MB to
install to the same location simply set INSTALL_BASE in MM and
C<--install_base> in MB to the same location.

    perl Makefile.PL INSTALL_BASE=/whatever
    perl Build.PL    --install_base /whatever

2) Use PREFIX / C<--prefix>

Module::Build 0.28 added support for C<--prefix> which works like
MakeMaker's PREFIX.

    perl Makefile.PL PREFIX=/whatever
    perl Build.PL    --prefix /whatever


=item How do I keep from installing man pages?

Recent versions of MakeMaker will only install man pages on Unix like
operating systems.

For an individual module:

        perl Makefile.PL INSTALLMAN1DIR=none INSTALLMAN3DIR=none

If you want to suppress man page installation for all modules you have
to reconfigure Perl and tell it 'none' when it asks where to install
man pages.


=item How do I use a module without installing it?

Two ways.  One is to build the module normally...

        perl Makefile.PL
        make
        make test

...and then set the PERL5LIB environment variable to point at the
blib/lib and blib/arch directories.

The other is to install the module in a temporary location.

        perl Makefile.PL INSTALL_BASE=~/tmp
        make
        make test
        make install

And then set PERL5LIB to F<~/tmp/lib/perl5>.  This works well when you
have multiple modules to work with.  It also ensures that the module
goes through its full installation process which may modify it.

=back


=head2 Philosophy and History

=over 4

=item Why not just use <insert other build config tool here>?

Why did MakeMaker reinvent the build configuration wheel?  Why not
just use autoconf or automake or ppm or Ant or ...

There are many reasons, but the major one is cross-platform
compatibility.

Perl is one of the most ported pieces of software ever.  It works on
operating systems I've never even heard of (see perlport for details).
It needs a build tool that can work on all those platforms and with
any wacky C compilers and linkers they might have.

No such build tool exists.  Even make itself has wildly different
dialects.  So we have to build our own.


=item What is Module::Build and how does it relate to MakeMaker?

Module::Build is a project by Ken Williams to supplant MakeMaker.
Its primary advantages are:

=over 8

=item * pure perl.  no make, no shell commands

=item * easier to customize

=item * cleaner internals

=item * less cruft

=back

Module::Build is the official heir apparent to MakeMaker and we
encourage people to work on M::B rather than spending time adding features
to MakeMaker.

=back


=head2 Module Writing

=over 4

=item How do I keep my $VERSION up to date without resetting it manually?

Often you want to manually set the $VERSION in the main module
distribution because this is the version that everybody sees on CPAN
and maybe you want to customize it a bit.  But for all the other
modules in your dist, $VERSION is really just bookkeeping and all that's
important is it goes up every time the module is changed.  Doing this
by hand is a pain and you often forget.

Simplest way to do it automatically is to use your version control
system's revision number (you are using version control, right?).

In CVS, RCS and SVN you use $Revision$ (see the documentation of your
version control system for details).  Every time the file is checked
in the $Revision$ will be updated, updating your $VERSION.

SVN uses a simple integer for $Revision$ so you can adapt it for your
$VERSION like so:

    $VERSION = (q$Revision$) =~ /(\d+)/g;

In CVS and RCS version 1.9 is followed by 1.10.  Since CPAN compares
version numbers numerically we use a sprintf() to convert 1.9 to 1.009
and 1.10 to 1.010 which compare properly.

    $VERSION = sprintf "%d.%03d", q$Revision$ =~ /(\d+)\.(\d+)/g;

If branches are involved (ie. $Revision: 1.5.3.4$) its a little more
complicated.

    # must be all on one line or MakeMaker will get confused.
    $VERSION = do { my @r = (q$Revision$ =~ /\d+/g); sprintf "%d."."%03d" x $#r, @r };

In SVN, $Revision$ should be the same for every file in the project so
they would all have the same $VERSION.  CVS and RCS have a different
$Revision$ per file so each file will have a differnt $VERSION.
Distributed version control systems, such as SVK, may have a different
$Revision$ based on who checks out the file leading to a different $VERSION
on each machine!  Finally, some distributed version control systems, such
as darcs, have no concept of revision number at all.


=item What's this F<META.yml> thing and how did it get in my F<MANIFEST>?!

F<META.yml> is a module meta-data file pioneered by Module::Build and
automatically generated as part of the 'distdir' target (and thus
'dist').  See L<ExtUtils::MakeMaker/"Module Meta-Data">.

To shut off its generation, pass the C<NO_META> flag to C<WriteMakefile()>.


=item How do I delete everything not in my F<MANIFEST>?

Some folks are surpried that C<make distclean> does not delete
everything not listed in their MANIFEST (thus making a clean
distribution) but only tells them what they need to delete.  This is
done because it is considered too dangerous.  While developing your
module you might write a new file, not add it to the MANIFEST, then
run a C<distclean> and be sad because your new work was deleted.

If you really want to do this, you can use
C<ExtUtils::Manifest::manifind()> to read the MANIFEST and File::Find
to delete the files.  But you have to be careful.  Here's a script to
do that.  Use at your own risk.  Have fun blowing holes in your foot.

    #!/usr/bin/perl -w
    
    use strict;
    
    use File::Spec;
    use File::Find;
    use ExtUtils::Manifest qw(maniread);
    
    my %manifest = map  {( $_ => 1 )}
                   grep { File::Spec->canonpath($_) }
                        keys %{ maniread() };

    if( !keys %manifest ) {
        print "No files found in MANIFEST.  Stopping.\n";
        exit;
    }
    
    find({
          wanted   => sub {
              my $path = File::Spec->canonpath($_);
    
              return unless -f $path;
              return if exists $manifest{ $path };
    
              print "unlink $path\n";
              unlink $path;
          },
          no_chdir => 1
         },
         "."
    );


=back

=head2 XS

=over 4

=item How to I prevent "object version X.XX does not match bootstrap parameter Y.YY" errors?

XS code is very sensitive to the module version number and will
complain if the version number in your Perl module doesn't match.  If
you change your module's version # without rerunning Makefile.PL the old
version number will remain in the Makefile causing the XS code to be built
with the wrong number.

To avoid this, you can force the Makefile to be rebuilt whenever you
change the module containing the version number by adding this to your
WriteMakefile() arguments.

    depend => { '$(FIRST_MAKEFILE)' => '$(VERSION_FROM)' }


=item How do I make two or more XS files coexist in the same directory?

Sometimes you need to have two and more XS files in the same package.
One way to go is to put them into separate directories, but sometimes
this is not the most suitable solution. The following technique allows
you to put two (and more) XS files in the same directory.

Let's assume that we have a package C<Cool::Foo>, which includes
C<Cool::Foo> and C<Cool::Bar> modules each having a separate XS
file. First we use the following I<Makefile.PL>:

  use ExtUtils::MakeMaker;

  WriteMakefile(
      NAME		=> 'Cool::Foo',
      VERSION_FROM	=> 'Foo.pm',
      OBJECT              => q/$(O_FILES)/,
      # ... other attrs ...
  );

Notice the C<OBJECT> attribute. MakeMaker generates the following
variables in I<Makefile>:

  # Handy lists of source code files:
  XS_FILES= Bar.xs \
  	Foo.xs
  C_FILES = Bar.c \
  	Foo.c
  O_FILES = Bar.o \
  	Foo.o

Therefore we can use the C<O_FILES> variable to tell MakeMaker to use
these objects into the shared library.

That's pretty much it. Now write I<Foo.pm> and I<Foo.xs>, I<Bar.pm>
and I<Bar.xs>, where I<Foo.pm> bootstraps the shared library and
I<Bar.pm> simply loading I<Foo.pm>.

The only issue left is to how to bootstrap I<Bar.xs>. This is done
from I<Foo.xs>:

  MODULE = Cool::Foo PACKAGE = Cool::Foo

  BOOT:
  # boot the second XS file
  boot_Cool__Bar(aTHX_ cv);

If you have more than two files, this is the place where you should
boot extra XS files from.

The following four files sum up all the details discussed so far.

  Foo.pm:
  -------
  package Cool::Foo;

  require DynaLoader;

  our @ISA = qw(DynaLoader);
  our $VERSION = '0.01';
  bootstrap Cool::Foo $VERSION;

  1;

  Bar.pm:
  -------
  package Cool::Bar;

  use Cool::Foo; # bootstraps Bar.xs

  1;

  Foo.xs:
  -------
  #include "EXTERN.h"
  #include "perl.h"
  #include "XSUB.h"

  MODULE = Cool::Foo  PACKAGE = Cool::Foo

  BOOT:
  # boot the second XS file
  boot_Cool__Bar(aTHX_ cv);

  MODULE = Cool::Foo  PACKAGE = Cool::Foo  PREFIX = cool_foo_

  void
  cool_foo_perl_rules()

      CODE:
      fprintf(stderr, "Cool::Foo says: Perl Rules\n");

  Bar.xs:
  -------
  #include "EXTERN.h"
  #include "perl.h"
  #include "XSUB.h"

  MODULE = Cool::Bar  PACKAGE = Cool::Bar PREFIX = cool_bar_

  void
  cool_bar_perl_rules()

      CODE:
      fprintf(stderr, "Cool::Bar says: Perl Rules\n");

And of course a very basic test:

  t/cool.t:
  --------
  use Test;
  BEGIN { plan tests => 1 };
  use Cool::Foo;
  use Cool::Bar;
  Cool::Foo::perl_rules();
  Cool::Bar::perl_rules();
  ok 1;

This tip has been brought to you by Nick Ing-Simmons and Stas Bekman.

=back

=head1 PATCHING

If you have a question you'd like to see added to the FAQ (whether or
not you have the answer) please send it to makemaker@perl.org.

=head1 AUTHOR

The denizens of makemaker@perl.org.

=head1 SEE ALSO

L<ExtUtils::MakeMaker>

=cut
Commit	Line	Data
479d2113	1	package ExtUtils::MakeMaker::FAQ;
479d2113	2
7292dc67	3	use vars qw($VERSION);
58d32538	4	$VERSION = '1.11_04';
479d2113	5
	6	1;
	7	__END__
	8
	9	=head1 NAME
	10
	11	ExtUtils::MakeMaker::FAQ - Frequently Asked Questions About MakeMaker
	12
	13	=head1 DESCRIPTION
	14
	15	FAQs, tricks and tips for C<ExtUtils::MakeMaker>.
	16
03c94fc2	17
	18	=head2 Module Installation
	19
	20	=over 4
	21
58d32538	22	=item How do I install a module into my home directory?
	23
	24	If you're not the Perl administrator you probably don't have
	25	permission to install a module to its default location. Then you
	26	should install it for your own use into your home directory like so:
	27
	28	perl Makefile.PL INSTALL_BASE=~
	29
	30	This will put modules into F<~/lib/perl5>, man pages into F<~/man> and
	31	programs into F<~/bin>.
	32
	33	To ensure your Perl programs can see these newly installed modules,
	34	set your C<PERL5LIB> environment variable to F<~/lib/perl5> or tell
	35	each of your programs to look in that directory with the following:
	36
	37	use lib "$ENV{HOME}/lib/perl5";
	38
	39
	40	=item How do I get MakeMaker and Module::Build to install to the same place?
	41
	42	Module::Build, as of 0.28, supports two ways to install to the same
	43	location as MakeMaker.
	44
	45	1) Use INSTALL_BASE / C<--install_base>
	46
	47	MakeMaker (as of 6.31) and Module::Build (as of 0.28) both can install
	48	to the same locations using the "install_base" concept. See
	49	L<ExtUtils::MakeMaker/INSTALL_BASE> for details. To get MM and MB to
	50	install to the same location simply set INSTALL_BASE in MM and
	51	C<--install_base> in MB to the same location.
	52
	53	perl Makefile.PL INSTALL_BASE=/whatever
	54	perl Build.PL --install_base /whatever
	55
	56	2) Use PREFIX / C<--prefix>
	57
	58	Module::Build 0.28 added support for C<--prefix> which works like
	59	MakeMaker's PREFIX.
	60
	61	perl Makefile.PL PREFIX=/whatever
	62	perl Build.PL --prefix /whatever
	63
	64
03c94fc2	65	=item How do I keep from installing man pages?
	66
	67	Recent versions of MakeMaker will only install man pages on Unix like
	68	operating systems.
	69
	70	For an individual module:
	71
	72	perl Makefile.PL INSTALLMAN1DIR=none INSTALLMAN3DIR=none
	73
	74	If you want to suppress man page installation for all modules you have
	75	to reconfigure Perl and tell it 'none' when it asks where to install
	76	man pages.
	77
	78
	79	=item How do I use a module without installing it?
	80
	81	Two ways. One is to build the module normally...
	82
	83	perl Makefile.PL
	84	make
58d32538	85	make test
03c94fc2	86
	87	...and then set the PERL5LIB environment variable to point at the
	88	blib/lib and blib/arch directories.
	89
	90	The other is to install the module in a temporary location.
	91
58d32538	92	perl Makefile.PL INSTALL_BASE=~/tmp
	93	make
	94	make test
	95	make install
03c94fc2	96
58d32538	97	And then set PERL5LIB to F<~/tmp/lib/perl5>. This works well when you
	98	have multiple modules to work with. It also ensures that the module
	99	goes through its full installation process which may modify it.
03c94fc2	100
	101	=back
	102
	103
479d2113	104	=head2 Philosophy and History
	105
	106	=over 4
	107
	108	=item Why not just use <insert other build config tool here>?
	109
	110	Why did MakeMaker reinvent the build configuration wheel? Why not
	111	just use autoconf or automake or ppm or Ant or ...
	112
	113	There are many reasons, but the major one is cross-platform
	114	compatibility.
	115
	116	Perl is one of the most ported pieces of software ever. It works on
	117	operating systems I've never even heard of (see perlport for details).
	118	It needs a build tool that can work on all those platforms and with
03c94fc2	119	any wacky C compilers and linkers they might have.
479d2113	120
03c94fc2	121	No such build tool exists. Even make itself has wildly different
03c94fc2	122	dialects. So we have to build our own.
479d2113	123
479d2113	124
03c94fc2	125	=item What is Module::Build and how does it relate to MakeMaker?
479d2113	126
	127	Module::Build is a project by Ken Williams to supplant MakeMaker.
	128	Its primary advantages are:
	129
	130	=over 8
	131
	132	=item * pure perl. no make, no shell commands
	133
	134	=item * easier to customize
	135
	136	=item * cleaner internals
	137
	138	=item * less cruft
	139
	140	=back
	141
	142	Module::Build is the official heir apparent to MakeMaker and we
03c94fc2	143	encourage people to work on M::B rather than spending time adding features
03c94fc2	144	to MakeMaker.
479d2113	145
	146	=back
	147
03c94fc2	148
2530b651	149	=head2 Module Writing
	150
	151	=over 4
	152
e3aa3ecb	153	=item How do I keep my $VERSION up to date without resetting it manually?
2530b651	154
	155	Often you want to manually set the $VERSION in the main module
	156	distribution because this is the version that everybody sees on CPAN
	157	and maybe you want to customize it a bit. But for all the other
	158	modules in your dist, $VERSION is really just bookkeeping and all that's
	159	important is it goes up every time the module is changed. Doing this
	160	by hand is a pain and you often forget.
	161
	162	Simplest way to do it automatically is to use your version control
	163	system's revision number (you are using version control, right?).
	164
7292dc67	165	In CVS, RCS and SVN you use $Revision$ (see the documentation of your
2977d345	166	version control system for details). Every time the file is checked
2977d345	167	in the $Revision$ will be updated, updating your $VERSION.
2530b651	168
2977d345	169	SVN uses a simple integer for $Revision$ so you can adapt it for your
2977d345	170	$VERSION like so:
2530b651	171
2977d345	172	$VERSION = (q$Revision$) =~ /(\d+)/g;
2530b651	173
2977d345	174	In CVS and RCS version 1.9 is followed by 1.10. Since CPAN compares
	175	version numbers numerically we use a sprintf() to convert 1.9 to 1.009
	176	and 1.10 to 1.010 which compare properly.
	177
	178	$VERSION = sprintf "%d.%03d", q$Revision$ =~ /(\d+)\.(\d+)/g;
2530b651	179
7292dc67	180	If branches are involved (ie. $Revision: 1.5.3.4$) its a little more
2530b651	181	complicated.
	182
	183	# must be all on one line or MakeMaker will get confused.
7292dc67	184	$VERSION = do { my @r = (q$Revision$ =~ /\d+/g); sprintf "%d."."%03d" x $#r, @r };
2530b651	185
2977d345	186	In SVN, $Revision$ should be the same for every file in the project so
	187	they would all have the same $VERSION. CVS and RCS have a different
	188	$Revision$ per file so each file will have a differnt $VERSION.
	189	Distributed version control systems, such as SVK, may have a different
	190	$Revision$ based on who checks out the file leading to a different $VERSION
	191	on each machine! Finally, some distributed version control systems, such
	192	as darcs, have no concept of revision number at all.
	193
	194
e3aa3ecb	195	=item What's this F<META.yml> thing and how did it get in my F<MANIFEST>?!
c2990482	196
	197	F<META.yml> is a module meta-data file pioneered by Module::Build and
	198	automatically generated as part of the 'distdir' target (and thus
	199	'dist'). See L<ExtUtils::MakeMaker/"Module Meta-Data">.
	200
	201	To shut off its generation, pass the C<NO_META> flag to C<WriteMakefile()>.
2530b651	202
58d32538	203
	204	=item How do I delete everything not in my F<MANIFEST>?
	205
	206	Some folks are surpried that C<make distclean> does not delete
	207	everything not listed in their MANIFEST (thus making a clean
	208	distribution) but only tells them what they need to delete. This is
	209	done because it is considered too dangerous. While developing your
	210	module you might write a new file, not add it to the MANIFEST, then
	211	run a C<distclean> and be sad because your new work was deleted.
	212
	213	If you really want to do this, you can use
	214	C<ExtUtils::Manifest::manifind()> to read the MANIFEST and File::Find
	215	to delete the files. But you have to be careful. Here's a script to
	216	do that. Use at your own risk. Have fun blowing holes in your foot.
	217
	218	#!/usr/bin/perl -w
	219
	220	use strict;
	221
	222	use File::Spec;
	223	use File::Find;
	224	use ExtUtils::Manifest qw(maniread);
	225
	226	my %manifest = map {( $_ => 1 )}
	227	grep { File::Spec->canonpath($_) }
	228	keys %{ maniread() };
	229
	230	if( !keys %manifest ) {
	231	print "No files found in MANIFEST. Stopping.\n";
	232	exit;
	233	}
	234
	235	find({
	236	wanted => sub {
	237	my $path = File::Spec->canonpath($_);
	238
	239	return unless -f $path;
	240	return if exists $manifest{ $path };
	241
	242	print "unlink $path\n";
	243	unlink $path;
	244	},
	245	no_chdir => 1
	246	},
	247	"."
	248	);
	249
	250
2530b651	251	=back
2530b651	252
479d2113	253	=head2 XS
	254
	255	=over 4
	256
e3aa3ecb	257	=item How to I prevent "object version X.XX does not match bootstrap parameter Y.YY" errors?
dedf98bc	258
	259	XS code is very sensitive to the module version number and will
	260	complain if the version number in your Perl module doesn't match. If
c2878c71	261	you change your module's version # without rerunning Makefile.PL the old
dedf98bc	262	version number will remain in the Makefile causing the XS code to be built
	263	with the wrong number.
	264
	265	To avoid this, you can force the Makefile to be rebuilt whenever you
	266	change the module containing the version number by adding this to your
	267	WriteMakefile() arguments.
	268
	269	depend => { '$(FIRST_MAKEFILE)' => '$(VERSION_FROM)' }
	270
	271
e3aa3ecb	272	=item How do I make two or more XS files coexist in the same directory?
479d2113	273
	274	Sometimes you need to have two and more XS files in the same package.
	275	One way to go is to put them into separate directories, but sometimes
	276	this is not the most suitable solution. The following technique allows
	277	you to put two (and more) XS files in the same directory.
	278
	279	Let's assume that we have a package C<Cool::Foo>, which includes
	280	C<Cool::Foo> and C<Cool::Bar> modules each having a separate XS
	281	file. First we use the following I<Makefile.PL>:
	282
	283	use ExtUtils::MakeMaker;
	284
	285	WriteMakefile(
	286	NAME => 'Cool::Foo',
	287	VERSION_FROM => 'Foo.pm',
	288	OBJECT => q/$(O_FILES)/,
	289	# ... other attrs ...
	290	);
	291
	292	Notice the C<OBJECT> attribute. MakeMaker generates the following
	293	variables in I<Makefile>:
	294
	295	# Handy lists of source code files:
	296	XS_FILES= Bar.xs \
	297	Foo.xs
	298	C_FILES = Bar.c \
	299	Foo.c
	300	O_FILES = Bar.o \
	301	Foo.o
	302
	303	Therefore we can use the C<O_FILES> variable to tell MakeMaker to use
	304	these objects into the shared library.
	305
	306	That's pretty much it. Now write I<Foo.pm> and I<Foo.xs>, I<Bar.pm>
	307	and I<Bar.xs>, where I<Foo.pm> bootstraps the shared library and
	308	I<Bar.pm> simply loading I<Foo.pm>.
	309
	310	The only issue left is to how to bootstrap I<Bar.xs>. This is done
	311	from I<Foo.xs>:
	312
	313	MODULE = Cool::Foo PACKAGE = Cool::Foo
	314
	315	BOOT:
	316	# boot the second XS file
	317	boot_Cool__Bar(aTHX_ cv);
	318
	319	If you have more than two files, this is the place where you should
	320	boot extra XS files from.
	321
	322	The following four files sum up all the details discussed so far.
	323
	324	Foo.pm:
	325	-------
	326	package Cool::Foo;
	327
	328	require DynaLoader;
	329
	330	our @ISA = qw(DynaLoader);
	331	our $VERSION = '0.01';
	332	bootstrap Cool::Foo $VERSION;
	333
	334	1;
	335
	336	Bar.pm:
337	-------
338	package Cool::Bar;
339
340	use Cool::Foo; # bootstraps Bar.xs
341
342	1;
343
344	Foo.xs:
345	-------
346	#include "EXTERN.h"
347	#include "perl.h"
348	#include "XSUB.h"
349
350	MODULE = Cool::Foo PACKAGE = Cool::Foo
351
352	BOOT:
353	# boot the second XS file
354	boot_Cool__Bar(aTHX_ cv);
355
356	MODULE = Cool::Foo PACKAGE = Cool::Foo PREFIX = cool_foo_
357
358	void
359	cool_foo_perl_rules()
360
361	CODE:
362	fprintf(stderr, "Cool::Foo says: Perl Rules\n");
363
364	Bar.xs:
365	-------
366	#include "EXTERN.h"
367	#include "perl.h"
368	#include "XSUB.h"
369
370	MODULE = Cool::Bar PACKAGE = Cool::Bar PREFIX = cool_bar_
371
372	void
373	cool_bar_perl_rules()
374
375	CODE:
376	fprintf(stderr, "Cool::Bar says: Perl Rules\n");
377
378	And of course a very basic test:
379
58d32538	380	t/cool.t:
479d2113	381	--------
	382	use Test;
	383	BEGIN { plan tests => 1 };
	384	use Cool::Foo;
	385	use Cool::Bar;
	386	Cool::Foo::perl_rules();
	387	Cool::Bar::perl_rules();
	388	ok 1;
	389
	390	This tip has been brought to you by Nick Ing-Simmons and Stas Bekman.
	391
	392	=back
	393
	394	=head1 PATCHING
	395
	396	If you have a question you'd like to see added to the FAQ (whether or
	397	not you have the answer) please send it to makemaker@perl.org.
	398
	399	=head1 AUTHOR
	400
	401	The denizens of makemaker@perl.org.
	402
	403	=head1 SEE ALSO
	404
	405	L<ExtUtils::MakeMaker>
	406
	407	=cut