[23820] in Perl-Users-Digest
Perl-Users Digest, Issue: 6023 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 29 20:56:32 2004
Date: Thu, 29 Jan 2004 17:50:55 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 29 Jan 2004 Volume: 10 Number: 6023
Today's topics:
MultiThreading and 'fork' (Naveen Reddy)
Re: MultiThreading and 'fork' <usenet@morrow.me.uk>
Re: MultiThreading and 'fork' <syscjm@gwu.edu>
Re: MultiThreading and 'fork' (Walter Roberson)
Re: MultiThreading and 'fork' <nospam-abuse@ilyaz.org>
Re: MultiThreading and 'fork' (Walter Roberson)
Re: MultiThreading and 'fork' <usenet@morrow.me.uk>
Re: MultiThreading and 'fork' <nospam-abuse@ilyaz.org>
Re: MultiThreading and 'fork' <usenet@morrow.me.uk>
Re: MultiThreading and 'fork' <nospam-abuse@ilyaz.org>
my own perl "dos->unix"/"unix->dos" <robw@sofw.org>
Re: my own perl "dos->unix"/"unix->dos" <1usa@llenroc.ude>
Re: my own perl "dos->unix"/"unix->dos" <tadmc@augustmail.com>
Re: my own perl "dos->unix"/"unix->dos" <robw@sofw.org>
Re: my own perl "dos->unix"/"unix->dos" <ittyspam@yahoo.com>
Re: my own perl "dos->unix"/"unix->dos" <usenet@morrow.me.uk>
Re: my own perl "dos->unix"/"unix->dos" <bik.mido@tiscalinet.it>
Re: my own perl "dos->unix"/"unix->dos" <noreply@gunnar.cc>
Need help with ExtUtils::MakeMaker <nospam@nospam.com>
Re: Need help with ExtUtils::MakeMaker <kalinaubears@iinet.net.au>
Re: Need help with ExtUtils::MakeMaker <jwillmore@remove.adelphia.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 25 Jan 2004 13:03:57 -0800
From: naveen_reddy_2004@hotmail.com (Naveen Reddy)
Subject: MultiThreading and 'fork'
Message-Id: <dec0b6c6.0401251303.2024a7e9@posting.google.com>
Hello all,
From my Perl program I can spawn a parent and a child process using
the 'fork'.
Is this synonymous to 'multi-threading' and are the 'threads' same as
'processes'?
I'm trying to understand why theres a module for threads, as in, 'use
threads', when fork lets you accomplish the mutiltasking?
Thanks for your time,
Reddy
------------------------------
Date: Sun, 25 Jan 2004 21:16:31 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: MultiThreading and 'fork'
Message-Id: <bv1bnf$kco$1@wisteria.csv.warwick.ac.uk>
naveen_reddy_2004@hotmail.com (Naveen Reddy) wrote:
> Hello all,
> From my Perl program I can spawn a parent and a child process using
> the 'fork'.
> Is this synonymous to 'multi-threading' and are the 'threads' same as
> 'processes'?
No. Have you read perlthrtut?
> I'm trying to understand why theres a module for threads, as in, 'use
> threads', when fork lets you accomplish the mutiltasking?
Threads are lighter than processes (creating many threads consumes
fewer resources than creating many processes), and it is possible to
share variables among threads. In theory all data is shared, but
perl's ithreads copy all the perl data structures when you create a
new thread, except those that are marked shared.
I would say that there is a good case for considering ithreads to be
pretty much redundant with fork() and threads::shared with Sys::Mmap
or some such, but those concepts are not portable outside unix whereas
ithreads are.
Ben
--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine. ben@morrow.me.uk
------------------------------
Date: Sun, 25 Jan 2004 17:39:30 -0500
From: Chris Mattern <syscjm@gwu.edu>
Subject: Re: MultiThreading and 'fork'
Message-Id: <401445A2.3050309@gwu.edu>
Naveen Reddy wrote:
> Hello all,
> From my Perl program I can spawn a parent and a child process using
> the 'fork'.
Well, you can spawn a child process. The parent was there to begin
with.
> Is this synonymous to 'multi-threading' and are the 'threads' same as
> 'processes'?
No. Threads share the same address space.
>
> I'm trying to understand why theres a module for threads, as in, 'use
> threads', when fork lets you accomplish the mutiltasking?
Because fork() has much higher overhead and processes have more
difficulty passing information back and forth.
Chris Mattern
------------------------------
Date: 25 Jan 2004 22:49:33 GMT
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: MultiThreading and 'fork'
Message-Id: <bv1h5t$n2l$1@canopus.cc.umanitoba.ca>
In article <401445A2.3050309@gwu.edu>, Chris Mattern <syscjm@gwu.edu> wrote:
:Naveen Reddy wrote:
:> I'm trying to understand why theres a module for threads, as in, 'use
:> threads', when fork lets you accomplish the mutiltasking?
:Because fork() has much higher overhead and processes have more
:difficulty passing information back and forth.
fork() on modern Unix systems does not necessarily
have more overhead than perl 5.8.2 ithreads .
Many modern unix servers have hardware-supported "copy-on-write"
semantics -- all they have to to is sweep through the existing process
page descriptor table, set the COW bit, and copy the resulting page
descriptor table into the new process.
The current implimentation (5.8.2) of ithreads involves process-level
copying of all existing perl variables that are not marked as shared.
If one has much data at all, that procedure is going to take longer
than the process creation overhead.
In a multi-threaded process I was recently working on, it took
about (roughly) 2 seconds per ithread spawned, whereas fork()'s
take a fraction of a second each.
--
Will you ask your master if he wants to join my court at Camelot?!
------------------------------
Date: Mon, 26 Jan 2004 00:15:07 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: MultiThreading and 'fork'
Message-Id: <bv1m6b$1e0t$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Chris Mattern
<syscjm@gwu.edu>], who wrote in article <401445A2.3050309@gwu.edu>:
> Because fork() has much higher overhead and processes have more
> difficulty passing information back and forth.
Starting from v5.8, perl (by default) does not support threads any
more. v5.9 has no thread support at all.
What v5.8 supports is "emulation of fork() on Win32 systems". This
emulation layer was hacked to implement creation of a "thread +
cloned-interpreter" pair. Creation of such a pair (via the
fork()-emulation layer!) is (in my measurements) 2 orders of magnitude
slower that creation of a new child process.
Hope this helps,
Ilya
------------------------------
Date: 26 Jan 2004 00:20:42 GMT
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: MultiThreading and 'fork'
Message-Id: <bv1mgq$pcs$1@canopus.cc.umanitoba.ca>
In article <bv1m6b$1e0t$1@agate.berkeley.edu>,
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
:Starting from v5.8, perl (by default) does not support threads any
:more. v5.9 has no thread support at all.
Perhaps that needs to be qualified with "ActiveState"? Or are
you referring to 5005 threads as compared to ithreads ??
--
csh is bad drugs.
------------------------------
Date: Mon, 26 Jan 2004 01:15:40 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: MultiThreading and 'fork'
Message-Id: <bv1pns$da$1@wisteria.csv.warwick.ac.uk>
roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
> In article <bv1m6b$1e0t$1@agate.berkeley.edu>,
> Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> :Starting from v5.8, perl (by default) does not support threads any
> :more. v5.9 has no thread support at all.
>
> Perhaps that needs to be qualified with "ActiveState"? Or are
> you referring to 5005 threads as compared to ithreads ??
Of course he is. Given Ilya's previous posts of the evils of fork(),
it is unsurprising he dislikes ithreads. I have to admit, it seems
rather daft to attempt to reimplement in perl something which the OS
does perfectly well; except on those OSen which don't. I have serious
doubts that ithread creation will ever become less expensive than
process creation on a decent unix, simply because they are essentially
the same operation.
Ben
--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine. ben@morrow.me.uk
------------------------------
Date: Mon, 26 Jan 2004 19:53:00 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: MultiThreading and 'fork'
Message-Id: <bv3r6s$20vh$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Ben Morrow
<usenet@morrow.me.uk>], who wrote in article <bv1pns$da$1@wisteria.csv.warwick.ac.uk>:
> > Perhaps that needs to be qualified with "ActiveState"? Or are
> > you referring to 5005 threads as compared to ithreads ??
>
> Of course he is. Given Ilya's previous posts of the evils of fork(),
> it is unsurprising he dislikes ithreads.
Myself, I do not see any connection between these two acts of madness.
Introducing fork() *was* an act of madness in '70; however, today,
when (on Unix) most problems associated with this madness are either
already resolved, or at least well understood, most it deserves is
just a shrug. [Of course, outside of Unix it provides enormous
difficulties to developers, but for the purpose of simiplicity, I
would like to keep the discussion of ithreads focused on one
architecture only.]
The fact that "fork() emulation on Win32" is related to fork() has
little to do with the problem of ithreads. Consider the code to
perform emulation as a black box. It is just a subsystem of Perl
which does "something".
Now somebody got a bright idea: "running this subsystem on Unix will
give us an interpreter running in a new thread; code reuse is a good
thing; let us just use this subsystem to create new threads."
"BTW, a lot of people had problems with running the old model of
threads. We care; let us remove the support for the old model, so
people do not have these problems."
Now we got a system which uses a microscope to pull nails. The
microscope does not care, but the finishing is all ruined.
> I have to admit, it seems rather daft to attempt to reimplement in
> perl something which the OS does perfectly well; except on those
> OSen which don't. I have serious doubts that ithread creation will
> ever become less expensive than process creation on a decent unix,
> simply because they are essentially the same operation.
Are you joking? Did you read the code for fork() emulation? Did you
run any benchmarks? The code is 2 orders of magnitude slower than
process creation.
Try to create 20 ithreads/sec; it may be possible on very recent
hardware, but I think it is close to the current maximum...
Hope this helps,
Ilya
------------------------------
Date: Mon, 26 Jan 2004 20:29:04 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: MultiThreading and 'fork'
Message-Id: <bv3tag$gv1$1@wisteria.csv.warwick.ac.uk>
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> [A complimentary Cc of this posting was sent to
> Ben Morrow
> <usenet@morrow.me.uk>], who wrote in article <bv1pns$da$1@wisteria.csv.warwick.ac.uk>:
> > I have to admit, it seems rather daft to attempt to reimplement in
> > perl something which the OS does perfectly well; except on those
> > OSen which don't. I have serious doubts that ithread creation will
> > ever become less expensive than process creation on a decent unix,
> > simply because they are essentially the same operation.
>
> Are you joking? Did you read the code for fork() emulation? Did you
> run any benchmarks? The code is 2 orders of magnitude slower than
> process creation.
I think you must have misread me. I said that not only is ithread
creation *currently* slower than process creation, but also there are
good reasons for thinking that on a unix system it will *always* be
slower, no matter how much p5p optimize it; namely, that it is
emulating in userland something already implemented perfectly well in
the kernel.
Ben
--
don't get my sympathy hanging out the 15th floor. you've changed the locks 3
times, he still comes reeling though the door, and soon he'll get to you, teach
you how to get to purest hell. you do it to yourself and that's what really
hurts is you do it to yourself just you, you and noone else * ben@morrow.me.uk
------------------------------
Date: Tue, 27 Jan 2004 02:04:51 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: MultiThreading and 'fork'
Message-Id: <bv4h03$28hg$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Ben Morrow
<usenet@morrow.me.uk>], who wrote in article <bv3tag$gv1$1@wisteria.csv.warwick.ac.uk>:
> > Are you joking? Did you read the code for fork() emulation? Did you
> > run any benchmarks? The code is 2 orders of magnitude slower than
> > process creation.
> I think you must have misread me. I said that not only is ithread
> creation *currently* slower than process creation, but also there are
> good reasons for thinking that on a unix system it will *always* be
> slower, no matter how much p5p optimize it; namely, that it is
> emulating in userland something already implemented perfectly well in
> the kernel.
Still: I do not consider your disclaimer sufficient. ;-) The overhead of
creation of a *thread* should/could be orders of magnitude smaller
than the overhead of creation of a new process.
However, the overhead of creation of a *new interpreter* is very large.
And the overhead of *cloning* an interpreter (as opposed to creating a
new one) is jet orders of magnitude larger.
Hope this helps,
Ilya
------------------------------
Date: Wed, 21 Jan 2004 10:24:10 -0500
From: Robert Wallace <robw@sofw.org>
Subject: my own perl "dos->unix"/"unix->dos"
Message-Id: <400E999A.B78701EF@sofw.org>
i made a dos to unix, unix to dos program catered for my own purposes.
it's seems to work fine. small program, 26 lines
anyone see any potential problems with it? do you have a better way to
do it?
my next step is to slip in some code to automatically "detect" whether
its a unix or dos file.
#!/usr/bin/perl -w
use strict;
#setting based on filename argument.
# if sym link is dos-unix or if sym link is unix-dos
my ($from, $to);
my $option=substr($0,rindex($0,'/')+1,length($0)-1); # $0 gives full
path. this code gives just filename
if ($option eq "dos-unix"){
$from="\015\012";
$to ="\012";
} elsif ($option eq "unix-dos"){
$from="[^\015]\012";
$from="[^\015]\012";
$to ="\015\012";
} else {
print "only sym links \"unix-dos\" and \"dos-unix\" are allowed\n";
}
foreach my $file (@ARGV){
my @output;
open READ, $file or die "Could not open file '$file' $!";
while (<READ>){
$_=~s/\Q$from/$to/;
push @output, $_;
}
close (READ);
open WRITE, ">$file" or die "Could not open output file '$file' $!";
print WRITE @output;
close (READ);
}
------------------------------
Date: 21 Jan 2004 16:11:37 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude>
Subject: Re: my own perl "dos->unix"/"unix->dos"
Message-Id: <Xns947771DE947C5asu1cornelledu@132.236.56.8>
Robert Wallace <robw@sofw.org> wrote in news:400E999A.B78701EF@sofw.org:
> i made a dos to unix, unix to dos program catered for my own purposes.
...
> anyone see any potential problems with it? do you have a better way to
> do it?
> #!/usr/bin/perl -w
> use strict;
>
> #setting based on filename argument.
> # if sym link is dos-unix or if sym link is unix-dos
> my ($from, $to);
> my $option=substr($0,rindex($0,'/')+1,length($0)-1); # $0 gives full
If you want your script to work on computers without symlinks, you might
want to handle this using command line options. Also, the line below you
comment is not related to your comment. If you keep with this commenting
style, your comments and code can get really out of sync when the script
gets bigger.
> if ($option eq "dos-unix"){
> $from="\015\012";
> $to ="\012";
> } elsif ($option eq "unix-dos"){
> $from="[^\015]\012";
> $from="[^\015]\012";
Why the repeated assignment to $from?
> $to ="\015\012";
> } else {
> print "only sym links \"unix-dos\" and \"dos-unix\" are allowed\n";
> }
>
> foreach my $file (@ARGV){
> my @output;
> open READ, $file or die "Could not open file '$file' $!";
> while (<READ>){
> $_=~s/\Q$from/$to/;
> push @output, $_;
> }
> close (READ);
I would actually open a temp file (there is a module to do that safely
and cleanly), write my output to that file, and only delete the original
and rename the temp after everything is successfully completed. That
would keep the script's memory usage constant regardless of file size.
> open WRITE, ">$file"
> or die "Could not open output file '$file' $!";
> print WRITE @output;
> close (READ);
> }
Ahem, if an error happens while you are writing to or closing the file,
you will have already clobbered the original. I don't see your script
asking the user if it is OK to nuke his file out of existence if the
conversion fails. Again, using a temporary file would handle this.
First, do no harm.
Sinan.
--
A. Sinan Unur
1usa@llenroc.ude (reverse each component for email address)
------------------------------
Date: Wed, 21 Jan 2004 10:49:49 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: my own perl "dos->unix"/"unix->dos"
Message-Id: <slrnc0tbdd.783.tadmc@magna.augustmail.com>
A. Sinan Unur <1usa@llenroc.ude> wrote:
> Robert Wallace <robw@sofw.org> wrote in news:400E999A.B78701EF@sofw.org:
>> $from="[^\015]\012";
>> $from="[^\015]\012";
>
> Why the repeated assignment to $from?
To make doubly sure that it is set to the correct value?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 21 Jan 2004 13:25:27 -0500
From: Robert Wallace <robw@sofw.org>
Subject: Re: my own perl "dos->unix"/"unix->dos"
Message-Id: <400EC417.83E934E5@sofw.org>
Tad McClellan wrote:
>
> A. Sinan Unur <1usa@llenroc.ude> wrote:
> > Robert Wallace <robw@sofw.org> wrote in news:400E999A.B78701EF@sofw.org:
>
> >> $from="[^\015]\012";
> >> $from="[^\015]\012";
> >
> > Why the repeated assignment to $from?
>
> To make doubly sure that it is set to the correct value?
>
copy and paste from a terminal problem.
copy and paste, scroll down, copy and paste.
what's the big deal. sheesh...
------------------------------
Date: Wed, 21 Jan 2004 13:35:30 -0500
From: Paul Lalli <ittyspam@yahoo.com>
Subject: Re: my own perl "dos->unix"/"unix->dos"
Message-Id: <20040121133251.V28498@dishwasher.cs.rpi.edu>
On Wed, 21 Jan 2004, Robert Wallace wrote:
> anyone see any potential problems with it? do you have a better way to
> do it?
> } elsif ($option eq "unix-dos"){
> $from="[^\015]\012";
> $to ="\015\012";
> }
> while (<READ>){
> $_=~s/\Q$from/$to/;
> push @output, $_;
> }
Are you sure you don't want lookbehinds here? I haven't tried your code,
but it looks to me like you're going to end up replacing both \012 and
whatever character came before it with \015\012. I think you want to
search for \012 that was not preceded by \015, but don't actually match
(and therefore replace) whatever character did precede it. That involves
lookbehinds, I believe.
Paul Lalli
------------------------------
Date: Wed, 21 Jan 2004 19:02:45 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: my own perl "dos->unix"/"unix->dos"
Message-Id: <bumicl$9ei$2@wisteria.csv.warwick.ac.uk>
Robert Wallace <robw@sofw.org> wrote:
> #!/usr/bin/perl -w
> use strict;
use warnings;
is better than -w.
>
> #setting based on filename argument.
> # if sym link is dos-unix or if sym link is unix-dos
> my ($from, $to);
> my $option=substr($0,rindex($0,'/')+1,length($0)-1); # $0 gives full
Use File::Spec or File::Basename to do this sort of thing.
> path. this code gives just filename
I try and keep code wrapped to a reasonable line length; part of doing
this means not putting long comments on the ends of lines.
> if ($option eq "dos-unix"){
> $from="\015\012";
> $to ="\012";
> } elsif ($option eq "unix-dos"){
> $from="[^\015]\012";
> $from="[^\015]\012";
> $to ="\015\012";
> } else {
> print "only sym links \"unix-dos\" and \"dos-unix\" are allowed\n";
Use qq{}.
> }
>
> foreach my $file (@ARGV){
> my @output;
> open READ, $file or die "Could not open file '$file' $!";
Use lexical filehandles, and scope them rather than explicitly closing
where you can.
open my $READ, $file or die...;
> while (<READ>){
> $_=~s/\Q$from/$to/;
> push @output, $_;
> }
> close (READ);
>
> open WRITE, ">$file" or die "Could not open output file '$file' $!";
> print WRITE @output;
> close (READ);
ITYM close (WRITE)?
> }
Ben
--
I've seen things you people wouldn't believe: attack ships on fire off the
shoulder of Orion; I've watched C-beams glitter in the darkness near the
Tannhauser Gate. All these moments will be lost, in time, like tears in rain.
Time to die. |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-| ben@morrow.me.uk
------------------------------
Date: Thu, 22 Jan 2004 23:59:29 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: my own perl "dos->unix"/"unix->dos"
Message-Id: <a7l010h8qp1h8okat3a48bcg6n026tjgq0@4ax.com>
On Wed, 21 Jan 2004 10:24:10 -0500, Robert Wallace <robw@sofw.org>
wrote:
>i made a dos to unix, unix to dos program catered for my own purposes.
>
>it's seems to work fine. small program, 26 lines
Have you ever heard of a (programmer's) virtue called lazyness?
Whenever I'm too lazy to remember which is which and I do not have any
particular requirement but converting to the native convention of the
OS I'm using, I resort to
perl -lpi -e '' <file(s)>
Well that is under Linux, under Win I have to do
perl -lpi.bak -e "" <file(s)>
and
perl -lpi.bak -e "BEGIN{@ARGV=map glob($_),@ARGV}" <file(s)>
if I need to use wildcards. (yes, I know there's an AS executable that
does shell wildcard expansion!)
My program is 1 line only! It is not equivalent to yours though...
;-)
HTH,
Michele
--
# This prints: Just another Perl hacker,
seek DATA,15,0 and print q... <DATA>;
__END__
------------------------------
Date: Thu, 22 Jan 2004 00:28:49 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: my own perl "dos->unix"/"unix->dos"
Message-Id: <bun22n$jvnmu$1@ID-184292.news.uni-berlin.de>
Paul Lalli wrote:
> On Wed, 21 Jan 2004, Robert Wallace wrote:
>>
>>} elsif ($option eq "unix-dos"){
>> $from="[^\015]\012";
>> $to ="\015\012";
>>}
>>
>> while (<READ>){
>> $_=~s/\Q$from/$to/;
>> push @output, $_;
>> }
>
> Are you sure you don't want lookbehinds here? I haven't tried your
> code, but it looks to me like you're going to end up replacing both
> \012 and whatever character came before it with \015\012. I think
> you want to search for \012 that was not preceded by \015, but
> don't actually match (and therefore replace) whatever character did
> precede it. That involves lookbehinds, I believe.
Or capturing:
$from = "([^\015])\012";
...
$_ =~ s/$from/$1$to/;
(quoting meta seems not to be correct)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 26 Jan 2004 17:37:57 +0000 (UTC)
From: jill <nospam@nospam.com>
Subject: Need help with ExtUtils::MakeMaker
Message-Id: <bv3j9l$g6q$1@reader2.panix.com>
I am trying to package a CGI script and associated modules so that
they can be installed using Perl's standard sequence (perl Makefile.PL
&& make && make test && make install).
My installation has some non-standard (although not at all tricky)
features, and I can't figure out how to coax MakeMaker into generating
the right makefile.
(Is it just me, or the documentation for the ExtUtils modules is
far below average for widely used Perl modules? Is there a better
guide to MakeMaker, etc. than the standard documentation. I have
spent many days on this, and I'm about to go nuts. My many posts
on this are a record of my frustration. I have searched *everywhere*
for clarifications on what MakeMaker does, to no avail. The
ExtUtils::ManMaker man page is useless. What is the directory auto
for? What is the file autosplit.ix? Why does MakeMaker generate
the particular directory structure it generates by default? I have
dozens of questions like this, but there's no information anywhere!
What is a developer supposed to do? No wonder managers prefer
Java! But I digress...)
OK, here's the installation structure I'm trying to achieve
(directories are indicated with trailing slashes):
PATH_TO_CGI_DIR/
INSTALL_DIR/
cgi_script.pl
Module_1.pm
Module_1/
Submodule_1.pm (Module_1::Submodule_1 package)
Submodule_2.pm (Module_1::Submodule_2 package)
Module_2.pm
i386-linux/
Module_3.pm
auto/
Module_3/
Module_3.bs
Module_3.so
autosplit.ix
data_dir/
data_file_1
data_file_2
data_subdir_1/
data_file_3
cgi_script.pl uses Module_1, Module_1::Submodule_1, Module_1::Submodule_2,
Module_2, and Module_3 (which is a Perl extension).
The user is supposed to specify the value for PATH_TO_CGI_DIR/INSTALL_DIR,
e.g.:
perl Makefile.PL LIB=${PATH_TO_CGI_DIR}/${INSTALL_DIR}
Could someone be so kind as to tell me what I must put in Makefile.PL
that will result in the above structure?
Many, many thanks!
jill
------------------------------
Date: Tue, 27 Jan 2004 13:20:21 +1100
From: Sisyphus <kalinaubears@iinet.net.au>
Subject: Re: Need help with ExtUtils::MakeMaker
Message-Id: <4015cbd4$0$1728$5a62ac22@freenews.iinet.net.au>
jill wrote:
> (Is it just me, or the documentation for the ExtUtils modules is
> far below average for widely used Perl modules?
>
I also find that much of the documentation is a little too intuitive for
me :-)
> OK, here's the installation structure I'm trying to achieve
> (directories are indicated with trailing slashes):
>
> PATH_TO_CGI_DIR/
> INSTALL_DIR/
> cgi_script.pl
> Module_1.pm
> Module_1/
> Submodule_1.pm (Module_1::Submodule_1 package)
> Submodule_2.pm (Module_1::Submodule_2 package)
> Module_2.pm
> i386-linux/
> Module_3.pm
> auto/
> Module_3/
> Module_3.bs
> Module_3.so
> autosplit.ix
Does Module_3 really need to go into the i386-linux directory ? Module_3
and its compiled '.so' will be found just as well if Module_3 is
placed in the same directory as Module_1 and Module_2. (I'm thinking
that this may be an unnecessary complication, that's all - and that you
can simply let makemaker decide where to put Module_3 without doing
anything special with it. That could mean that Module_3 gets put in the
i386-linux/ directory anyway.)
> data_dir/
> data_file_1
> data_file_2
> data_subdir_1/
> data_file_3
>
> Could someone be so kind as to tell me what I must put in Makefile.PL
> that will result in the above structure?
>
I would certainly have to play around with it to work out an answer - no
doubt you have been doing just that. Actually "play" is hardly the
appropriate word - I imagine it gets fairly tedious.
If you can't get a satisfactory answer here then all I can suggest is
the makemaker mailing list. See http://lists.perl.org .
Cheers,
Rob
--
To reply by email u have to take out the u in kalinaubears.
------------------------------
Date: Tue, 27 Jan 2004 01:20:20 -0500
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: Need help with ExtUtils::MakeMaker
Message-Id: <pan.2004.01.27.06.20.19.25106@remove.adelphia.net>
On Mon, 26 Jan 2004 17:37:57 +0000, jill wrote:
> I am trying to package a CGI script and associated modules so that
> they can be installed using Perl's standard sequence (perl Makefile.PL
> && make && make test && make install).
<snip>
Use h2xs ;-)
This does all of the "nasty" work for you. For example, suppose you want
to create a module called Foo::Bar. If, in a working/temp/whatever
directory, you execute:
h2xs -XAn Foo::Bar
this takes care of creating files for you - to populate with your code.
(Thanks to Randal Schwartz for helping me see the light of modules in his
book "Learning Perl Objects, References, & Modules").
You may also want to look over perltoot, perlboot, perlmod and h2xs.
I don't have any experience with ExtUtils::MakeMaker ... because there are
other tools Perl offers. But, if you *really* want the straight poop on
this module, try posting to comp.lang.perl.modules - which deals with ...
Perl modules ;-)
A side note - Java is far more complicated IMHO. Setting the proper
CLASSPATH alone is a task and a half. Perl is much easier to
incorporate packages into your install. But, of course, it's just my
opinion.
HTH
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
War is peace. Freedom is slavery. Ketchup is a vegetable.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 6023
***************************************
