 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.07.2021 um 18:53 schrieb jr:
> downloaded the 'povunix' as recommended, was surprised the archive unpacks in
> the cwd rather than in a sub-directory.
If you can help wrangling the `tar` and/or `gzip` command to rectify
that, I'd appreciate it.
We're currently using the following sequence of commands to bundle the
files we want:
tarfile="povunix-v${POV_RAY_FULL_VERSION}.tar"
# Bundle relevant portions of the original source tree, making sure
# to exclude interim products placed there by the prebuild process.
tar -chWf "${tarfile}" \
--anchored \
--exclude="*Makefile.am" \
--exclude="unix/prebuild*" \
--exclude="unix/scripts*" \
--exclude="platform/windows" \
--exclude="vfe/win" \
doc platform source unix vfe \
LICENSE README.md changes.txt revision.txt
# Add everything created by the prebuild process, except for some
# interim products created by the prebuild process.
# (Note that some files may have already been added by the previous
# command, so we're using `-u` instead of `-r` to avoid duplicates.)
tar -uhWf "${tarfile}" \
--anchored \
--exclude="*Makefile.am" \
--exclude="configure.ac" \
--exclude="bootstrap" \
${prebuild_made}
# Compress bundle into proper tarball
gzip "${tarfile}"
where `prebuild_made` is a list of files detected as having been created
by `unix/prebuild.sh`.
> (in which scenario is building from "Source code (tar.gz)" still preferred?)
In the one where you're building for a non-Unix platform but have a ZIP
file format phobia, I guess.
The "Source code (tar.gz)" and "Source code (zip)" assets are added
automatically by GitHub, whether we want it to or not.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymous org> wrote:
> Am 11.07.2021 um 18:53 schrieb jr:
>
> > downloaded the 'povunix' as recommended, was surprised the archive unpacks in
> > the cwd rather than in a sub-directory.
>
> If you can help wrangling the `tar` and/or `gzip` command to rectify
> that, I'd appreciate it.
>
> We're currently using the following sequence of commands to bundle the
> files we want:
>
> tarfile="povunix-v${POV_RAY_FULL_VERSION}.tar"
> # Bundle relevant portions of the original source tree, making sure
> # to exclude interim products placed there by the prebuild process.
> tar -chWf "${tarfile}" \
> --anchored \
> --exclude="*Makefile.am" \
> --exclude="unix/prebuild*" \
> --exclude="unix/scripts*" \
> --exclude="platform/windows" \
> --exclude="vfe/win" \
> doc platform source unix vfe \
> LICENSE README.md changes.txt revision.txt
> # Add everything created by the prebuild process, except for some
> # interim products created by the prebuild process.
> # (Note that some files may have already been added by the previous
> # command, so we're using `-u` instead of `-r` to avoid duplicates.)
> tar -uhWf "${tarfile}" \
> --anchored \
> --exclude="*Makefile.am" \
> --exclude="configure.ac" \
> --exclude="bootstrap" \
> ${prebuild_made}
> # Compress bundle into proper tarball
> gzip "${tarfile}"
>
> where `prebuild_made` is a list of files detected as having been created
> by `unix/prebuild.sh`.
had not known '--anchored', interesting. I guess simplest would be just
repacking, something like (any typos mine):
tarfile="povunix-v${POV_RAY_FULL_VERSION}.tar"
...
# Compress bundle into proper tarball
mkdir v${POV_RAY_FULL_VERSION}
( cd v${POV_RAY_FULL_VERSION} ; tar -xf ../$tarfile )
rm -f $tarfile
tar $tarfile ${POV_RAY_FULL_VERSION} && sync
gzip "${tarfile}"
rm -fr ${POV_RAY_FULL_VERSION}
> > (in which scenario is building from "Source code (tar.gz)" still preferred?)
>
> In the one where you're building for a non-Unix platform but have a ZIP
> file format phobia, I guess.
>
> The "Source code (tar.gz)" and "Source code (zip)" assets are added
> automatically by GitHub, whether we want it to or not.
ah, ok. thanks.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> ... typos ... </sigh> even missed out the cli options, sorry.
mkdir v${POV_RAY_FULL_VERSION}
( cd v${POV_RAY_FULL_VERSION} ; tar -xf ../$tarfile )
rm -f $tarfile
tar -cvf $tarfile v${POV_RAY_FULL_VERSION} && sync
gzip "${tarfile}"
rm -fr v${POV_RAY_FULL_VERSION}
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.07.2021 um 19:58 schrieb jr:
>>> downloaded the 'povunix' as recommended, was surprised the archive unpacks in
>>> the cwd rather than in a sub-directory.
>>
>> If you can help wrangling the `tar` and/or `gzip` command to rectify
>> that, I'd appreciate it.
...
> had not known '--anchored', interesting. I guess simplest would be just
> repacking, something like (any typos mine):
...
I think I've found something: Adding `--transform "s,^,FOO/,"` to the
parameters should do the job (for a suitable definition of `FOO`).
Requires GNU, but we don't need this to work on end-users' machines.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> Am 11.07.2021 um 19:58 schrieb jr:
>
> >>> downloaded the 'povunix' as recommended, was surprised the archive unpacks in
> >>> the cwd rather than in a sub-directory.
> >>
> >> If you can help wrangling the `tar` and/or `gzip` command to rectify
> >> that, I'd appreciate it.
> ...
> > had not known '--anchored', interesting. I guess simplest would be just
> > repacking, something like (any typos mine):
> ...
>
> I think I've found something: Adding `--transform "s,^,FOO/,"` to the
> parameters should do the job (for a suitable definition of `FOO`).
works using 'sed'?! v nice. (will try and remember to explore this when
opportune)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.07.2021 um 00:02 schrieb jr:
>> I think I've found something: Adding `--transform "s,^,FOO/,"` to the
>> parameters should do the job (for a suitable definition of `FOO`).
>
> works using 'sed'?! v nice. (will try and remember to explore this when
> opportune)
Not sure if it uses `sed` under the hood, but the syntax seems to be
`sed`-like, yes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> It's official now:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.1
>
>
> A note to Unix users:
>
> We're now providing Unix-specific source code packages again. We
> recommend that you build from the `povunix-*.tar.gz` tarball, rather
> than the "Source code (tar.gz)" or "Source code (zip)" packages or the
> raw repo contents.
>
>
> A note to Windows XP users:
>
> Let us know if there are still any of you out there. Otherwise we'll
> presume that Vista (and higher) support should be enough for everybody.
>
>
> Happy Testing!
I could install and run the benchmark without any problems on two Linux
machines.
Thank you Clipka.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 12.07.2021 um 00:02 schrieb jr:
>
> >> I think I've found something ...
there was one other (small) thing, forgot to mention. during installation, if
another 3.8 version already exists, the old 'povray.{conf,ini}' files get
renamed to '*.bak' and new files are put in place. this has the disadvantage
that the existing povray no longer works as configured. the usual practice is
to leave existing files alone if found, and create the distributed as
'povray.{conf,ini}.new'; "admin" then integrates manually.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.07.2021 um 11:34 schrieb jr:
> there was one other (small) thing, forgot to mention. during installation, if
> another 3.8 version already exists, the old 'povray.{conf,ini}' files get
> renamed to '*.bak' and new files are put in place. this has the disadvantage
> that the existing povray no longer works as configured. the usual practice is
> to leave existing files alone if found, and create the distributed as
> 'povray.{conf,ini}.new'; "admin" then integrates manually.
Can you please file an issue report on GitHub, to put a propoer pin in this?
I tend to lose track of stuff mentioned only on the newsgroups.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> Am 14.07.2021 um 11:34 schrieb jr:
>
> > there was one other (small) thing, forgot to mention. during installation, if
> > another 3.8 version already exists, the old 'povray.{conf,ini}' files get
> > renamed to '*.bak' and new files are put in place. this has the disadvantage
> > that the existing povray no longer works as configured. the usual practice is
> > to leave existing files alone if found, and create the distributed as
> > 'povray.{conf,ini}.new'; "admin" then integrates manually.
>
> Can you please file an issue report on GitHub, to put a propoer pin in this?
went there, cannot add an "issue" without acquiring an account. sorry.
> I tend to lose track of stuff mentioned only on the newsgroups.
perhaps a "kind soul" with github membership followed this thread and will
create the report.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
