Randy W. Sims wrote:
Thinking more about this, I guess META.yml would need to provide a
little more info to a configure module. Would something like the
following work?
It's probably too late, but I am not keen on YAML. What is wrong with
pure Perl configuration information? YAML is touchy abou
Randy W. Sims wrote:
darren chamberlain wrote:
* Randy W. Sims [2003-11-10 15:49]:
Also, as I noted in the AFS thread the other day, this info should be
written in META.yml so that cpan-testers can determine
programatically whether a module should be tested. Info like required
non-perl packa
darren chamberlain wrote:
* Randy W. Sims [2003-11-10 15:49]:
Also, as I noted in the AFS thread the other day, this info should be
written in META.yml so that cpan-testers can determine programatically
whether a module should be tested. Info like required non-perl packages
and libraries, whe
Hi Sherzod and everybody,
>If the whole library has a dependency, and wouldn't function as intended if
>they are found missing,
>then you have to let Makefile.PL to take care of it (read my prev. message
>to this thread).
Yes, without daemontools installed, my module has nothing else to do on tha
: > In my test script, I cause the test to fail if it
: cannot find a process,
: > 'svscan', running on the machine. Do you think that
: this can cause all the
: > cpan-testers to fail?
If the whole library has a dependency, and wouldn't function as intended if
they are foun
: ...but how would things like AFS be detectible?
Look into standard Config.pm, which will have all the information about
particular Perl installation.
* Randy W. Sims [2003-11-10 15:49]:
> Also, as I noted in the AFS thread the other day, this info should be
> written in META.yml so that cpan-testers can determine programatically
> whether a module should be tested. Info like required non-perl packages
> and libraries, whether the build/test/
darren chamberlain wrote:
* Bruno Negrao [2003-11-10 17:10]:
I?m finishing to write a module, Proc::Daemontools, and it requires that the
daemontools package be installed on a machine for it to work.
Where must I indicate that this module have a dependency? I already wrote
this on the README file
On Mon, Nov 10, 2003 at 03:06:30PM -0500, darren chamberlain wrote:
> > be the TLD since it is mail related?
> >
> > Mail::Mutt::Parser
> >
> > is my guess, but I don't know much about mutt.
>
> Though the idea and syntax originate with mutt (as far as I know, at
> least), the general idea is no
* Bruno Negrao [2003-11-10 17:10]:
> I?m finishing to write a module, Proc::Daemontools, and it requires that the
> daemontools package be installed on a machine for it to work.
> Where must I indicate that this module have a dependency? I already wrote
> this on the README file. Is there any othe
* Terrence Brannon [2003-11-10 08:27]:
> darren chamberlain wrote:
>
> >Is this worth putting onto CPAN,
> >
> it sounds like re-useable functionality, so why not?
That was my thinking.
> >and, if so, what should it be called?
> >The working name is Parse::MuttStylePatterns, but that's a pretty
: Where must I indicate that this module have a dependency?
You have to indicate it in your Makefile.PL. Here is an example of a
Makefile.PL:
WriteMakefile(
NAME=> 'Class::PObject',
VERSION_FROM=> 'PObject.pm',
PREREQ_PM => {
'Storable' => 0,
Bruno Negrao wrote:
Hi all,
I´m finishing to write a module, Proc::Daemontools, and it requires that the
daemontools package be installed on a machine for it to work.
Where must I indicate that this module have a dependency?
I already wrote
this on the README file. Is there any other place?
Hi all,
I´m finishing to write a module, Proc::Daemontools, and it requires that the
daemontools package be installed on a machine for it to work.
Where must I indicate that this module have a dependency? I already wrote
this on the README file. Is there any other place?
In my test script, I caus
darren chamberlain wrote:
Is this worth putting onto CPAN,
it sounds like re-useable functionality, so why not?
and, if so, what should it be called?
The working name is Parse::MuttStylePatterns, but that's a pretty bad
name.
should Mail::
be the TLD since it is mail related?
Mail::Mutt::Pa
> What about:
>
> Daemontools::Installinstall/uninstall a server under daemontools
> (i.e. `ln -s /path-to-startup-dir /service` ...)
>
> Daemontools::Configure daemontools server configuration
> (i.e. `touch /service/qmail/down` ...)
>
> Daemont
Hello, all.
I have a short module that parses arbitrary mutt-style patterns into a hash
(mutt's patterns are documented in section 4.2 of the mutt manual). For
example:
~t foo ~f bar
would turn into:
$VAR1 = {
'f' => {
'value' => 'bar',
'
17 matches
Mail list logo
