Michael G Schwern <[EMAIL PROTECTED]> writes:
> Giving read() semantics completely unrelated to reading a filehandle would
> be a bad choice of syntax.
I wonder what the people who implemented the GNU/Linux "procfs" think
about this.
-- Johan
Michael G Schwern <[EMAIL PROTECTED]> writes:
> And if you're not using a CPAN shell every module install is going
> to be a chore anyway.
Tchk. I think it's quite nice and powerful to be able to download an
arbitrary module's .tar.gz and get it going with the simple "perl
Makefile.PL; make all
Michael G Schwern <[EMAIL PROTECTED]> writes:
> It's probably easier to just make it a normal prerequisite.
My hesitation in doing this is that the module does not need Test::*
for its operation, just for the IVP.
But I tend to agree that making any special provisions for this
purpose is proba
Janek Schleicher <[EMAIL PROTECTED]> writes:
> A good solution from my point of view would be,
> if you could use Makefile.PL to do this job,
> perhaps similar to
> 'PREREQ_PM' => { ... }
> a
> 'PREREQ_TEST_PM' => { ... }
> statement,
> warning the user that the test can't be done without a speci
chromatic <[EMAIL PROTECTED]> writes:
> On Fri, 26 Jul 2002 13:19:51 -0700, Johan Vromans wrote:
> This idea appeals to me, but I have thought of two drawbacks. The first is
> minor, and it's that I don't think Test::Builder should have special logic for
> insta
Folks,
One of the problems I have with using Test::Builder is that I want to
distribute packages to systems that do not (necessarily) have a decent
version of Test::* installed. Now it is easy to include a copy of a
suitable version of Test::Builder with the package (provided it is not
too big).
> # parse the command-line
> -my $result = GetOptions( qw(
> +my $result = GetOptions( map {
> + my $key = $_;
> + $key =~ s/\W.+$//;
> + $key => \$Options{$_};
> +} qw(
> help
> podpath=s
> podroot=s
I'm not sure what you are trying to a
[Quoting Kirrily Robert, on October 9 2001, 23:56, in "Re: Test::Harness in"]
> I think he's trying to say that Perl (i.e. the "Perl community") should
> define these things so that different packagers (Debian, Red Hat,
> whoever) can have somewhat-consistent packages.
Exactly. Sorry for my uncle
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Debian has the beginnings of that. perl-base is the minimum necessary
> to have a useful Perl, basically a binary, the perl man page, and a
> handful of critical modules ...
Wouldn't it be a good idea to try to define packages like these, so
that
[Quoting Michael G Schwern, on October 8 2001, 14:46, in "Re: Test::Harness in"]
> On Mon, Oct 08, 2001 at 10:20:20AM +0200, Johan Vromans wrote:
> > But I agree with everyone who says there should be a better, more
> > generic solution.
>
> Debian. ;)
Actually,
Michael G Schwern <[EMAIL PROTECTED]> writes:
> It means both packages lay claim to /usr/lib/perl5/5.6.0/Test/Harness.pm and
> /usr/share/man/man3/Test::Harness.3pm.gz. Can't happen
Oh yes, it does. Frequently.
I ran into the same problem when I tried to make installable packages
for Getopt::Lo
11 matches
Mail list logo
