On Sun, 23 Dec 2001, Stas Bekman wrote:
> That means two different ways to add configuration.
yup. because we're doing different things. and for the record: there
are already more than 2 ways to add configuration. tho only one to run
the CONFIGURE routine.
> Why cannot we make the .pm scanne
Doug MacEachern wrote:
> On Fri, 21 Dec 2001, Stas Bekman wrote:
>
>
>>I was thinking some more about this issue and came to a conclusion that
>>there is nothing we should add, since we have already a working solution:
>>
>
> close, but the current .pm scanner a bit too specific to mod_perl in
ter
On Fri, 21 Dec 2001, Stas Bekman wrote:
> I was thinking some more about this issue and came to a conclusion that
> there is nothing we should add, since we have already a working solution:
close, but the current .pm scanner a bit too specific to mod_perl in terms
of location (where the .pm's h
I was thinking that the best solution would be to encode the need for
scanning a certain file in its name. e.g. foo.conf.t or foo.c.t, foo.ct
(like this one the best since it won't appear in the tests stats
output), so you still have one file and no need to open the files at
all. The only cave
On Thu, 13 Dec 2001, Stas Bekman wrote:
> I guess 'restrictive' wasn't the right word. I've a gut feeling that
> test writers will not remember that it must be a first line and there
> will be no warnings that they've done it wrong (e.g. put it as a seconf
> line). Oh well.
i don't think we sh
Stas Bekman wrote:
>
> My last suggestion was to have a single file with test and config
> inside. The problem is scanning many files, which I suggested to solve
> by having a special naming (e.g. .ct instead of .t) to mark certain
> files that they include extra configuration.
I would prefer to
Rodent of Unusual Size wrote:
I don't mind to having to include the stuff that foo.t needs
in foo.conf.in, as long as the two are co-located. The
part to which I object is having the config stuff either
in a separate directory, or having to manually mung an
existing file (e.g., extras.conf.in) for
I don't mind to having to include the stuff that foo.t needs
in foo.conf.in, as long as the two are co-located. The
part to which I object is having the config stuff either
in a separate directory, or having to manually mung an
existing file (e.g., extras.conf.in) for it. I want a
drop-in ability
Doug MacEachern wrote:
On Thu, 13 Dec 2001, Stas Bekman wrote:
agreed, but the other suggestion to check the first line of .t is too
restrictive.
how so? the first line thing is just to say 'scan this file'. if the
magic isn't on the first line, the file isn't scanned.
I guess 'restrictive' wa
On Thu, 13 Dec 2001, Stas Bekman wrote:
> agreed, but the other suggestion to check the first line of .t is too
> restrictive.
how so? the first line thing is just to say 'scan this file'. if the
magic isn't on the first line, the file isn't scanned.
> Also when you want to get to the CONFIG
Doug MacEachern wrote:
On Wed, 12 Dec 2001, Stas Bekman wrote:
another idea would be to have a second file for this purpose. So if you
have foo.t you'd add foo(.t?).conf.in in the same directory with
whatever things you want. This is a snap to add (we already scan t/conf
for .in files now we
On Wed, 12 Dec 2001, Stas Bekman wrote:
> another idea would be to have a second file for this purpose. So if you
> have foo.t you'd add foo(.t?).conf.in in the same directory with
> whatever things you want. This is a snap to add (we already scan t/conf
> for .in files now we can just scan al
Doug MacEachern wrote:
On Mon, 10 Dec 2001, Rodent of Unusual Size wrote:
I have some lines that need to be added to extras.conf, but I'd
prefer to embed them in the .t file rather than editing extras.conf.in.
I want to be able to drop in a .t file without having to modify
any of the existing fram
On Mon, 10 Dec 2001, Rodent of Unusual Size wrote:
> I have some lines that need to be added to extras.conf, but I'd
> prefer to embed them in the .t file rather than editing extras.conf.in.
> I want to be able to drop in a .t file without having to modify
> any of the existing framework to accomm
I have some lines that need to be added to extras.conf, but I'd
prefer to embed them in the .t file rather than editing extras.conf.in.
I want to be able to drop in a .t file without having to modify
any of the existing framework to accommodate it.
Can be done?
--
#kenP-)}
Ken Coar, Sanagend
15 matches
Mail list logo
