building 2.0.0 on OS X

[r-a-v-a-s]

When building from Qt Creator, the App file appears in the repository's bin folder, along with plugins and a plugins folder.

Using macdeploy.sh results in http://pastebin.com/9Y7L2yE3

The resulting .app didn't work because the script isn't copying libQupZilla.2.dylib LIBRARY_NAME="libQupZilla.1.dylib" I think this needs to be updated. https://github.com/QupZilla/qupzilla/blob/master/mac/macdeploy.sh

When I don't use this script and just use macdeployqt it complains about not having libQupZilla.2.dylib in frameworks; so I copy the files shown in the image above into the app's frameworks folder and then it works.

macdeployqt produces a .dmg that is 68mb

hdiutil convert -format UDBZ QupZilla.dmg -o QupZilla_bzip2.dmg produces a .dmg that is 47.9mb

For those wondering why version 1.8.9 was only 26.7 MB: QtWebKit.framework is 30.2 MB QtWebEngineCore.framework is 98.4 MB

The only change I made was in main.pro QMAKE_CXXFLAGS += -O2 http://stackoverflow.com/questions/887509/when-to-use-o2-flag-for-gcc

It's nothing fancy like the 1.8.9 dmg, but if you want to use it let me know.

[nowrep]

Can you please test if it works when you change library version to 2 in macdeploy.sh?

[r-a-v-a-s]

It copies the file to qupzilla/bin/QupZilla.app/Contents/MacOS/libQupZilla.2.dylib and the program will run when double-clicked. However, all the other errors are still present, and no dmg is produced. Personally I would remove dmg creation from the process, because not everyone that wants to build wants to create a dmg.

What are the three other libQupZilla files for?

The plugin files seem to be placed into the .app before running this script.

I'm not sure what these are for:

# fix libQupZilla
install_name_tool -change $LIBRARY_NAME @executable_path/$LIBRARY_NAME QupZilla.app/Contents/MacOS/QupZilla

# fix plugins
for plugin in QupZilla.app/Contents/Resources/plugins/*.dylib
do
 install_name_tool -change $LIBRARY_NAME @executable_path/$LIBRARY_NAME $plugin
done

In short, building from Creator and then just running macdeployqt seems to accomplish everything needed other than moving libQupZilla.2.dylib.

[Martii]

Personally I would remove dmg creation from the process,

I rather like this feature and it would be a shame to see it go away... although would be nice to reduce the file size footprint some more if possible.

Since it's been decades since I've been on a mac I think I have a dmg available for test purposes. I didn't run into your issue @r-a-v-a-s at all... with the current HEAD of 9d8552aa4baea01f091b945d9826319937649bbc + b937359a17bbb5e520bbd7b31841c5dc4f1e0ffc

[r-a-v-a-s]

I rather like this feature and it would be a shame to see it go away...

I just meant the call to create_dmg.sh could be removed. You could call it after macdeploy.sh if you wanted.

Regardless, as I said before:

... building from Creator and then just running macdeployqt seems to accomplish everything needed other than moving libQupZilla.2.dylib.

... meaning I didn't need those scripts. Also worth noting is that macdeployqt has an optional -dmg argument. You will still need to run hdiutil for bzip2 compression, but macdeployqt is designed to take care of most of the work.

I'm not having any problems, so this can be closed whenever the team wants.

[Martii]

@r-a-v-a-s

I do see an issue with AVG using realtime protection and building QupZilla. I have to replace a line and insert this code (tailor retries to suit the need):

# Some macs can be a little slower than others
#   depending on how they are configured
#
retries=4
while [ $retries -gt 0 ]
do
  hdiutil detach /tmp/tmp-qupzilla-release
  rc=$?
  if [[ $rc != 0 ]]; then
    ((retries--))
    echo "Retrying in 15 seconds to detach DMG from write"
    sleep 15
  else
    retries=0
  fi
done

... into ./mac/create_dmg.sh in order to allow AVG to finish so I don't get a ~"Resource temporarily unavailable" when it is detached for the conversion... because the cp command and AVG (or other parallel process) is generating concurrent traffic that is tying up the disk image. This could be in part to this mac having a HDD instead of a SSD... but an issue none-the-less even if run manually. Another alternative is to turn these services off while compiling and the retries code shouldn't be needed.

[Martii]

Just a note here for future searches with building on the Mac remotely:

When using screen sharing from a Mac to another platform, and the detachable monitor is turned off, it will become super slow in every aspect of building. Initially it will be fast then get slower and slower over time. This is due to a feature with some Mac's where the GPU is shut off when no monitor is "attached"... this includes if it's a TV and/or piped through a switching receiver but those are off but still attached.

To resolve this issue in this use case an option is to purchase a Display Emulator Headless Emulator dongle... such as one of these. They come in various configurations including HDMI which is what I needed. It's still a bit slow but it's about 1 million times better than it was.