> I understood the limitation of the single interpreter, the problem again
> was to append to @INC per VirtualHost.
It's confusing when you say that, since there's only one @INC for
everything. I'm interpreting this as meaning that you have a bunch of
applications with different install directories and you want them all to go
in the global @INC.
> The goal was to be able to checkout the application source from our CVS
> repository, "Include" its "app.httpd.conf" from the main httpd.conf, and
> be ready to go, with the absolute path for each application's lib
> directory appended to @INC for StatINC to work.
How do you avoid hard-coding the paths to app.httpd.conf then? If you're
already hard-coding that path on each server, you should be able to just
make everything else relative to that. Is that what you were trying to do
with your original post? That code would work fine if you change
$PerlRequire to a straight 'require'. They do the same thing.
<Perl>
my $dirroot = $0;
$dirroot = s/\.htaccess$//;
require ($dirroot . 'modperlstartup.pl');
</Perl>
> As I mentioned previously we switched to absolute paths in the
> per-application startup.pl file. Its a pain to maintain a per-server
> times per-application list of lib paths, but that fixes us until I get
> to see what mod_perl 2.0 has in store for me :-)
Well, what Stas was talking about with mod_perl 2 was just having different
Perl interpreters (with different @INCs) per VirtualHost, which actually
doesn't sound like it has much to do with your problem.
I still don't understand what problem you're trying to solve well enough to
give good advice, but configuration management issues are commonly handled
through an installation process that sets local paths. The last time I had
to do that for a mod_perl app, we used Template Toolkit to generate our
httpd.conf and startup.pl with local paths during the install. For simpler
localization, you could just use a couple of substitutions, or you could try
playing with MakeMaker.
- Perrin
