Mailing List Archive

Perl module build mechanism
[followup to perl-porters, i imagine]

> tar -xzf ... , ./configure , make , make install

> Why isn't the perl community going with that idiot proof scheme?

That's still too much. Our current scheme of

gzcat Foo.tar.gz | tar xf -
cd Foo
perl Makefile.PL
make
make test
make install

is only somewhat suboptimal.

a stub makefile should be included that bootstraps
a real one via perl Makefile.PL if needed would help.
likewise, if a configure step is needed, that should not
have to be specified. the build system should figure it out
and run it if it needs to.

also, we don't yet have 'make install' include the doc
temp, which would be something like:
pod2man foo.pm > foo.3pm

--tom
Re: Perl module build mechanism [ In reply to ]
On Sun, 27 Aug 1995, Tom Christiansen wrote:

> [followup to perl-porters, i imagine]
>
> > tar -xzf ... , ./configure , make , make install
>
> > Why isn't the perl community going with that idiot proof scheme?
>
> That's still too much. Our current scheme of
>
> gzcat Foo.tar.gz | tar xf -
> cd Foo
> perl Makefile.PL
> make
> make test
> make install
>
> is only somewhat suboptimal.
>
> a stub makefile should be included that bootstraps
> a real one via perl Makefile.PL if needed would help.
> likewise, if a configure step is needed, that should not
> have to be specified. the build system should figure it out
> and run it if it needs to.

The latter isn't a problem, as far as I can see. The Makefile.PL should
invoke the configuration, or write the invokation into the makefile if
there are files that can be used to trigger configuration.

The stub makefile is more of a problem, as we went through before.
Apparently some makes can get confused if you rewrite the Makefile you
are using. And some, like GNU, recognize exactly what you are doing, and
will automatically reinvoke themselves on the new makefile.

> also, we don't yet have 'make install' include the doc
> temp, which would be something like:
> pod2man foo.pm > foo.3pm

How about this: let's add questions to Configure that ask for the section
and extension to use for installing the library man pages. That way we
know what the pages should be called, and where they should go (if
anywhere). The current position of $PERLDIR/man/man3 with an extension of
3p can stay as the default.

MakeMaker can the add to the indicated repository any PODs. (Of course,
some heuristics may be needed to figure out what files have pods, and
what the man pages should be called.)

> --tom

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: Perl module build mechanism [ In reply to ]
On Sun, 27 Aug 1995, Tom Christiansen wrote:

> [followup to perl-porters, i imagine]
>
> > tar -xzf ... , ./configure , make , make install
>
> > Why isn't the perl community going with that idiot proof scheme?
>
> That's still too much. Our current scheme of
>
> gzcat Foo.tar.gz | tar xf -
> cd Foo
> perl Makefile.PL
> make
> make test
> make install
>
> is only somewhat suboptimal.
>
> a stub makefile should be included that bootstraps
> a real one via perl Makefile.PL if needed would help.
> likewise, if a configure step is needed, that should not
> have to be specified. the build system should figure it out
> and run it if it needs to.

The latter isn't a problem, as far as I can see. The Makefile.PL should
invoke the configuration, or write the invokation into the makefile if
there are files that can be used to trigger configuration.

The stub makefile is more of a problem, as we went through before.
Apparently some makes can get confused if you rewrite the Makefile you
are using. And some, like GNU, recognize exactly what you are doing, and
will automatically reinvoke themselves on the new makefile.

> also, we don't yet have 'make install' include the doc
> temp, which would be something like:
> pod2man foo.pm > foo.3pm

How about this: let's add questions to Configure that ask for the section
and extension to use for installing the library man pages. That way we
know what the pages should be called, and where they should go (if
anywhere). The current position of $PERLDIR/man/man3 with an extension of
3p can stay as the default.

MakeMaker can the add to the indicated repository any PODs. (Of course,
some heuristics may be needed to figure out what files have pods, and
what the man pages should be called.)

> --tom

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: Perl module build mechanism [ In reply to ]
>From: Tom Christiansen <tchrist@mox.perl.com>
>
>[followup to perl-porters, i imagine]

ok, this is p5p only.

