On 06/25/2017 12:31 AM, Cousin Ricky wrote:
> On 2017-06-23 04:17 PM (-4), clipka wrote:
>> **IMPORTANT NOTE:** In contrast to the betas, the Windows version of the
>> release candidate does NOT make any attempt to co-exist with v3.7.0. If
>> you intend to keep v3.7.0 around, make sure to back up the binaries, or
>> install v3.7.1 in a different location.
> I am an active Object Collection contributor, and I test my modules
> across different POV-Ray versions. Some differences between v3.7.0 and
> v3.7.1 are significant enough that I wish to keep v3.7.0 around.
> Regarding the Unix version, I did *not* take your earlier suggestion to
> run the configure script with the --prefix= parameter. (See "Peaceful
> coexistence between 3.7.0 and 3.7.1" in p.t.tutorials.) I understand
> this to mean that my beta installs have already been storing data where
> v3.7.0 looks for them. (I've already noticed the changes in the user
> manual.) Does this mean that the hack I used to keep both versions
> coexisting should continue to work?
I am currently using the following method to maintain multiple versions
of POV-Ray on Ubuntu linux for similar testing and support reasons.
I create a tmpUser directory in my own space. Within this directory I
currently have sub-directories called MyP370, MyP371, MyP372, MyJG,
MyUber and MyPovr. If you were supporting multiple users on your system
or creating installable system-images you might create these directories
In your local git repository(ies) where the branch(es) are available do
the usual builds always specifying a prefix:
git checkout release/v3.7.1
./configure COMPILED_BY="wfp" --prefix=$HOME/tmpUser/MyP371
For each branch you want to maintain change the --prefix argument to
point to the corresponding install space. In my case the branches are
currently "3.7-stable", "release/v3.7.1", "master"(3.7.2) and other
experimental branches including my own "povr" branch for my work version
It's helpful to do a 'make clean' or 'make distclean' after each 'make
install'. With the code refactoring over time the clean and distclean
"targets" have changed due the source code directories getting moved
around and renamed. You can skip the cleanup step but you might find
yourself with, for example, extra "*.o" object files laying around.
Note you'll get extra directories relative to any particular branch in
any case. These extra directories will be empty if you have done the
distclean step while in the branch where they were valid.
With the differing distributions built and installed, I create small
wrapper scripts in my $HOME/bin directory to run each. For example, I
have a p370 bash script which looks like:
------------------ Start -----------------
# Wrapper to run local POV-Ray 3.7.0 stable install
#-- Use install version's povray.ini over, for example,
# $HOME/.povray/3.7/povray.ini which might have been
# customized or be incompatible. If have Library paths
# important and normally in the home directory, will
# need to use -L or add additional Library_Path= in temp .ini file.
echo "" >$HOME/.povray/3.7/povray.ini
# A similar conflict is possible with
# $HOME/.povray/<version>/povray.conf. Use $PATH install only.
echo "" >$HOME/.povray/3.7/povray.conf
#--- Run what the user passes for options.
------------------ End -----------------
Now instead of the usual:
povray +w800 +h600 the.pov
command use instead one of:
p370 +w800 +h600 the.pov
p371 +w800 +h600 the.pov
p372 +w800 +h600 the.pov
pPovr +w800 +h600 the.pov
pJG +w800 +h600 the.pov
pUber +w800 +h600 the.pov
One of the awkward parts today is every "make install"(1) puts its own
versions of povray.ini and povray.conf into the users $HOME in a .povray
sub-directory common for all 3.7 versions. My view is this isn't
something "make install" should be doing - rather povray should on start
look to create these files if need be on a users first invocation.
Further, better to maintain separate versions for 3.7.0 vs 3.7.1 for
example. Anyway, not the way in works today and part of what the
wrapper scripts do is avoid the stuff in $HOME.
The six distributions currently require just under 300MB of disk space.
(1) - uberpov is set up so as to maintain its own .uberpov directory,
but I use the same form of wrapper script as all other versions to keep
Post a reply to this message