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