Am 12.05.2021 um 15:20 schrieb jr:

> no one mentioned using/creating a (shell, etc) script to build yet, I think, so
> that'd be my advice.


Just throwing in a couple of $0.02 here:


We are intentionally NOT delivering a single shell script, because...

(1) This is a Unix version of POV-Ray, not specifically a Linux version.

(2) Although there are some well-established standards on Linux machines 
by now, it is never guaranteed that a particular Linux machine uses, 
say, apt for package management.

(3) What we really want is that magic

     sudo apt-get install povray

as the sole installation instructions for POV-Ray. That command, or 
whatever equivalent may happen to work on your Linux distribution. Or 
whatever equivalent mouse click may make that same magic happen. In 
other words, our hope is that package maintainers for the various Linux 
distributions will (continue to) "adopt" POV-Ray and compile it into 
packages custom-tailored to fit the conventions of those very distributions.


The current steps of installing POV-Ray from the GitHub package has the 
following components, which all have their specific place and reason for 
being separate:


(1) Acquire the POV-Ray source code package.

This differs depending on where you want to get your source code package 
from - you could download it via the GitHub web interface, you could 
pull it in via `git` IF you have it installed but we don't know that, 
you could have downloaded it to a USB stick and be carrying it over to a 
machine on which you have no internet access... the possibilities are 
endless. Also, obviously this can't be part of a simple script, because 
you'll have to download that script first.


(2) `prebuild.sh`

This script converts the platform-agnostic source code distribution 
package - the thing you'd download from GitHub - into a Unix-specific 
source code package, populating the directory tree with additional files 
created on the fly that would be a PITA to maintain manually, or move 
Unix-specific files to places where we normally don't want 
platform-specific clutter - all to placate subsequent build steps, which 
use a (and arguably still THE) standard toolchain well established in 
the Unix world.

This script is kept separate because the intention is to eventually not 
have this run by the end user at all, nor even a package maintainer, but 
rather by ourselves, to create a neat official POV-Ray v3.8 for Unix 
source package once that version is finalized, that we can then put up 
for download anywhere we please.


(3) Install any of the necessary prerequisites for you

There is no way to universally do this step for you. We don't know what 
package managers you have installed. Is it apt? Is it rpm? Maybe even 
opkg? nix? pacman? What is the name of the package? It may be different 
depending on your Linux distro. Heck, we don't even know what shell 
you're using. Is it bash? ksh? some other flavor? Nope. Not going there, 
thank you.


(4) `configure`, `make` (or `make check`) and/or `make install`

This sequence of commands is THE leading de-factor standard in the Unix 
world wherever software is still installed from source code (as opposed 
to via package managers), period.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 12.05.2021 um 15:20 schrieb jr:
>
> > no one mentioned using/creating a (shell, etc) script to build yet, I think, so
> > that'd be my advice.
>
> Just throwing in a couple of $0.02 here:
>
> We are intentionally NOT delivering a single shell script, because...
>
> (1) This is a Unix version of POV-Ray, not specifically a Linux version.
>
> (2) Although there are some well-established standards on Linux machines
> by now, it is never guaranteed that a particular Linux machine uses,
> say, apt for package management.

"...there is really precious little clear, methodical,
detailed information on how to install povray on a linux system, that is right
here on the POV-Ray website".  this comment by BE started off the thread.
you're right, UNIX != Linux, perhaps even more so for Debian derived stuff than
for others.

re providing build script(s) -- makes things repeatable, with little effort.
what's not to like?


> (3) What we really want is that magic
>
>      sudo apt-get install povray
>
> as the sole installation instructions for POV-Ray. That command, or
> whatever equivalent may happen to work on your Linux distribution. Or
> whatever equivalent mouse click may make that same magic happen. In
> other words, our hope is that package maintainers for the various Linux
> distributions will (continue to) "adopt" POV-Ray and compile it into
> packages custom-tailored to fit the conventions of those very distributions.

why would anyone want 'apt' installed, if others package managers work equally
well?  by making the process depend on a specific Linux how would that help?


> The current steps of installing POV-Ray from the GitHub package has the
> following components, which all have their specific place and reason for
> being separate:
>
> (1) Acquire the POV-Ray source code package.
> ...
> (2) `prebuild.sh`
> ...
> (3) Install any of the necessary prerequisites for you
> ...
> (4) `configure`, `make` (or `make check`) and/or `make install`
>
> This sequence of commands is THE leading de-factor standard in the Unix
> world wherever software is still installed from source code (as opposed
> to via package managers), period.

one could argue that (2) and (3) should be reversed.  agree on (4), how does
embedding that sequence (steps 2+4) in a script present "a problem"?


