|
|
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
|
|