>
>> tar -xzf ... , ./configure , make , make install
>
>> Why isn't the perl community going with that idiot proof scheme?
>
>That's still too much. Our current scheme of
>
> gzcat Foo.tar.gz | tar xf -
> cd Foo
> perl Makefile.PL
> make
> make test
> make install
>
>is only somewhat suboptimal.
>
>a stub makefile should be included that bootstraps
>a real one via perl Makefile.PL if needed would help.

This has been discussed before. I cannot repeat the whole discussion,
but off the top of my head:

If things go wrong, where do you start again?

Let's say, 'Makefile' is distributed and overwritten by the first call
to 'make' ... difficult.

'Makefile' is distributed and the first thing it did was to write
Makefile.xxx ... if the user fixes something, it's unlikely that the
stub Makefile will recognize the changes. So 'make -f Maekfile.xxx'
will be difficult again and quite non-standard.

A stub makefile will know enough in most of the cases, but if it
doesn't then a divide and conquer technique will help a lot. The
postman always rings twice.

>likewise, if a configure step is needed, that should not
>have to be specified. the build system should figure it out
>and run it if it needs to.

Priority is to have 100% buildability with above steps, and 100%
findability for the most recent version number. Tom, tcgrep is such a
great tool, why doesn't it have a version number? Or does it have?

>
>also, we don't yet have 'make install' include the doc
>temp, which would be something like:
>pod2man foo.pm > foo.3pm

Yes, I'm sorry. I have promised to integrate it into MakeMaker. Will
do ASAP. This week I'm expecting the tax man :(


>
>--tom
>


andreas
Re: Perl module build mechanism [ In reply to ]
On Sun, 27 Aug 1995, Tom Christiansen wrote:

> > > also, we don't yet have 'make install' include the doc
> > > temp, which would be something like:
> > > pod2man foo.pm > foo.3pm
>
> > How about this: let's add questions to Configure that ask for the section
> > and extension to use for installing the library man pages. That way we
> > know what the pages should be called, and where they should go (if
> > anywhere). The current position of $PERLDIR/man/man3 with an extension of
> > 3p can stay as the default.
>
> hm... i suppose that that *is* more in line with
> each major software package having its own bin, lib, and
> man dirs. i've just always kept mine in /usr/local/man/man3/*.3pm myself.

It also solves the problem of "just what is perl doing with the library
man pages?"

> hm.. 14-char filenames might be a problem. oh well, they
> have other problems.

I guess this comes under naming heuristics in MakeMaker.

> --tom

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: Perl module build mechanism [ In reply to ]
On Sun, 27 Aug 1995, Tom Christiansen wrote:

> > > also, we don't yet have 'make install' include the doc
> > > temp, which would be something like:
> > > pod2man foo.pm > foo.3pm
>
> > How about this: let's add questions to Configure that ask for the section
> > and extension to use for installing the library man pages. That way we
> > know what the pages should be called, and where they should go (if
> > anywhere). The current position of $PERLDIR/man/man3 with an extension of
> > 3p can stay as the default.
>
> hm... i suppose that that *is* more in line with
> each major software package having its own bin, lib, and
> man dirs. i've just always kept mine in /usr/local/man/man3/*.3pm myself.

It also solves the problem of "just what is perl doing with the library
man pages?"

> hm.. 14-char filenames might be a problem. oh well, they
> have other problems.

I guess this comes under naming heuristics in MakeMaker.

> --tom

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: Perl module build mechanism [ In reply to ]
> > Priority is to have 100% buildability with above steps, and 100%
> findability for the most recent version number. Tom, tcgrep is such a
> great tool, why doesn't it have a version number? Or does it have?

you really think so, or are you teasing me? it's kinda so--so, although i
do use it a bunch. its version is at 1.1 right now.

# tcgrep: tom christiansen's rewrite of grep
# tchrist@colorado.edu
# see usage for features
# yet to implement: -f
# v1.0: Thu Sep 30 16:24:43 MDT 1993
# v1.1: Fri Oct 1 08:33:43 MDT 1993

> >
> >also, we don't yet have 'make install' include the doc
> >temp, which would be something like:
> >pod2man foo.pm > foo.3pm

> Yes, I'm sorry. I have promised to integrate it into MakeMaker. Will
> do ASAP. This week I'm expecting the tax man :(

