* Define it even though previous experiments have shown it to be
unnecessary since it seems like it may be necessary after all
* Add QPDF_DLL_CLASS to QPDFObjectHelper and QPDFDocumentHelper in
case there's some future unknown reason why someone may want to have
them and/or in case it helps with the weird
QPDFNameTreeObjectHelper problem.
Over time, qpdf's grade has dropped on lgtm, but they are not
transparent about how grades are assigned. Fixing current alerts, in
my opinion, reduces clarity and maintainability of the code in the
name of performance in non-critical sections of code. Some analysis by
m-holger suggests that fixing some of the current alerts actually
degrades performance (slightly) while fixing others results in
insignificant improvements. The quality of qpdf can be measured in
other ways, such as its extensive test suite, documentation, and long
track record of reliably manipulating PDFs with high performance, few
bugs, and few external dependencies. The lgtm rating is a distraction
at best.
I'm not sure why this is needed now and wasn't needed before since the
cmake changes have been in main for a while and there don't appear to
be recent changes to the appimage build tools.
This change adds to lib directory to LD_LIBRARY_PATH so the appimage
tools' ldd check will pass. This is an appropriate change since the
directory that is added will be in the standard load path when
installed.
Files are copied into the build area rather than left in the source
tree, and the test suite looks for them there. Also remove special
case around counting files in the qpdf corpus.
We have been keeping main's version at the last released version, but
starting now, main's version will always be whatever it would be if
a release were cut from the tip of main.
