--- Begin Message ---
Stas Bekman wrote:
Could you explain how making:
PerlRequire /path/to/startup.pl
makes it harder to keep things in sync? I'm not sure i understand your
example of Windows dll.
It doesn't. I probably didn't explain the thought process clearly. or
maybe the thought process
itself wasn't very clear :-}
As I said, the fact that I have multiple machines with different
architectures forces me to have
differences in the Apache configs. I could just have multiple monolithic
httpd.conf files, but
that's a recipe for making fixes on one machine and forgetting to make
the same changes on
at least one of the others.
So, the requirement is to have host-dependent elements in the config,
while ideally-
1) Making it clear which elements of the config are common between
machines, and
which host-dependent.
2) Coming up with a reasonable compromise between (a) Everything in one
file, which
is hard to scroll-around in, hard to "see the wood for the trees",
and easy to make an
accidendal error in; (b) A rats-nest of mutiple interdependant
files, esp. given the
aparrent sequence-sensitivity of many of the config directives.
I don't have a major problem with putting the Perl config in a
startup.pl script, but that does
introduce it's own level of mixing host-dependant and host-independent
config elements
(or having startup_local.pl and startup_common.pl). I just wanted to
know what my options
were.
As i said to Martin, I could have gone for a pure Perl "executable
config", with all the variable
elements coded in, but that seemed like a fairly big step for someone in
his first week of setting
up Apache. I'm not sure I would expect much help from the alias with a
totally custom-coded
httpd.conf "application" in perl...
What I have at the moment is this arrangement-
httpd.conf
------------------------
early host-dependent "section 1"
< Include httpd_common_s1.conf> < ---------------- Section 1
common config
late host-dependent "section 1"
early host-dependent "section 2"
< Include httpd_common_s2.conf> < ---------------- Section 2
common config
late host-dependent "section 2"
(if/when I need Vhosts I would add
a section 3 as above).
Maybe not the most elegant or extensible solution, but it seems to work.
Add Perl to
the mix, and there are multiple options for structuring this. One
solution would seem to be-
<Perl>
early host-dependent Perl config
</Perl>
<PerlRequire startup.pl > <------------------------ Common
Perl config
<Perl>
late host-dependent Perl config
</Perl>
this is why I asked the question, To know whether my choices were open as to
which config elements went where, or whether <Perl></Perl> sections were
constrained in any way.
There are some interesting tradeoffs here. For example, the docs recommend
<Directory> sections as more robust containers for access control than
<Location>.
However my filesystem layouts obviously differ between Solaris and
Windows, so
if I use <Directory>, it has to go in the host-dependent httpd.conf.
By comparison, assuming I want my devel and production machines to mirror
each other in their "public" face, If I use <Location> for acces
control, the locations
will be the same and I can share these between machines. Not brain
surgery, but
tricky choices when you are starting out.
Regards: Colin
--- End Message ---
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
