# from Ken Williams on Tuesday 12 June 2007 09:00 pm:
>It's currently exactly analogous to the
>other prereq types, except that during the "dist" action we'll warn
>the author if there's an item in config_requires that isn't present
>in any of the other prereq fields.
# from Ken Williams on
On Jun 13, 2007, at 3:32 PM, Eric Wilhelm wrote:
# from Ken Williams
# on Tuesday 12 June 2007 09:00 pm:
In most cases, M::B will be the only c_r entry (and will be auto.) I
would really like to not need to state any explicit M::B
requirement in
Build.PL, so then you get into special-casin
# from Andreas J. Koenig
# on Wednesday 13 June 2007 11:14 pm:
>You left one spot out:
>
>% grep -rn config_requires .
>./website/META-spec.pod:262: config_requires:
Got it. Thanks.
$ svn diff -r 9643:HEAD | grep config_
--Eric
--
Issues of control, repair, improvement, cost, or just plain
u
> On Wed, 13 Jun 2007 21:41:53 -0500, Ken Williams <[EMAIL PROTECTED]> said:
> I guess I don't feel super-strongly about it though, so I'll rename it
> in homage to its creator.
You left one spot out:
% grep -rn config_requires .
./website/META-spec.pod:262: config_requires:
--
andre
On Jun 13, 2007, at 9:15 PM, Adam Kennedy wrote:
Yes, it is currently in the wild (in a fairly unobtrusive way though).
As to noun vs verb, the reason that we need the key at all is
specifically because the ./Configure installation phase is turing-
complete and not static.
Well yeah, but
I like "config", because "configure" is a verb and "config" (or
"configuration") is a noun - the stage where you configure. Verbs
can't require things, but nouns can.
Eric mentioned that configure_requires is already in the wild,
though. Is that the case?
Also I hope you just accidental
# from Ken Williams
# on Tuesday 12 June 2007 09:00 pm:
>It's currently exactly analogous to the
>other prereq types, except that during the "dist" action we'll warn
>the author if there's an item in config_requires that isn't present
>in any of the other prereq fields. Earlier today I mana
What's the current state of config(ure)_requires in M::I and CPAN(PLUS)?
Do we need the full "configure_requires" or will "config_requires" do
it?
Looks like we might need to use "configure_requires", since M::I may
already be bundled in a few distros by now.
http://search.cpan.org/src/ADAMK
# from Andreas J. Koenig
# on Tuesday 12 June 2007 09:51 pm:
>The example code in the META-spec.pod erroneously says
>build_requires
fixed in r9645
> > I haven't figured out the right thing to do vis-a-vis
> automatically > adding M::B to config_requires.
>
>My current thinking about is that i
> On Tue, 12 Jun 2007 23:00:08 -0500, Ken Williams <[EMAIL PROTECTED]> said:
> All,
> I committed a preliminary patch for config_requires support.
Thanks! The example code in the META-spec.pod erroneously says
build_requires still. Instead of "These dependencies are not required
after the
All,
I committed a preliminary patch for config_requires support. It's
revision 9644 in the repo. It's currently exactly analogous to the
other prereq types, except that during the "dist" action we'll warn
the author if there's an item in config_requires that isn't present
in any of the
# from Adam Kennedy
# on Tuesday 17 April 2007 11:14 pm:
>Eric Wilhelm wrote:
>> Module::Build version y.yy required--this is only version x.xx
>>
>> even call-center-grade troubleshooting guides instruct the user to
>> install version y.yy. Maybe it's not always that easy?
>Here is my standar
# from Adam Kennedy
# on Sunday 18 March 2007 04:28 am:
>> Also - what happens if a user has an old CPAN, an old M::B, and
>> downloads a META.yml containing a configure_requires entry?
>> Presumably that entry would be ignored and the user would miss the
>> dependency altogether.
>There is no g
This META.yml key, if it exists in a distribution, would inform the
CPAN client that it has dependencies that MUST be installed prior to
the configure script being run at all.
These dependencies would always be static, and could never be changed.
Platform related dependency variability in THES
Hi Adam,
On Mar 8, 2007, at 7:36 AM, Adam Kennedy wrote:
I've been having some exploratory discussions with a couple of
people on the idea of creating some sort of RDF grammar to provide
a generic metadata publishing mechanism for source repositories of
any language.
Good.
The idea is
On Mar 8, 2007, at 9:36 PM, Adam Kennedy wrote:
Chris Dolan wrote:
Just a reminder that there already is an XML/RDF format for
project metadata: DOAP (http://usefulinc.com/doap/) It has the
significant advantage that it already exists. :-) Seriously,
some services are already consuming
# from Chris Dolan
# on Thursday 08 March 2007 07:06 pm:
>Just a reminder that there already is an XML/RDF format for project
>metadata: DOAP (http://usefulinc.com/doap/) It has the significant
>advantage that it already exists. :-) Seriously, some services are
>already consuming DOAP so
On Mar 8, 2007, at 7:36 AM, Adam Kennedy wrote:
I've been having some exploratory discussions with a couple of
people on the idea of creating some sort of RDF grammar to provide
a generic metadata publishing mechanism for source repositories of
any language.
The idea is to provide ways of
I know I've been fairly down on Module::Build in the past for not
bootstrapping properly within CPAN dependency traversal.
I've been having some exploratory discussions with a couple of people on
the idea of creating some sort of RDF grammar to provide a generic
metadata publishing mechanism f
19 matches
Mail list logo
