On Jun 22, 2004, at 2:44 PM, Stas Bekman wrote:
It may be a fairly complex logic to add, though you could write wrappers that simply push things into @ARGV, emulating the command line.
Though I'd rather have one way to do things. It's already a non-trivial thing with all the multiple options. If we have to explain to the user in trouble with the test suite more than one way to help us show their problems, it makes things even more complex and confusing. So if you can keep t/TEST as it is I think it'll be a good thing. Feel free to convince me otherwise. Admittedly I have never used MB, so I may miss some things.
I'll leave it; I don't have the tuits to change it. I'm just happy to have something that works with Module::Build. My only thought was that t/TEST seemed like a hack to get something Perlish to work in a C<make> environment. And since Module::Build is a Perl environment, that hack is no longer necessary. But I recognize that there has been a lot built up around that hack, so it's much simpler to follow the 80/20 rule and get it done the way it is.
Yes, but it won't work for modules not using MB, so it's better to have something common. We can always change things later if we find it beneficial. Nothing is cast in stone as long as it doesn't add a huge overhead for the user's learning curve.
Somewhere around that code that deals with cmodules:
grep -Ir cmodules Apache-Test/lib/Apache/
Yes, Randy has been pointing it out. But does TestMB need this support in an initial release? Seems like those who depend on the Makefile will keep using TestMM for a while.
I doubt so. Just make it die with the appropriate message, so that if someone needs it they will know that it'll be added in the future.
No, no, it's fine. But don't worry, once the patch is finished I'll go over it to make it consistent with the rest of the code. Most of things are just perfect.
I figured. I like my style, too (mainly just cperl-mode style). ;-)
pretty much the same here, cperl-mode too :)
I meant the fact that '$script.PL' doesn't interpolate $script.
Oh, duh. Fixed.
I guess that part of the code is not really tested :)
I never, *ever,* create my own t/TEST.PL, so no, it isn't.
generate_script does it for you too.
Instead of:
print "Bar tar car\n";
use Apache::TestTrace;
debug "Bar tar car\n";
Now replace debug with whatever level you want this message to be printed at. By default the trace level is 'info', so unless user changes the default, traces:
emerg alert crit error warning notice info
will always log things, whereas debug() won't. So for example in your case you could use the notice() func. Apache::TestTrace really mimicks the LogLevel from Apache.
Are you suggesting that it be used inside Apache::TestMB? There's only one print statement, in generate_script(), and there I followed the approach of Module::Build, even though TestMM used info.
It doesn't matter for now. I was just mentioning a feature that you may find useful.
So, what more do you need before committing this puppy? I'm ready to take advantage of it with my module and upload that module to CPAN! ;-)
It'd be nice to actually try your patch in action with some module that uses MB before committing it. Other than that +1 and thank you, David.
Moreover, I think it's time to give you commit access to A-T if you wish to. Do you have an account at apache.org?
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