regards, jr.

Post a reply to this message

Am 27.05.2021 um 08:21 schrieb jr:

>> We are intentionally NOT delivering a single shell script, because...
>>
>> (1) This is a Unix version of POV-Ray, not specifically a Linux version.
>>
>> (2) Although there are some well-established standards on Linux machines
>> by now, it is never guaranteed that a particular Linux machine uses,
>> say, apt for package management.
> 
> "...there is really precious little clear, methodical,
> detailed information on how to install povray on a linux system, that is right
> here on the POV-Ray website".  this comment by BE started off the thread.
> you're right, UNIX != Linux, perhaps even more so for Debian derived stuff than
> for others.
> 
> re providing build script(s) -- makes things repeatable, with little effort.
> what's not to like?

See above, particularly (2).

Yes, we could conceivably provide scripts for, say, "a typical desktop 
Debian 10.0 install", "a typical desktop Ubuntu 21.10 install", "a 
typical desktop Fedora 34 install", "a typical desktop FreeBSD 11.2 
install", and so forth.

What we can't provide is a single one-size-fits-all script. It's simply 
not possible.

Even if we'd go for the individual scripts approach, we'd need people to 
maintan them. Each and every one:

- Every time we add a new package dependency (such as about to happen 
with the FreeType library), someone would have to figure out the name of 
that package on each and every distribution we try to support, and 
modify those scripts accordingly. And test them.

- Every time a distribution we try to support releases a new version, 
someone would have to test the existing script on the new distro 
version. And maybe create a new script to adapt to any changes.

- Every time a user reports an issue with any of those scripts, someone 
would have to troubleshoot that script. And once the root cause has been 
solved, every single other script would have to be examined as well, to 
see if they are subject to the same issue.

You see where this is going?


I'm not intending to discorage you. All I'm saying is, this is the sort 
of problems associated with this approach, and this is why "we" (as in, 
the POV-Ray main developers) WILL NOT DO THIS FOR YOU. If you or anyone 
else wants this to happen, it will have to be a community effort. And it 
should be a commitment, not only to create such scripts once, but also 
stick with it and maintain them.


My take is that it is probably far more efficient to let package 
maintainers do the job. People who know the peculiarities of their 
distributions by heart, and who commit to keeping "their" packages 
maintained. People who are also intimately familiar with the 
`configure`/`make` standard process for compiling software from source 
code. We provide them with the information what packages POV-Ray needs 
and what switches its `configure` script accepts, and they figure out 
the exact sequence of commands to produce binaries for a particular 
distribution, ready to be installed by end users at a single click or a 
single command line.

Which again leads us to:

>> (3) What we really want is that magic
>>
>>       sudo apt-get install povray
>>
>> as the sole installation instructions for POV-Ray. That command, or
>> whatever equivalent may happen to work on your Linux distribution. Or
>> whatever equivalent mouse click may make that same magic happen. In
>> other words, our hope is that package maintainers for the various Linux
>> distributions will (continue to) "adopt" POV-Ray and compile it into
>> packages custom-tailored to fit the conventions of those very distributions.
> 
> why would anyone want 'apt' installed, if others package managers work equally
> well?  by making the process depend on a specific Linux how would that help?

As I said, "or whatever equivalent may happen to work on your Linux 
distrubution. Or whatever equivalent mouse click may make that same 
magic happen."

Whatever Linux, FreeBSD or other Unix(oid) distrubution you may be using 
- YOU as the end user WILL be faminilar with YOUR package manager. You 
WILL have an idea how to search for the POV-Ray package for your distro, 
and you WILL know how to install a package once you've identified it.

If that is something you DON'T know, then how can you expect to be able 
to install ANY software on your machine?


>> The current steps of installing POV-Ray from the GitHub package has the
>> following components, which all have their specific place and reason for
>> being separate:
>>
>> (1) Acquire the POV-Ray source code package.
>> ...
>> (2) `prebuild.sh`
>> ...
>> (3) Install any of the necessary prerequisites for you
>> ...
>> (4) `configure`, `make` (or `make check`) and/or `make install`
>>
>> This sequence of commands is THE leading de-factor standard in the Unix
>> world wherever software is still installed from source code (as opposed
>> to via package managers), period.
> 
> one could argue that (2) and (3) should be reversed.  agree on (4), how does
> embedding that sequence (steps 2+4) in a script present "a problem"?

You're right about the ordering of (2) and (3) insofar as (2) requires 
autoconf. As far as I know, that's the only prerequisite required for 
that step though.

As for combining (2) and (4), see far above.

You don't just run `configure` and then `make`.

