2
1
mirror of https://github.com/qpdf/qpdf.git synced 2024-12-22 19:08:59 +00:00
qpdf/README-maintainer

386 lines
13 KiB
Plaintext
Raw Normal View History

ROUTINE DEVELOPMENT
2019-02-02 14:00:50 +00:00
**Remember to check pull requests as well as issues in github.**
Default:
2021-02-10 19:26:54 +00:00
./configure CXX="g++ --std=c++14" --enable-werror
Debugging:
2021-02-10 19:26:54 +00:00
./configure CXX="g++ --std=c++14" CFLAGS="-g" CXXFLAGS="-g" \
--enable-werror --disable-shared
2019-07-13 14:38:27 +00:00
Profiling:
2021-02-10 19:26:54 +00:00
./configure CXX="g++ --std=c++14" CFLAGS="-g -pg" CXXFLAGS="-g -pg" \
LDFLAGS="-pg" --enable-werror --disable-shared
2019-07-13 14:38:27 +00:00
Then run `gprof gmon.out`. Note that gmon.out is not cumulative.
Memory checks:
./configure CFLAGS="-fsanitize=address -fsanitize=undefined -g" \
CXXFLAGS="-fsanitize=address -fsanitize=undefined -g" \
LDFLAGS="-fsanitize=address -fsanitize=undefined" \
2021-02-10 19:26:54 +00:00
CC=clang CXX="clang++ --std=c++14" \
--enable-werror --disable-shared
2019-11-17 03:29:00 +00:00
2019-06-13 13:28:38 +00:00
GOOGLE OSS-FUZZ
2019-08-29 01:47:03 +00:00
* See ../misc/fuzz (not in repo) for unfixed, downloaded fuzz test cases
2019-06-14 16:34:23 +00:00
* qpdf project: https://github.com/google/oss-fuzz/tree/master/projects/qpdf
2020-10-22 09:11:36 +00:00
* Adding new test cases: download the file from oss-fuzz and drop it
in fuzz/qpdf_extra/issue-number.fuzz. If not ready to include, it
can be stored anywhere, and the absolute path can be passed to the
reproduction code as described below.
2019-06-13 13:28:38 +00:00
* To test locally, see https://github.com/google/oss-fuzz/tree/master/docs/,
2019-06-14 16:34:23 +00:00
especially new_project_guide.md. Summary:
2019-06-13 13:28:38 +00:00
2019-06-14 16:34:23 +00:00
Clone the oss-fuzz project. From the root directory of the repository:
2019-06-13 13:28:38 +00:00
Add `-e GITHUB_FORK=fork -e GITHUB_BRANCH=branch` to build_fuzzers
2019-06-14 16:34:23 +00:00
from a qpdf fork/branch rather than qpdf/master.
2020-10-22 09:11:36 +00:00
python3 infra/helper.py build_image --pull qpdf
python3 infra/helper.py build_fuzzers [ --sanitizer memory|undefined|address ] qpdf
python3 infra/helper.py check_build qpdf
python3 infra/helper.py build_fuzzers --sanitizer coverage qpdf
python3 infra/helper.py coverage qpdf
2019-08-29 01:47:03 +00:00
To reproduce a test case, build with the correct sanitizer, then run
2020-10-22 09:11:36 +00:00
python3 infra/helper.py reproduce qpdf <specific-fuzzer> testcase
2019-08-29 01:47:03 +00:00
where fuzzer is the fuzzer used in the crash.
2019-06-14 16:34:23 +00:00
The fuzzer is in build/out/qpdf. It can be run with a directory as
an argument to run against files in a directory. You can use
qpdf_fuzzer -merge=1 cur new >& /dev/null&
to add any files from new into cur if they increase coverage. You
need to do this with the coverage build (the one with
--sanitizer coverage)
* General documentation: http://libfuzzer.info
* Build status: https://oss-fuzz-build-logs.storage.googleapis.com/index.html
* Project status: https://oss-fuzz.com/ (private -- log in with Google account)
* Latest corpus:
gs://qpdf-backup.clusterfuzz-external.appspot.com/corpus/libFuzzer/qpdf_fuzzer/latest.zip
2019-11-17 03:29:00 +00:00
CODING RULES
* Avoid atoi. Use QUtil::string_to_int instead. It does
overflow/underflow checking.
* Remember to avoid using `operator[]` with `std::string` or
`std::vector`. Instead, use `at()`. See README-hardening.md for
details.
2019-06-22 01:36:34 +00:00
* Use QIntC for type conversions -- see casting policy in docs.
* Remember to imbue ostringstreams with std::locale::classic() before
outputting numbers. This protects against the user's global locale
altering otherwise deterministic values. (See github issue #459.)
One could argue that error messages containing numbers should
respect the user's locale, but I think it's more important for
output to be consistent, since the messages in question are not
2020-10-26 23:42:23 +00:00
really targeted at the end user.
* Use QPDF_DLL on all methods that are to be exported in the shared
library/DLL. Use QPDF_DLL_CLASS for all classes whose type
information is needed. This is important for exception classes and
it seems also for classes that are intended to be subclassed across
the shared library boundary.
* Put private member variables in PointerHolder<Members> for all
public classes. Remember to use QPDF_DLL on ~Members().
2019-11-17 03:29:00 +00:00
RELEASE PREPARATION
2021-01-04 21:01:09 +00:00
* Each year, update copyright notices. This will find all relevant
places (assuming current copyright is from last year) except the
manual:
git --no-pager grep -i -n -P "copyright.*$(expr $(date +%Y) - 1).*berkenbilt"
Also update the copyright in these places:
* manual
* debian package -- search for copyright.*berkenbilt in debian/copyright
* qtest-driver, TestDriver.pm in qtest source
Copyright last updated: 2021.
2020-10-25 21:59:34 +00:00
* Take a look at "External Libraries" in TODO to see if we need to
make any changes. There is still some automation work left to do, so
handling external-libs releases is still manual. See also
README-maintainer in external-libs.
2019-06-22 14:37:03 +00:00
* Check for open fuzz crashes at https://oss-fuzz.com
* Check lgtm: https://lgtm.com/projects/g/qpdf/qpdf/?mode=list
2019-02-02 14:00:50 +00:00
* Check all open issues and pull requests in github and the
2020-04-06 15:26:47 +00:00
sourceforge trackers. See ~/scripts/github-issues. Don't forget pull
requests.
* Check `TODO` file to make sure all planned items for the release are
done or retargeted.
* Check work `qpdf` project for private issues
* Run a spelling checker over the source code to catch errors in
variable names, strings, and comments.
2019-02-01 02:40:06 +00:00
ispell -p ispell-words **/*.hh **/*.cc manual/* ChangeLog README* TODO
* If needed, run large file and image comparison tests. Configure
options:
--enable-test-compare-images --with-large-file-test-path=/path
For Windows, use a Windows style path, not an MSYS path for large files.
2020-10-27 15:50:02 +00:00
* Test with clang. Pass `CC=clang CXX=clang++` to `./configure`. (Done
in CI).
* Test with newer version of gcc if available.
* Test 32-bit. Pass `CC=i686-linux-gnu-gcc CXX=i686-linux-gnu-g++` to
`./configure`. (Done in CI.)
* Test build on a mac. (Done in CI.)
2020-10-27 15:50:02 +00:00
* Test with address sanitizer as described above. (Done in CI.)
* A small handful of additional files have been taken from autotools
programs. These should probably be updated from time to time.
* `config.guess`, `config.sub`, `ltmain.sh`, and the `m4` directory:
these were created by running `libtoolize -c`. To update, run
2020-01-25 03:34:12 +00:00
`libtoolize -f -c` or remove the files and rerun `libtoolize`. For
`config.guess` and `config.sub`, search for "latest" in the files,
and follow directions for updating them.
* Other files copied as indicated:
```
2021-01-04 21:22:18 +00:00
cp /usr/share/automake-1.16/install-sh .
cp /usr/share/automake-1.16/mkinstalldirs .
cp /usr/share/aclocal/pkg.m4 m4
```
The entire contents of the `m4` directory came from `libtool.m4`. If
we had some additional local parts, we could also add those to the
`m4` directory. In order for this to work, it is necessary to run
`aclocal -I m4` before running `autoheader` and `autoconf`. The
`autogen.sh` script handles this.
* If any interfaces were added or changed, check C API to see whether
changes are appropriate there as well. If necessary, review the
casting policy in the manual, and ensure that integer types are
properly handled with QIntC or the appropriate cast.
2021-02-23 14:50:23 +00:00
* Update versions and shared library details
* Increment shared library version information as needed
(`LT_CURRENT` in `configure.ac`)
* Make sure version numbers are consistent in the following locations:
* configure.ac
* libqpdf/QPDF.cc
* manual/qpdf-manual.xml
* qpdf/qpdf.cc
`make_dist` verifies this consistency.
* Run ./autogen.sh
2021-01-04 21:26:49 +00:00
2020-04-06 15:26:47 +00:00
* Performance test is included with binary compatibility steps. Even
if releasing a new major release and not doing binary compatibility
testing, do performance testing.
* Test for performance and binary compatibility:
* Check out the last release
* ./configure --enable-werror && make -j$(nproc)
* Check out the current version
2020-04-04 14:37:29 +00:00
* ./performance_check | tee -a /tmp/perf
* ./configure --enable-werror && make -j$(nproc) build_libqpdf
* Checkout the last release
2020-11-21 18:06:26 +00:00
* make -k check NO_REBUILD=1 (some failures are normal -- looking
for binary compatibility)
* Check out the current version
2020-04-04 14:37:29 +00:00
* make -j$(nproc)
* ./performance_check | tee -a /tmp/perf
2018-06-23 01:12:26 +00:00
* Run pikepdf's test suite. Do this in a separate shell.
cd ...qpdf-source-tree...
export QPDF_SOURCE_TREE=$PWD
export LD_LIBRARY_PATH=$QPDF_SOURCE_TREE/libqpdf/build/.libs
cd /tmp/z
git clone git@github.com:pikepdf/pikepdf
virtualenv v
source v/bin/activate
cd pikepdf
pip3 install -r requirements/test.txt
rehash
pip3 install .
pytest -n auto
2018-06-23 01:12:26 +00:00
* Update release notes in manual. Look at diffs and ChangeLog. Update
release date in `manual/qpdf-manual.xml`. Remember to ensure that
the entities at the top of the document are consistent with the
release notes for both version and release date.
* Add a release entry to ChangeLog.
CREATING A RELEASE
* Push to master. This will create an artifact called distribution
which will contain all the distribution files. Download these,
verify the checksums from the job output, rename to remove -ci from
the names, and copy to the release archive area.
2018-02-25 14:27:14 +00:00
* Sign the source distribution:
version=x.y.z
gpg --detach-sign --armor qpdf-$version.tar.gz
* Build and test the debian package
* Add a calendar reminder to check the status of the debian package to
make sure it is transitioning properly and to resolve any issues.
* Sign the releases. The release archive area should contain the
Windows binaries, the AppImage, the source tarball, and the source
tarball signature.
2020-10-25 21:59:34 +00:00
\rm -f *.sha256
files=(*)
2020-10-25 21:59:34 +00:00
sha256sum ${files[*]} >| qpdf-$version.sha256
gpg --clearsign --armor qpdf-$version.sha256
mv qpdf-$version.sha256.asc qpdf-$version.sha256
2018-02-25 14:27:14 +00:00
chmod 444 *
chmod 555 *.AppImage
* When creating releases on github and sourceforge, remember to copy
`README-what-to-download.md` separately onto the download area if
needed.
* Ensure that the master branch has been pushed to github. The
rev-parse command below should show the same commit hash for all its
2019-01-07 14:08:41 +00:00
arguments. Create and push a signed tag. This should be run with
HEAD pointing to the tip of master.
2018-02-25 14:27:14 +00:00
2020-10-27 22:06:13 +00:00
git rev-parse upstream/master @
2019-01-07 14:08:41 +00:00
git tag -s release-qpdf-$version @ -m"qpdf $version"
2018-02-25 14:27:14 +00:00
git push upstream release-qpdf-$version
* Create a github release after pushing the tag. `gcurl` is an alias
that includes the auth token.
# Create release
2021-01-05 16:20:45 +00:00
GITHUB_TOKEN=$(qdata-show cred github-token)
function gcurl() { curl -H "Authorization: token $GITHUB_TOKEN" ${1+"$@"}; }
url=$(gcurl -s -XPOST https://api.github.com/repos/qpdf/qpdf/releases -d'{"tag_name": "release-qpdf-'$version'", "name": "qpdf '$version'", "draft": true}' | jq -r '.url')
# Get upload url
upload_url=$(gcurl -s $url | jq -r '.upload_url' | sed -E -e 's/\{.*\}//')
echo $upload_url
# Upload all the files. You can add a label attribute too, which
# overrides the name.
for i in *; do
mime=$(file -b --mime-type $i)
gcurl -H "Content-Type: $mime" --data-binary @$i "$upload_url?name=$i"
done
If needed, go onto github and make any manual updates such as
indicating a pre-release, adding release notes, etc.
# Publish release
gcurl -XPOST $url -d'{"draft": false}'
2019-11-17 03:29:00 +00:00
* Upload files to sourceforge.
rsync -vrlcO ./ jay_berkenbilt,qpdf@frs.sourceforge.net:/home/frs/project/q/qp/qpdf/qpdf/$version/
* On sourceforge, make the source package the default for all but
Windows, and make the 32-bit mingw build the default for Windows.
* Publish a news item manually on sourceforge.
* Update the web page to indicate the new version and to put the new
documentation in the `files` subdirectory of the website on
sourceforge.net.
2019-11-17 03:29:00 +00:00
(cd /tmp; mkdir -p z; cd z; \
tar xf ~/Q/storage/releases/qpdf/qpdf/$version/qpdf-$version.tar.gz qpdf-$version/doc; \
scp -p qpdf-$version/doc/qpdf-* jay_berkenbilt,qpdf@frs.sourceforge.net:htdocs/files/)
2020-04-08 01:36:48 +00:00
* Upload the debian package and Ubuntu ppa backports.
* Email the qpdf-announce list.
OTHER NOTES
To construct a source distribution from a pristine checkout,
`make_dist` does the following:
./configure --enable-doc-maintenance --enable-werror
make build_manual
make distclean
For local iteration on the AppImage generation, it works to just
./build-scripts/build-appimage and get the resulting AppImage from
the distribution directory. You can also pass -e SKIP_TESTS=1
build-appimage, which passes it along to to docker, to skip the test
suite, which useful for rapid iteration.
2019-11-17 03:29:00 +00:00
GENERAL BUILD STUFF
QPDF uses autoconf and libtool but does not use automake. The only
files distributed with the qpdf source distribution that are not
controlled are `configure`, `libqpdf/qpdf/qpdf-config.h.in`,
`aclocal.m4`, and some documentation. See above for the steps required
to prepare a source distribution.
If building or editing documentation, configure with
`--enable-doc-maintenance`. This will ensure that all tools or files
required to validate and build documentation are available.
If you want to run `make maintainer-clean` or `make distclean` and you
haven't run `./configure`, you can pass `CLEAN=1` to make on the
command line to prevent it from complaining about configure not having
been run.
If you want to run checks without rerunning the build, pass
`NO_REBUILD=1` to make. This can be useful for special testing
scenarios such as validation of memory fixes or binary compatibility.
LOCAL WINDOWS TESTING PROCEDURE
2015-05-24 20:46:36 +00:00
This is what I do for routine testing on Windows.
From Windows, git clone from my Linux clone, and unzip
`external-libs`.
2015-05-24 20:46:36 +00:00
Look at `make_windows_releases`. Set up path the same way and run
whichever `./config-*` is appropriate for whichever compiler I need to
test with. Start one of the Visual Studio native compiler shells, and
from there, run one of the msys shells. The Visual Studio step is not
necessary if just building with mingw.