Verify build works on Mac OS and update installation instructions

[dannyedel]

@wwwdata created the initial Mac OS installation instructions using the macports system. However, in the meantime the brew system emerged.

@wwwdata, please verify that building on current MacOS with the brew system, and - if possible - include this project in their database for easy installation.

btw, I can only assign tickets to myself or nobody. Can you click assign to yourself on this ticket?

[wwwdata]

no, I cannot. But I will check this out this weekend. In brew you can create your own formulas to compile stuff. I will try to create one for dspdfviewer 😄

[dannyedel]

If they have any "generic cmake project" plugin, it should work since the cmake process is 100% standard now (even when compiling on non-debian from non-git). Be sure to add crypto checksums if you use the tar.gz archive : )

If "Compile with standard cmake method" does not work, please file a bug.

[shaaati]

How did the testing turn out for a current OS X?
I tried manual compilation on 10.9, which is the second latest release of OS X, and did not succeed.
A native solution would be great as for now, I have to fiddle with virtual machines for presentation.

[wwwdata]

I have to test again, the last time I tried I could not install qt4 via brew because I am using the beta of 10.10.

[dannyedel]

If Qt4 is the problem, and you're ready for some experiments, I have now added compatibility for Qt5 into the master branch.

Activate via cmake -DUseQtFive=ON /path/to/source at the configure step.

If you're willing to give this a shot I'd appreciate some real-world feedback (but please compile with debug symbols and provide sample-data and backtrace when it crashes : )

[dannyedel]

I have added basic osx building to Travis-CI's integration tests, using their default compiler (clang).
Little compiler differences between clang-linux and clang-osx were present, but they have (hopefully) been dealt with.

@shaaati, please try building the current master branch directly from git, using the same commands I fed travis:

brew install poppler --with-qt4
git clone git://github.com/dannyedel/dspdfviewer
cd dspdfviewer
mkdir build
cd build
cmake -DUseQtFive=OFF ..
make

Since you said you're using 10.9, we might be in luck:

Quote http://docs.travis-ci.com/user/osx-ci-environment/

Travis CI uses OS X 10.9.5.

[wwwdata]

hm, I tested it now and it seems the qt build is still broken because of my el capitain beta ...