You pass several parameters to configure, starting with `COMPILED_BY=`. 
Then some people prefer to specify `--prefix=`, while some others don't 
care much about it, and some people need it because they're not 
administrators. Then some people want to first run `make check` to 
verify that compilation went fine, and only run `make install` after 
that has been established, while others prefer to just run `make 
install` straight away. Others may just want to build an experimental 
version without installing it, and therefore refrain from running `make 
install`. Not to mention certain cases for which we know that the usual 
procedure does _not_ work, such as trying to build with Clang 3.4 while 
using standard headers from gcc 4.6, which needs 
`CXXFLAGS=-fno-fast-math` as a parameter to `configure` to work.

Also, some people may want to check for unexpected warnings after each 
of those steps before proceeding to the next.

Yeah, sure, maybe we could create a script that accepts a bunch of 
parameters to pass to `prebuild.sh`, another bunch to pass to 
`configure`, yet another to pass to a first call to `make`, and finally 
another to pass to a second call to `make`. And some parameter to 
control whether you want to pause (with the option to abort) between steps.

Do you think that would make things a jot easier?
I don't.

What I do know is that it would be another assload of work to set up, 
maintain, and curse to hell when things go wrong.

Post a reply to this message

Am 28.05.2021 um 09:46 schrieb clipka:

> You pass several parameters to configure, starting with `COMPILED_BY=`. 
> Then some people prefer to specify `--prefix=`, while some others don't 
> care much about it, and some people need it because they're not 
> administrators. Then some people want to first run `make check` to 
> verify that compilation went fine, and only run `make install` after 
> that has been established, while others prefer to just run `make 
> install` straight away. Others may just want to build an experimental 
> version without installing it, and therefore refrain from running `make 
> install`. Not to mention certain cases for which we know that the usual 
> procedure does _not_ work, such as trying to build with Clang 3.4 while 
> using standard headers from gcc 4.6, which needs 
> `CXXFLAGS=-fno-fast-math` as a parameter to `configure` to work.