cool. that wasn't supposed to be a nudge.

you have more than plenty to worry for a while about given that the
taxman cometh. my deepest sympathies. :-)

--tom
Re: Perl module build mechanism [ In reply to ]
> > also, we don't yet have 'make install' include the doc
> > temp, which would be something like:
> > pod2man foo.pm > foo.3pm

> How about this: let's add questions to Configure that ask for the section
> and extension to use for installing the library man pages. That way we
> know what the pages should be called, and where they should go (if
> anywhere). The current position of $PERLDIR/man/man3 with an extension of
> 3p can stay as the default.

hm... i suppose that that *is* more in line with
each major software package having its own bin, lib, and
man dirs. i've just always kept mine in /usr/local/man/man3/*.3pm myself.

hm.. 14-char filenames might be a problem. oh well, they
have other problems.


--tom
Re: Perl module build mechanism [ In reply to ]
> > also, we don't yet have 'make install' include the doc
> > temp, which would be something like:
> > pod2man foo.pm > foo.3pm

> How about this: let's add questions to Configure that ask for the section
> and extension to use for installing the library man pages. That way we
> know what the pages should be called, and where they should go (if
> anywhere). The current position of $PERLDIR/man/man3 with an extension of
> 3p can stay as the default.

hm... i suppose that that *is* more in line with
each major software package having its own bin, lib, and
man dirs. i've just always kept mine in /usr/local/man/man3/*.3pm myself.

hm.. 14-char filenames might be a problem. oh well, they
have other problems.


--tom
Re: Perl module build mechanism [ In reply to ]
>>>>> "Tom" == Tom Christiansen <tchrist@mox.perl.com> writes:

Tom> you have more than plenty to worry for a while about given that the
Tom> taxman cometh. my deepest sympathies. :-)

At least it's *only* the taxman.

:-)

Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@ora.com)
Web: <A HREF="http://www.teleport.com/~merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
Re: Perl module build mechanism [ In reply to ]
On Sun, 27 Aug 1995, Kenneth Albanowski wrote:

> How about this: let's add questions to Configure that ask for the section
> and extension to use for installing the library man pages. That way we
> know what the pages should be called, and where they should go (if
> anywhere). The current position of $PERLDIR/man/man3 with an extension of
> 3p can stay as the default.

You mean like the following from 5.001m/Configure :-)

################################################
: determine where library module manual pages go
set man3dir man3dir none
eval $prefixit
$cat <<EOM

$spackage has manual pages for many of the library modules.
EOM

[ . . . stuff omitted . . . ]

rp="Where do the $spackage library man pages (source) go?"
. ./getfile
if test "X$man3direxp" != "X$ansexp"; then
installman3dir=''
fi

################################################

It doesn't presently ask for man3ext, it just sets it to '3' in
almost all cases.

Andy Dougherty doughera@lafcol.lafayette.edu
Re: Perl module build mechanism [ In reply to ]
On Sun, 27 Aug 1995, Tom Christiansen wrote:

> hm.. 14-char filenames might be a problem. oh well, they
> have other problems.

Configure already correctly handles this and sets man3dir to ' ', which
means no module man pages are to be installed.

Andy Dougherty doughera@lafcol.lafayette.edu
Re: Perl module build mechanism [ In reply to ]
On Mon, 28 Aug 1995, Andy Dougherty wrote:

> On Sun, 27 Aug 1995, Kenneth Albanowski wrote:
>
> > How about this: let's add questions to Configure that ask for the section
> > and extension to use for installing the library man pages. That way we
> > know what the pages should be called, and where they should go (if
> > anywhere). The current position of $PERLDIR/man/man3 with an extension of
> > 3p can stay as the default.
>
> You mean like the following from 5.001m/Configure :-)
>
> [...]
>
> rp="Where do the $spackage library man pages (source) go?"
> [...]
>
> It doesn't presently ask for man3ext, it just sets it to '3' in
> almost all cases.

That's part of it, but with this .3p issue, it's not the whole thing. I
think we may need three questions:

Where do the library man pages go? [/usr/local/man]

What subdirectory does the source go in? [man3]

What extension do they get? [3p]

> Andy Dougherty doughera@lafcol.lafayette.edu

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)