> Finally, I just did a quick search online and discovered that beginning with
> OSX 10.2 (we are now in version 10.3) /usr/local/bin is "no longer part of
> the default environment variables".

	Is it explained anywhere why such a decision was made?  (In case
it is claimed that it's for "security" reasons, I'd actually expect more
trouble than safety).

> ps, since I mentioned it, can I impose on you to suggest any UNIX resources
> that deal with installing software on multiple machines across a network?

	Sorry I'm not a sysadmin used to install things on many machines
at once.  However, as you will have to log as root on each of them, I'm not
sure it's actually useful to have a script trying to automate this.
	I suppose what is done usually (in the context of a network made of
similar machines) is to have a fileserver that owns all the softwares in a
single location, for instance in the /usr/local directory.  Then this
directory is shared over network via e.g. NFS mounts; i.e. each client
machine mounts the /usr/local directory of the fileserver.  To avoid
slowing down the network, the filesever should be a machine which has
good hardware ressources, which is not likely to be your case.

	Therefore, you may have the only possibility to install POV-Ray
on each machine seperatly.  If all of your machines are running the same
OS version and are accessible from a single one via e.g. SSH, you don't
have to recompile POV-Ray on each machine.  Instead, you can compile and
install it once, then replicate this install on the other machines.

	For instance:

1) compile and install POV-Ray on one machine under the /usr/local
directory you've just created.
2) since /usr/local does contain nothing but POV-Ray files, pack this
directory in a (compressed) tar file called install.tar.gz :

cd /
tar cvf install.tar /usr/local
gzip --best install.tar   (which gives install.tar.gz)

3) copy and unpack this archive on all the other machines

scp install.tar.gz root@the_other_machine:/
ssh -l root the_other_machine
cd /
tar xvzf install.tar.gz

4) adapt the PATH where necessary.

	Note that you may find this procedure actually more time-consuming
than just running configure and compiling the program on each machine (which
of course can be done in parallel, so the compilation time doesn't scale as
the number of machines).

	Again, I don't know whether things can be done in a more automatic
manner, so these are just my not-so-efficient suggestions.

	- NC

Post a reply to this message

Nicolas, thank you very much for your advice and for being so generous with
your time.  Your suggestions have helped a lot.  I was not aware that one
could compress the binaries and just copy them from machine to machine.  I
am still studying your example and it will take me a little time to try
your suggestions since I don't have access to my lab at the moment.  Still,
in the meantime I did try out remotely logging in as root using "ssh
root@<other machine IP>.  so, if I can log onto each machine then I should
be able to change the PATH variables and then move and uncompress the tar
files.  I suppose that in theory I could write a script to do this
automatically but by the time I get that working I could have probably just
gone from machine to machine with a CD of the tar files.  Anyway, I will
write back when I try this out. Thanks again, Chris

Post a reply to this message

Paul Bourke <pdb### [at] swineduau> wrote:
> There has been some discussion here about PovRay 3.6.1
> compiling under Mac OS-X. I can confirm that it does
> compile "out-of-the-box", I just did it as a test. So,
> if it doesn't for you then I imagine you don't have the
> full developer tools installed. If anyone does does want
> the command line version for Mac OS-X then let me know
> and I'll make a binary available.
> --
> Paul Bourke
> pdb_NOSPAMswin.edu.au

Hey Paul--if you read this after so long a time--I was able to compile POV
3.6.1 on my iMac Core Duo, although a complete idiot when it comes to UNIX.
But I guess XWindows or whatever isn't in my Developer Tools. So there's no
watching a scene render. But files output beautifully.

And it works, under OX 10.4.4 on a Mactel machine.

I wonder what gcc optimizations might be employed in compiling this thing?

Best regards!

Post a reply to this message