#4435 mupdf-1.6 (new package)

[Stefan]

This is a new Fink package for mupdf. The package builds fine with -m, as nobody, etc. It was tested on Mac OS 10.9 and 10.10 but I see not reason for it not to work on any other version given the minimal dependencies.

Here is the dpkg -L:

< godel:~ > dpkg -L mupdf
/.
/sw
/sw/bin
/sw/bin/mudraw
/sw/bin/mujstest
/sw/bin/mupdf-x11
/sw/bin/mupdf-x11-curl
/sw/bin/mutool
/sw/include
/sw/include/mupdf
/sw/include/mupdf/cbz.h
/sw/include/mupdf/fitz
/sw/include/mupdf/fitz/annotation.h
/sw/include/mupdf/fitz/bitmap.h
/sw/include/mupdf/fitz/buffer.h
/sw/include/mupdf/fitz/colorspace.h
/sw/include/mupdf/fitz/compressed-buffer.h
/sw/include/mupdf/fitz/context.h
/sw/include/mupdf/fitz/crypt.h
/sw/include/mupdf/fitz/device.h
/sw/include/mupdf/fitz/display-list.h
/sw/include/mupdf/fitz/document.h
/sw/include/mupdf/fitz/filter.h
/sw/include/mupdf/fitz/font.h
/sw/include/mupdf/fitz/function.h
/sw/include/mupdf/fitz/getopt.h
/sw/include/mupdf/fitz/glyph-cache.h
/sw/include/mupdf/fitz/glyph.h
/sw/include/mupdf/fitz/hash.h
/sw/include/mupdf/fitz/image.h
/sw/include/mupdf/fitz/link.h
/sw/include/mupdf/fitz/math.h
/sw/include/mupdf/fitz/meta.h
/sw/include/mupdf/fitz/outline.h
/sw/include/mupdf/fitz/output-pcl.h
/sw/include/mupdf/fitz/output-png.h
/sw/include/mupdf/fitz/output-pnm.h
/sw/include/mupdf/fitz/output-pwg.h
/sw/include/mupdf/fitz/output-svg.h
/sw/include/mupdf/fitz/output-tga.h
/sw/include/mupdf/fitz/output.h
/sw/include/mupdf/fitz/path.h
/sw/include/mupdf/fitz/pixmap.h
/sw/include/mupdf/fitz/shade.h
/sw/include/mupdf/fitz/store.h
/sw/include/mupdf/fitz/stream.h
/sw/include/mupdf/fitz/string.h
/sw/include/mupdf/fitz/structured-text.h
/sw/include/mupdf/fitz/system.h
/sw/include/mupdf/fitz/text.h
/sw/include/mupdf/fitz/transition.h
/sw/include/mupdf/fitz/tree.h
/sw/include/mupdf/fitz/version.h
/sw/include/mupdf/fitz/write-document.h
/sw/include/mupdf/fitz/xml.h
/sw/include/mupdf/fitz.h
/sw/include/mupdf/img.h
/sw/include/mupdf/memento.h
/sw/include/mupdf/pdf
/sw/include/mupdf/pdf/annot.h
/sw/include/mupdf/pdf/appearance.h
/sw/include/mupdf/pdf/cmap.h
/sw/include/mupdf/pdf/crypt.h
/sw/include/mupdf/pdf/document.h
/sw/include/mupdf/pdf/event.h
/sw/include/mupdf/pdf/field.h
/sw/include/mupdf/pdf/font.h
/sw/include/mupdf/pdf/javascript.h
/sw/include/mupdf/pdf/object.h
/sw/include/mupdf/pdf/output-pdf.h
/sw/include/mupdf/pdf/page.h
/sw/include/mupdf/pdf/parse.h
/sw/include/mupdf/pdf/resource.h
/sw/include/mupdf/pdf/widget.h
/sw/include/mupdf/pdf/xref.h
/sw/include/mupdf/pdf-tools.h
/sw/include/mupdf/pdf.h
/sw/include/mupdf/tiff.h
/sw/include/mupdf/xps.h
/sw/lib
/sw/lib/libmupdf.a
/sw/share
/sw/share/doc
/sw/share/doc/mupdf
/sw/share/doc/mupdf/CHANGES
/sw/share/doc/mupdf/CONTRIBUTORS
/sw/share/doc/mupdf/COPYING
/sw/share/doc/mupdf/naming.txt
/sw/share/doc/mupdf/overview.txt
/sw/share/doc/mupdf/progressive.txt
/sw/share/doc/mupdf/README
/sw/share/doc/mupdf/refcount.txt
/sw/share/doc/mupdf/thirdparty.txt
/sw/share/man
/sw/share/man/man1
/sw/share/man/man1/mudraw.1
/sw/share/man/man1/mupdf.1
/sw/share/man/man1/mutool.1
/sw/bin/mupdf

[Hanspeter Niederstrasser]

Built fine on 10.9. Would it make sense to move include and lib/libmupdf.a to a mupdf-dev SplitOff package? They shouldn't be needed at runtime (and in case mupdf ever decides to have a shared library, that will make the packaging easier).

[Hanspeter Niederstrasser]

Also, is it worth pursuing not using any/some/all of the included thirdparty libraries (curl, freetype, jbig, jpeg, zlib)? This will probably bring down the file size of the executables, which currently are 10MB, by dynamically linking to system or Fink provided copies.

[Stefan]

Good point about the splitoff, I have done so (see attached). As for building against the fink libraries, I agree that this is a good idea but I could not convince so far the package to do so. I will try to dig deeper in the coming days but I am not sure how quick will this happen. I was thinking to include this version for now, but I am fine with postponing this until a better package is available -- just let me know what you think on the matter.

[Hanspeter Niederstrasser]

I've checked in this current version since it does what it says it does. I took a quick glance at the build system (it's a bit of a homegrown mess), and here are some notes to apply to future packages (both general improvement and to use system libs):

1. use make build=release XCFLAGS=-MD. The default is to build debug binaries which will be slower and bigger. -MD will generate .d dependency files that can be used with fink-package-precedence to track which external libraries are used when the time comes.
2. To make the build use a system or Fink library, the corresponding directory in thirdparty/FOO just has to be renamed/removed (the Makefile checks for a file inside the lib directory when choosing).
3. system-freetype on OS X is hardcoded to use X11/freetype. It'll have to be taught to use Fink's instead (probably via pkg-config).
4. It needs openjpeg-2, but we only have 1.5. There might be problems with the build if Fink's 1.5 version is present and the build picks up the system-1.5 headers vs its local 2.0 headers. Maybe flag-sort -r -v can help here.

[Stefan]

Thank you for the hints. The strange hand-made build system is what caused a whole lot of problems for me. In addition I already faced the openjpeg-2, at least I could not build against Fink's.

Anyway, I will dig further as soon as I find the time and I will update the package accordingly. Thank you again.