search

PhilterPaper / Perl-PDF-Builder

Extended version of the popular PDF::API2 Perl-based PDF library for creating, reading, and modifying PDF documents
https://www.catskilltech.com/FreeSW/product/PDF%2DBuilder/title/PDF%3A%3ABuilder/freeSW_full
Other
6 stars 7 forks source link

Correct Windows ghostscript path for gs v9.55.0 #173

Closed carygravel closed 2 years ago

carygravel commented 2 years ago

Ghostscript embeds the version number in the path, which had therefore changed, and it could therefore no longer be found. Obviously, this is really brittle, and there is probably a way of extracting the directory below C:\Program Files\gs\ and adding it to the path automatically.

PhilterPaper commented 2 years ago

So every time GS is updated, test.yml will have to be updated? In return, updating test.yml will mean having to update my local GS copy? Who will this affect -- only people like you and me with a PDF::Builder Git repository?

That's really stupid for GS to hard code the version number into the path -- it forces multiple updates at once. I suppose that a soft link ("junction" in Windows) could allow a versionless path in test.yml, but then a separate operation would still be needed to map the versionless path to the actual versioned path. Or, when GS is installed, the versioned path could be renamed to a versionless path. Any way you cut it, it's still a nuisance. If it's only Git repository owners, it might not be too bad, so long as everyone remembers to do the update. Perhaps test.yml should have a reminder line that if such-and-such can't be found, manually update test.yml with the corrected path version?

PhilterPaper commented 2 years ago

By the way, that path appending doesn't "build up" with a permanent change to any PATH variables, right? I don't want to find that I now have 9.53, 9.54, 9.55,... waxy buildup on my floor in any paths.

carygravel commented 2 years ago

So every time GS is updated, test.yml will have to be updated? In return, updating test.yml will mean having to update my local GS copy? Who will this affect -- only people like you and me with a PDF::Builder Git repository?

No. Only people like you and me who use github workflows. This doesn't affect the way the tests run locally on your machine.

That's really stupid for GS to hard code the version number into the path -- it forces multiple updates at once. I suppose that a soft link ("junction" in Windows) could allow a versionless path in test.yml, but then a separate operation would still be needed to map the versionless path to the actual versioned path. Or, when GS is installed, the versioned path could be renamed to a versionless path. Any way you cut it, it's still a nuisance. If it's only Git repository owners, it might not be too bad, so long as everyone remembers to do the update. Perhaps test.yml should have a reminder line that if such-and-such can't be found, manually update test.yml with the corrected path version?

I don't think the ghostscript project does the windows packaging - I assume that is just chocolate.

In the days when I still used windows, it seemed to be fairly standard to embed the version number in the installation directory - it then enabled multiple parallel versions to be installed/tested.

carygravel commented 2 years ago

By the way, that path appending doesn't "build up" with a permanent change to any PATH variables, right? I don't want to find that I now have 9.53, 9.54, 9.55,... waxy buildup on my floor in any paths.

No. And in any case, these changes are only happening in the Github docker container, which is thrown away as soon as each test is finished.

PhilterPaper commented 2 years ago

I appear to have only gs9.53.3 installed, so t/tiff.t is happy to run (it only checks if at least 9.25.0). Is the TIFF code really dependent on 9.55? Or is this a recent problem where GS names have been changed? What happens when eventually I upgrade to 9.55? Conversely, should test.yml require the latest and greatest GS, or would it be happy with earlier versions?

carygravel commented 2 years ago

I appear to have only gs9.53.3 installed, so t/tiff.t is happy to run (it only checks if at least 9.25.0). Is the TIFF code really dependent on 9.55? Or is this a recent problem where GS names have been changed? What happens when eventually I upgrade to 9.55? Conversely, should test.yml require the latest and greatest GS, or would it be happy with earlier versions?

No. The TIFF code is not dependent on GS at all. The only reason this change was necessary was because in order to run the full set of tests in Windows we need a GS installation. The one that chocolate installs by default changed because they packaged a newer version of GS. The requirements for test.yml haven't changed, but we have to adapt test.yml to deal with what is available.