==> ./configure -prefix /usr/local/Cellar/qt/4.8.7 -system-zlib -qt-libtiff -qt-libpng -qt-libjpeg -confirm-license -opensource -nomake demos -nomake examples -cocoa -fast -release -platform unsupported/macx-clang-libc++ -no-qt3support -nomake docs -arch x86_64
==> make
2 errors generated.
make[2]: *** [.obj/release-shared/qpaintengine_mac.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [release] Error 2
make: *** [sub-gui-make_default-ordered] Error 2

READ THIS: https://git.io/brew-troubleshooting

These open issues may also help:
Qt 5 Fix for El Capitan https://github.com/Homebrew/homebrew/pull/42452
qt-gstreamer 1.2.0 (new formula) https://github.com/Homebrew/homebrew/pull/40491
qt failed to build on 10.11 https://github.com/Homebrew/homebrew/issues/42370
libdbusmenu-qt fails to build on 10.10.3 https://github.com/Homebrew/homebrew/issues/41273
Warning: You are using OS X 10.11.
We do not provide support for this pre-release version.
You may encounter build failures or other breakage.

I don't have a mac with the previous OS right now. But if travis can use brew maybe it can also be abused with a custom brew recipe 😄

[dannyedel]

@wwwdata it seems this is a known bug in brew, Apple seems to have dropped a function from the Mac OS API, and therefore the compile breaks... see Homebrew/legacy-homebrew#42370.

Homebrew/legacy-homebrew#40585 contains a comment with a possible fix, you might want to try out the patch from this comment:
Homebrew/legacy-homebrew#40585 (comment)

Disclaimer: I have absolutely no idea about Qt's inner workings, and cannot judge if the patch is sane. But hey, we probably already have hundreds of thousands of lines of code on our system that aren't sane...

[dannyedel]

quote @wwwdata

But if travis can use brew maybe it can also be abused with a custom brew recipe

If you hack a formula together blindly in a git repo of yours, I suppose you can add some kind of .travis.yml that basically calls "brew install ./formula.rb", maybe even benefiting from their build matrix feature to try qt4 and qt5 depending on an env variable.

Since brew looks like a source-based distribution to me (with binaries of some popular libs thrown in), you could add the following switches:

• --with-qt4 (This is currently the default)
  • Depend on poppler --with-qt4
  • Pass -DUseQtFive=OFF to cmake. (This is currently the default if no option is specified)
• --with-qt5
  • Depend on poppler --with-qt5
  • Pass -DUseQtFive=ON to cmake
• --git (or similar)
  • Build from current git master branch instead of checking out the current release

Since the v1.13.1 release was never tried on OSX, I doubt it would compile cleanly anyway, so you might want to wait with sending the Formula upstream until v1.14 is there.

[shaaati]

Im sorry that it took me so long to answer.
@dannyedel I compiled the most recent version as you mentioned in your post literally fifteen minutes before I gave a talk with it. The result was stable, but none of the different timers was shown on the notes screen.

I have no idea why my compilation attempt did not work earlier, because I did it exactly as you said before I posted here.

[dannyedel]

@shaaati:

I have no idea why my compilation attempt did not work earlier, because I did it exactly as you said before I posted here.

That was most likely my fault, since I used functions from headers without #includeing them properly. Because both clang and gcc included them by default, I didn't even notice my mistake (not even with warnings cranked up to 11) on my linux box, it was only discovered when I tried to add osx to the build matrix.

I have created a new issue to track the timers not showing on OSX; as soon as I get my hands on a mac I'll try to debug this.

[wwwdata]

Ok I got it working on El Capitain. The only problem now is the test-block of the brew formula. I have to run the program with something. So I just tried dspdfviewer -h to display the help. This is a bad test but it's better than none. And it is the only thing we can do because we have no input output manipulation, this program displays stuff on the users screen.

So the problem is, that dspdfviewer exits with status code 1 after displaying the help, which fails the test.

[dannyedel]

Considering that this page itself says that foo --version or foo --help is a bad test, I'm not sure if doing a proper test is possible easily.

Note that since dspdfviewer is a Qt Gui application, anything it does will require a working GUI subsystem;
it simply is not a command-line tool.
On X11, the QApplication constructor will stop the program if $DISPLAY is not set, that's even before option parsing.

Quoting the Formula Cookbook:

We want tests that don't require any user input and test the basic functionality of the application.

In dspdfviewer's case the "basic functionality" is rendering PDFs full-screen (as in, exclusive use of the screen).
While that would not necessarily require user input (all it wants is keystrokes), it will generate graphical output and assume it's the only user of the graphical output.

If that's not a showstopper, then a halfway-reasonable test would be "start dspdfviewer /path/to/some.pdf, wait a second, send it a couple of keystrokes and check the return code is zero".

Simple cooked-together-in-one-minute-example (Assuming macos has something similar to xdotool, you can probably adapt this):

#!/bin/bash
(
        sleep 1;
        xdotool key Down; sleep 1;
        xdotool key b; sleep 1;
        xdotool key Down; sleep 1;
        xdotool key Up; sleep 1;
        xdotool key q
) & # send keystrokes from subshell
dspdfviewer ~/Downloads/test.pdf
RETCODE=$?
wait # wait for subshell
return $RETCODE

If you're wondering why this specific sequence of keystrokes: It would have detected #65.

So you better use something else, because the chance rest assured I'm testing that sequence before every release myself :) In theory, you can send pseudo-random keystrokes; it should not crash the program. But if you send any of the keystrokes that launch a popup (F1, ?, G for example) be aware that a simple "Q" won't quit the program, so you may need two "Esc" (one for dialog, one for program window)

[wwwdata]

hm, I din't know if these tests can be performed by the homebrew tester. But my current formula looks like this: https://gist.github.com/wwwdata/666d57a9f074ca79f48d

[dannyedel]

One more comment from me:

• If you are reworking the formula anyway, you may want to specify a link to the head revision too, so users willing to test features not-yet-released can easily do so.

[wwwdata]

Yes good idea. In will update my pr this evening.

[wwwdata]

it got merged in homebrew. They suggested that we compile dspdfviewer with qt5 in the future because qt4 support is very bad and will not be there in the future.

[dannyedel]

Nice, thanks 👍

Now all that's left is update the macos install instructions and this issue can be closed.

---

Regarding qt5 support: Please start testing HEAD builds with qt5 under MacOS and report any strange things.

While I still consider the support experimental (mostly because poppler-qt5 does not declare a stable version yet) it should™ work and bug reports are more than welcome.

Once the next stable version is released, I'd recommend leaving the default compile mode at qt4 and activating qt5 only on user request (at least until poppler-qt5 is stable), but in the end you're the MacOS/brew expert so you should decide this.

[dannyedel]

fixed by #83. Thanks!