On Mon, 10 Sep 2001, Doug MacEachern wrote:
> On Tue, 11 Sep 2001, Stas Bekman wrote:
> > 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.
ok.
> > 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.
right, I've decided that the files that I require won't be required again.
Of course this is wrong, since they get required again with a new
interpreter when the server is started. Of couse *Apache::LOG_MARK = sub
{}; from above makes sense then. we just need to make require() happy.
> > 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.
that's clear now.
> > 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.
ah, OK, now I recall why did we want to have APACHE_TEST_CONFIGURE at the
test startup time. We want to access the config object. If I use
Apache::TestUtil I have no access for example to all the dirs. So if I
want to write some files which rely on the server layout I need to access
these vars.
May be we should provide a method in Apache::TestUtil that reads the
config vars and makes them available to users of Apache::TestUtil?
> > 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 ...;
> }
sure.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
