Hi Thanks for all the replies and various solutions proposed to my question. A brief roundup, for the benefit of anyone who passes this way in future:
1. Re the 'use lib' stuff, the 'FindBin::Real' does indeed look like it would get around the problem of the ambiguous 'use lib '../..' thing. (According to the docs, straight FindBin should NOT be used, as you will get the path for the first call made to a given process, and that will be used for all subsequent calls - not what's wanted). I tried it and it looked good, the trouble was ... it breaks ths use of the T switch as the INC is now considered insecure. I started playing around with trying to untaint that, but there comes a point when the whole thing gets to be too much trouble and you start looking for a simpler way. 2. The VINC module looks good too. Trouble with that is, your modules get reloaded every call, which knocks out some of the benefit of mod_perl. Not that it really matters on my dev/test setup, but I want to also be able to do testing/debugging on the prod server, so it seemed worth continuing the hunt. In the end the simple solution seems to be "run 2 apache-perl instances". This means sorting out httpd.conf (a job that was long overdue) and running dev and test services on different ports, but it wasn't too bad, and seems to work well (touch wood). Once we have 2 versions of the conf file, it's just a questin of starting/stopping the dev version (which runs on 8080) with kill -HUP `cat /var/run/dev-apache-perl.pid` instead of the usual /etc/init.d/apache-perl stuff (I left the startup scripts alone). It seems OK. It also allows me to use a different startup.pl for each setup, which is handy (for doing things like having 'fatals to browser' controlled individually. Also I'm kind of happy if there is a bit more isolation between the screwups I might make doing dev work, and the server that others can be working on. Thanks again for the help. Load of work to get this stuff working right, but it's nice to get a good fix. Daniel -- Daniel McBrearty danielmcbrearty at gmail.com
