On 7/15/19 6:28 PM, jr wrote:
> hi,
> 
...
> haven't got the actual url to hand, but for stock POV-Ray, I do the following,
> as regular user:
> 
> - make a directory, eg /tmp/P, and cd into it.
> - use 'wget' to retrieve the archive.
> - unpack the archive with 'tar xf filename'.
> - change into the (newly created) povray directory.
> - execute '( cd unix ; ./prebuild.sh)'.  note the parentheses around the
> commands.
> - run './configure', usually first with '--no-create --help' to look see the
> stuff that may need adapting.
> - run 'make'.
> 
> if you capture the whole configuration and compile sequence with something like
> 'typescript(1)', you have a "log" in case of problems.  only actual install
> needs be done with privilege.
> 
>> see:
>> https://github.com/LeForgeron/povray/blob/hgpovray38/unix/install.txt
>> https://github.com/LeForgeron/povray/blob/hgpovray38/unix/README.md
>> https://bitbucket.org/LeForgeron/povray/wiki/Compilation
>>
>> And if there's a way I can start playing with some source code and trying to
>> compile my OWN fork, as a learning experience, then that would be super cool as
>> well.
> 
...
> 
I'm partly back from my break away... Always interesting to see how 
others are working and compiling compared to me. To what jr and Jerome 
have said, I'll somewhat randomly add:

- While /tmp is ramdisk on some systems I don't think this today true 
for Debian based ones like mint - but maybe. You can check with the 'df' 
command which run from an xterm window will spit out a bunch of lines, 
one of which should be something like:

tmpfs            8108248     37556   8070692   1% /tmp

if your /tmp is running on the tmpfs ram disk. If not, it can be changed 
to be so or you can use one of the other ram disk directories which 
typically exist. Look for tmpfs lines in the df output. /run and 
/dev/shm are common user ram disks. I have long used /run/shm/<DirNames> 
on Ubuntu though suppose /run falling out of favor. You should have a 
reasonable amount of ram (min 8GB I'd say) to use ram disk. Use regular 
drives if you know you'll be creating files larger than the free space 
shown by the df command for any tmpfs directory.

- Instead of wget to grab the github zips, I usually just go the to 
github web page for the branch and click the green clone/download button 
which pops up a window with a download zip at the bottom.

- With implementations like the depthmap patch, hgpovray38 or uberpov 
downloading the zip compiling and putting the created 'povray' load 
module somewhere in the executable path with a unique name usually OK 
(uberpov installs apart from povray so make install OK in that case). 
With my other public, routinely re-based to master branches such as:

https://github.com/wfpokorny/povray/tree/update/JG_sdl2

the intent is for users to be set up with git and to be staying current 
with the master development branch. Then, to add any of my published 
features to the current master, you'd do something like the following 
from the master branch in git:

git branch pUltra
git checkout pUltra
git branch --set-upstream-to master pUltra

git pull https://github.com/wfpokorny/povray.git 
feature/newDensityPatternInterpolations

git pull https://github.com/wfpokorny/povray.git update/JG_sdl2

git pull . feature/MyVortex    ;# <-- Your Vortex branch.

...

After which you'd do the normal build sequence. You end up with a 
personal version of POV-Ray with all the additional features you want. 
With my published branches you could download the matching zip and 
compile - but then you'd have only that feature in addition to what's in 
master.

Aside: re-basing branches to master is what I do today and it takes time
on each re-base. My branches not always current with the most recent 
commit. As I write this they are, but - check. The branches I publish 
are today all pull-able / merge-able with master - you can use them all 
at once. Might or might not be true if personal or other's branches are 
pulled too. Modern code control is great, but colliding changes have to 
be sorted out (or avoided) in the end.

- In addition to the packages listed in the <...>/unix/README.md file I 
would also recommend installing sdl2 if you plan to use hgpovray38 or my 
JG_sdl2 patch. I've been running with Jerome's sdl2 update for months 
with good result. If sdl2 not already installed use:

sudo apt-get install libsdl2-dev

Note. Unlike most packages where you don't want to specify the version 
to get the linux package's supported version. It is needed with libsdl2 
due libsdl1.2 being dissimilar to 2.* versions. Install git if you plan 
to roll your own branches or version of POV-Ray.

- Perhaps useful. I use the following (debian) command to check what is 
already installed:

dpkg -l | grep sdl

Which for me shows both libsdl1.2-dev and libsdl2-dev given I run 
versions of POV-Ray using both.

- If you'll be running multiple versions of POV-Ray routinely you might 
find installs to unique directories and the wrapper script approach, 
discussed most recently at: 
https://github.com/POV-Ray/povray/issues/374, useful. The build 
processes are today set up to support only one install of a version at a 
time in a target directory. When you run the configure script you can 
specify an install directory in your local space for each compiled 3.8 
version. Individual wrapper scripts then can run each.

Hope my rambling of some help.

Bill P.

Post a reply to this message