On Tue, 11 Sep 2001, Stas Bekman wrote:
> Yup, I was thinking about that, but figured it'd be more expensive. I know
> we don't care much about speed in tests :) so can() should be fine.
yeah, the difference in speed here isn't worth it for tests.
> > yeah, the common ones normally compiled in modperl_startup.pl
>
> But at this point modperl_extra.pl (where it actually happens) is not
> loaded yet :)
i realize that.
> What do you think is the right position for writing tests? Should these be
> standalone or rely on the fact that somebody else maybe has compiled
> constants for them. I'm fine with adding these compile calls as I find
> problems, so if it makes tests cleaner I'm willing to clean up.
i'm fine with assuming they've been compiled. in fact, that itself is a
test, constants compiled in one file should be able to be seen in another.
> doh! I didn't expect code in .h :) sure should have checked that. thanks!
most of the xs/ *.h files have code in them. they are .h because they are
always #include-d, never compiled into their own object file. and only
the file that #include-s a .h file from xs/ should be able to see what's
in there. anything else belongs in a src/modules/perl/foo.c public api.
> But this can be a problem. Since the file will be in %INC already, it'll
> keep on using bogus *Apache::LOG_MARK . Unless you actually suggest to
> implement it in what you've placed as a comment.
it's not a problem in this case, since Apache::LOG_MARK will never be
called outside of httpd. it just needs to be defined. so you could
actually just do this:
unless (defined &Apache::LOG_MARK) {
*Apache::LOG_MARK = sub {};
}
> Ditto, the test may not work later, unless we delete $INC{...}
i don't understand the %INC problem you're talking about. %INC has
nothing to do with a subroutine being defined or not.
> But can you please explain why require() doesn't work here? Is it because
> something else happens behind the walls when the server is up?
both are subroutines defined in the .xs which are not bootstrapped outside
of httpd.
> So should I just give up the idea of APACHE_TEST_CONFIGURE and move on
> with Apache::TestUtil like vhost_alias does?
i think so.
> Let's just think for a sec, whether we may have some other reason for
> having something like APACHE_TEST_CONFIGURE? Was the creation of the files
> on the fly the only reason for wanting this?
we can always revisit later if needed.
would be nice if the .t files do something like this in any case to make
things clear:
configure();
sub configure {
t_mkdir ...;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
