Hello, JH>I've found it possible to dispense with a separate configuration file JH>for almost any application, even those with an RDBMS back-end. Under JH>*nix it's really easy to automate things, under Win32 it's a little more JH>difficult (file permissions are a bastard to manipulate). Perl can JH>analyse its own environment very accurately, and once it has this JH>"awareness" it's really easy to achieve automation.
So you are right about this, but let me add a caveat. Many times you need to cooperate with a third-party package management system. For example, an RPM database, or a stow or encap repository. In the latter case especially the paths that files are referenced at (typically /usr/local) differ from the places they actually live (typically a mounted repository). (I believe the Andrew File System has a similar problem, too.) Stuff using GNU autoconf is pretty easy to work into this by specifying a PREFIX at configure time. As of Perl 5.6.0 the Perl base install system accomodates for this as well, allowing you to specify different stuff to go into @INC versus where "make install" puts the package. Perl modules aren't as nice to fix. They automatically want to go where Perl is installed. If you want to rev packages separately, regular "make install" doesn't do the right thing. One last thing that is hard is where is your DocumentRoot? This is a huge problem for web applications being installable "out of the box." Perl can't necessarily figure that out by itself, either. I guess my point is that installation is hard. Rather than trying to make it work for everybody out of the box, you should make it work for the typical case out of the box, and then provide hooks for installing it in custom places. Humbly, Andrew ---------------------------------------------------------------------- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELL Fax 650-930-9101 ----------------------------------------------------------------------
