Closed mgieseki closed 9 months ago
Would you please consider merging this PR, @kberry? I would like to run tests with dvisvgm
in connection with the current Ghostscript/MuPDF/mutool release. The new PDF interpreter shipping with Ghostscript necessitated considerable changes in dvisvgm
. Thank you in advance.
As shown above "all checks have failed"
i386-linux:
In file included from ../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../EllipticalArc.hpp:23:0,
from ../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../GraphicsPath.hpp:32,
from ../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../Glyph.hpp:24,
from ../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../GFGlyphTracer.hpp:27,
from ../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../FontWriter.hpp:28,
from ../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../SVGTree.hpp:30,
from ../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/SVGOptimizer.cpp:25:
../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../Bezier.hpp:35:26: error: enclosing class of constexpr non-static member function ‘const DPair& QuadBezier::point(int) const’ is not a literal type
constexpr const DPair& point (int i) const {return _points[i];}
^
../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../Bezier.hpp:30:7: note: ‘QuadBezier’ is not literal because:
class QuadBezier {
^
../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../Bezier.hpp:30:7: note: ‘QuadBezier’ is not an aggregate, does not have a trivial default constructor, and has no constexpr constructor that is not a copy or move constructor
../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../Bezier.hpp:60:26: error: enclosing class of constexpr non-static member function ‘const DPair& CubicBezier::point(int) const’ is not a literal type
constexpr const DPair& point (int i) const {return _points[i];}
^
../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../Bezier.hpp:45:7: note: ‘CubicBezier’ is not literal because:
class CubicBezier {
^
../../../../../../texk/dvisvgm/dvisvgm-src/src/optimizer/../Bezier.hpp:45:7: note: ‘CubicBezier’ is not an aggregate, does not have a trivial default constructor, and has no constexpr constructor that is not a copy or move constructor
x86_64-linux:
../../../../../../texk/dvisvgm/dvisvgm-src/src/ttf/TTFWriter.cpp:26:10: fatal error: woff2/encode.h: No such file or directory
26 | #include <woff2/encode.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.
make[7]: *** [Makefile:464: TTFWriter.o] Error 1
Thanks for the hints. I've added two changesets that should fix the build errors.
As shown above "all checks have failed"
i386-linux:
...
x86_64-linux:
...
I was able to successfully compile a forked upstream TeX-Live/texlive-source with @mgieseki 's PR #59 applied, on my up-to-date Gentoo Linux box Linux 6.1.6-gentoo-x86_64
with gcc (Gentoo 11.3.1_p20221209 p3) 11.3.1 20221209
.
The problem you reported must be due to peculiarities of the CI/CD pipelines of the GitHub build system.
I'd be happier updating TL with a release, not a release + patches. But Martin, if you can point at the exact patches to apply (the links in this issue left me unsure), I guess I don't mind in this case. --thanks, karl.
I can gladly create a new point release but would like to eliminate all build issues first because it's much more time-consuming for me to prepare a release. Maybe you could run the previously failed test builds again.
Here's the initial patch to update dvisvgm to version 3.0.1: update-to-dvisvgm-3.0.1.patch.gz
And these are the links of the two patches I applied on top of version 3.0.1 to fix the errors reported above:
Thanks Martin. It seems the first patch was already applied. I applied the other (to Bezier.cpp) and committed the new version to the TL sources (r65593). It will show up here on github within an hour, I believe.
I'll tell tlbuild, and Mojca's automatic build will kick in shortly for a variety of platforms. https://build.contextgarden.net/#/console
Fingers crossed, Karl
@kberry thanks for picking up the patches. Should we activate CI testing for pull requests here? That would give automatic tests and build checks?
forgot to close this pr on the github side. happily all seems fine now with 3.2, here in 2024 :).
I've updated the TL sources of dvisvgm to version 3.0.1. They build successfully on my Linux machines, but it might be a good idea to test the changes on further machines to make sure I didn't miss anything.