... oh, and I forgot: Depending on various circumstances, people will 
want to run either `make install` or `sudo make install`. In the latter 
case, they`ll typically want to run a simple `make` first, if they don't 
run `make check`.

Or, on some odd quirky system, they may not be able to use `sudo`, and 
instead need to start a new shell session with `su`, run `make install` 
in there, and exit it again. In that case, running this as a spearate 
step is, to the best of my knowledge, inevitable. Unless you want to run 
all of the installation steps as superuser, but trust me, you don't want 
to do that. If you were the type of person who would, you'd be logged in 
as root all the time anyway.


If I can come up with all that stuff in just half a morning's worth of 
time, imagine what good old reality would throw at such a script...

Post a reply to this message

hi,

first off, reading yr reply, I realise (and want to note) that we are, in fact,
"in violent agreement" on pretty much all the points.  (so I've taken the
liberty to snip much)


clipka <ano### [at] anonymousorg> wrote:
> Am 27.05.2021 um 08:21 schrieb jr:
>
> >> We are intentionally NOT delivering a single shell script, because...

for all the reasons you gave etc.  the thread however, as I understood it, is
about building up a .. repository of scripts, snippets, related info on "foo"
required, etc.  all, again aiui, to be summarised + published on the wiki,
eventually.  a user-to-user resource.


> ...
> - Every time we add a new package dependency ...
> My take is that it is probably far more efficient to let package
> maintainers do the job. People who know the peculiarities of their
> distributions by heart, and who commit to keeping "their" packages
> maintained.

I have attached the 'ldd' output for POV-Ray 3.7.0.8, as installed on a Debian
system, via 'apt-get'.  I leave it to you to .. rationalise the linking to
'pulseaudio' and other such.  ;-)

Post a reply to this message

Attachments:
Download 'lddpov.txt' (5 KB)

"jr" <cre### [at] gmailcom> wrote:

> > >> We are intentionally NOT delivering a single shell script, because...
>
> for all the reasons you gave etc.  the thread however, as I understood it, is
> about building up a .. repository of scripts, snippets, related info on "foo"
> required, etc.  all, again aiui, to be summarised + published on the wiki,
> eventually.  a user-to-user resource.

Right.
One the one hand is the horror of what clipka describes, but on the other is
what I perceived as a tangible lack of concise organized instructions for doing
a basic install from scratch - right on the POV-Ray website, where someone would
expect it to be.

So, whatever it turns out to be, I think the realistic goal is to outline the
steps required for a successful install, along with some helpful caveats and
commentary about each step if necessary/desireable.

To illustrate this in part, TOK wrote, "And since Ubuntu's repository version
was already installed, I did not want to mess up things by running the sudo make
install command."

And if TOK doesn't want to screw things up, I'm betting a newbie isn't even
going to have the bravery to try.  I often don't know what "standard"
directories things get installed into, and from past threads, even those
locations are debated amongst experienced Unix/Linux users.

jr very kindly led me through a recent install of the povr branch, and somehow a
wrench got thrown into the works that puzzled everyone including WFP.  It got
sorted out - only because these people were "present", online, and asking
questions and running tests of their own in a timely manner.   That's a rare
luxury, and not something that's going to be available to some random person out
there thinking to themselves, "Hey, maybe I'll installl this POV-Ray thing..."
Which is exactly what we want people to do - install povray.

So I think the goal is not to have a bulletproof script, but to address the
problem of having next-to-no instructions on how to compile your own install,
and at least cut down on the number of forum posts required to get that to
happen with a minimum pucker factor.


> I have attached the 'ldd' output for POV-Ray 3.7.0.8, as installed on a Debian
> system, via 'apt-get'.  I leave it to you to .. rationalise the linking to
> 'pulseaudio' and other such.  ;-)

I'm just gonna take a stab at that one and say that maybe there's the error and
render sounds - if those even happen in a linux install...

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> I'm just gonna take a stab at that one and say that maybe there's the error and
> render sounds - if those even happen in a linux install...

damn, too easy..  </grin>  how about:

libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8


regards, jr.

Post a reply to this message

Am 28.05.2021 um 10:04 schrieb jr:

>> - Every time we add a new package dependency ...
>> My take is that it is probably far more efficient to let package
>> maintainers do the job. People who know the peculiarities of their
>> distributions by heart, and who commit to keeping "their" packages
>> maintained.
> 
> I have attached the 'ldd' output for POV-Ray 3.7.0.8, as installed on a Debian
> system, via 'apt-get'.  I leave it to you to .. rationalise the linking to
> 'pulseaudio' and other such.  ;-)

POV-Ray wants SDL for display.

SDL, as the full name "Simple Direct Media Layer" implies, does more 
than just display.

SDL wants stuff, too.

Post a reply to this message

Am 28.05.2021 um 15:57 schrieb clipka:
> Am 28.05.2021 um 10:04 schrieb jr:
> 
>>> - Every time we add a new package dependency ...
>>> My take is that it is probably far more efficient to let package
>>> maintainers do the job. People who know the peculiarities of their
>>> distributions by heart, and who commit to keeping "their" packages
>>> maintained.
>>
>> I have attached the 'ldd' output for POV-Ray 3.7.0.8, as installed on 
>> a Debian

>> linking to

> 
> POV-Ray wants SDL for display.
> 
> SDL, as the full name "Simple Direct Media Layer" implies, does more 
> than just display.
> 
> SDL wants stuff, too.

(If you squint your eyes and look closely, you'll find all of POV-Ray's 
primary dependencies at the top of the list, right up to `libc`. All the 
remaining stuff is pulled in by those primary dependencies, it would seem.)

Post a reply to this message

Am 28.05.2021 um 10:04 schrieb jr:

>>>> We are intentionally NOT delivering a single shell script, because...
> 
> for all the reasons you gave etc.  the thread however, as I understood it, is
> about building up a .. repository of scripts, snippets, related info on "foo"
> required, etc.  all, again aiui, to be summarised + published on the wiki,
> eventually.  a user-to-user resource.

Beware that you're creating documentation for a moving target.

If that repository of knowledge isn't kept up to date, it will become as 
useless as any other location where such information has accumulated 
over the years.


If you really want to improve the installation documentation situation, 
my suggestion would be to help us (*) improve `unix/README.md` (which 
constitutes THE authoritative quick-install instructions for Linux and 
other Unixoids) and `unix/install.txt` (wich currently constitutes THE 
authoritative detailed documentation of the installation process for 
such platforms).

As for the official POV-Ray wiki, I guess it makes sense to document the 
installation process for FINAL versions there. But we currently don't 
have any such for v3.8. Until then, it is far easier to maintain 
up-to-date install instructions for the development versions at exactly 
the same place where those versions themselves are maintained: In the 
source code erepository. In the aforementioned `unix/README.md`, to be 
specific.

In any other places, the proper thing to do would be to just let people 
know that `unix/README.md` exists, and that they should follow the 
instructions there.


(*) Ideally, what you'd do is clone the repository, change the file, 
then create a pull request. Some discussion could (and probably would) 
then ensue in the GitHub "pull requests" section, over concerns we might 
have with the new wording, and you might be expected to make further 
changes, before the pull request would be adopted into the official repo.

A bunch of smaller pull requests addressing individual shortcomings of 
the document would probably be more likely to get adopted quickly than a 
single pull request essentially rewriting the entire file.

Post a reply to this message