Date: 14 Apr 1997 21:46:01 +0100 From: Paul Richards <paul@originat.demon.co.uk> To: cracauer@wavehh.hanse.de (Martin Cracauer) Subject: Re: Comments on new search page.. Message-ID: <87ragd2v06.fsf@originat.demon.co.uk> Resent-Message-ID: <199704142047.VAA23835@originat.demon.co.uk> In-Reply-To: cracauer@wavehh.hanse.de's message of Mon, 14 Apr 1997 19:57:11 %2B0200 (MET DST) References: <9704141757.AA05465@wavehh.hanse.de>
next in thread | previous in thread | raw e-mail | index | archive | help
cracauer@wavehh.hanse.de (Martin Cracauer) writes:
> A few comments:
>
> 1) We should not copy tools that are in src/ to www/ as well. CVS
> doesn't support a concept like symbolic links, so we can't have both
> without a maintainace nightmare and we can't have just www/ , because
> the normal FreeBSD src/ build should install those tols as before.
Maybe, maybe not.
Not quite a directly related question but are all the mirrors
FreeBSD boxes? I'd guess so but it's not necessarily the case.
> This doesn't mean we should have no programs in www/ at all. Programs
> that are needed by the HTML build process, but that should not be
> parts of a normally installed FreeBSD system goes into www/. Programs
> for all FreeBSD installations go into src/. A third category are
> ports, but I think we can require having the newest version of a port
> installed normally on a WWW mirror (if it build on older releases,
> that is :-)
We should think a bit about this. As far as possible it would be nice
to not have to duplicate source trees but we also need to detach the
www area from dependance on FreeBSD itself because the needs of www
will move much faster than those of FreeBSD. It's essential that we
have Perl5 for instance.
If we're sure of the FreeBSD version that the mirror runs on then,
yes, we can use the system binaries when possible, but in a
heterogenous environment my experiences of doing this are all bad and
it's much better to build the environment of the web product along
with the product.
This imposes constraints on the cgi scripts, not in what they can do
but in how they should be written. As far as possible they should
*not* use system binaries but rely on Perl functionality. It's rare
that you need to use a system binary (in a complex journal delivery
product in work I've not had one single need to use a system binary).
This is true regardless of whether Perl5 is used but I'd hope that
mainly that's what would be used.
> 2) I think your setup require one installation procedure more than
> needed. /product/FreeBSD/build is not needed.
>
> I like my idea of fully relative build more (obviously :-) and to have
> just an install target that puts the WWW things (but not tools to
> build these) where the httpd expects it.
You don't install the tools on the web server. Only what's under
./content/ is installed on the web server. You have to create a build
environment though in order to "build" the content.
I think you may be confused by my use of the word build. In my example
the build area is where the scripts used to build the site are
placed. These are, for example, perl scripts for converting man pages
into html. These never get installed on the web server (the web server
is coceptually a different environment even if it's the same
hardware).
It's akin to the two steps of building the FreeBSD documentation. You
first have to build the tools that are needed to "build" the
documents.
> The only problem I see is with libraries needed by tools. If we have a
> C program that links to a non-standard library, we need to set up an
> additional Makefile target so that it is linked to ../lib/whatever.a
> instead of /usr/lib/whatever.a. Maybe it is acceptable to do this by
> the standard FreeBSD build process as well.
A web site that relies on relative links to make it portable are a
nightmare to maintain. You can't easily restructure the site without a
lot of effort. It's a much better paradigm to build a web site
specifically for a target area and build it absolute. If you need to
install it somewhere else you rebuild it for that target.
> Same applies for perl modules, but those need to be current in the
> base system anyway when CGI scripts are to be supported. I'm not a
> perl expert, can one change the place perl looks for modules in by
> environment variables?
You can manipulate Perl's search path. The common trick is to set up
the path in a BEGIN block
e.g.
BEGIN {
push(@INC, "/www/FreeBSD/content/libs");
}
--
Dr Paul Richards, Originative Solutions Ltd.
Internet: paul@originat.demon.co.uk
Phone: 0370 462071 (UK Mobile)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87ragd2v06.fsf>