Re: Mac qwt/qwtpolar build/install suggestions
Tilman Skobowsky <qwt <at> spellowsky.de>
2013-02-06 23:50:58 GMT
> Well a naked patch attached without tags would be better. For loading it
> into a tool like meld or applying it these tags are not helpful.
Do you have a reference on how that should look? And/or which 'svn diff' parameters to use? (I'm not that used
to work with diffs due to the fact that we don't really use "diff" at work...)
>> [ debug_and_release ... ]
> Probably on all platforms beside Windows it is possible to mix release
> and debug libraries. That's why there is a good reason to do it special
> on Windows, but there I don't s a good one for the Mac.
There are good reasons to do this on the Mac in a single build though...
> The default setting on all other systems should be release only. As
> using suffixes for debug libraries ( _debug ) is quite uncommon in UNIX
> environments it is more likely, that Qwt would be built twice and
> installed into different directories.
...but I have to go into some details here (hoping, that I don't tell you a lot of things you already know)
In general, most Mac applications make use of so called frameworks. Frameworks bundle the actual library
with optional header files and an optional debug version of the library, whose name is the same as the
libraries name appended by "_debug". (*blink*) The nice part about the "_debug" version is that you can
optionally use them when debugging the code i.e. with Qt Creator or XCode (the native IDE for Mac OS X). So
when the framework bundle provides a debug version, it will be taken, if not, it will use the non debug
version as fallback automatically (*blink*). Using the debug version allows source code stepping into
the library code with the debugger, which of course is very handy sometimes.
As a matter of fact, the Qt library installer for Mac (up until 4.8.x) installed the Qt Frameworks
containing the release libs. An optional installer adds the debug libraries to the already installed Qt
Second: Mac applications are deployed as application bundle.The bundle is really a folder that is shown as
if it were a single file. More important, the application bundle contains all libraries used by the
application within the bundle. As a result, the application can be installed by simply copying the
application "file" (folder) to any place – without an installer (windows) or the need to first install
other packages (*nix).
Starting at around 4.5 or so, Qt includes a tool called "macdeployqt" that takes the work-in-progress
developement application, collects the referenced libraries / frameworks and puts them all into a
release application bundle (converting absolute references to libs / frameworks to relative
references within the bundle) – which is very, very handy.
Ok, the one drawback of putting all libraries into the application bundle is, that you can't reuse the same
libraries for various applications, so there is a lot of duplication of libraries. On the other hand, this
way you will avoid the DLL-hell known to the Windows world, since you never have the problem of using the
wrong version of a library. And last not least, it is very easy to install software on a Mac.
For some more info on Framworks see around here, if your're really interested in... (or don't bother)
> Please check the modified pro/pri files on your systems. Building
> applications with "CONFIG += qwt" would be very interesting too.
I did check with my project, which uses the above line. BTW: I set QMAKEFEATURES with the following line:
qmake -set QMAKEFEATURES /usr/local/qwt-6.1.0-svn/features
before I was able to use "CONFIG+=qwt" (I just repeat this for people like me: it took me a while to figure this
There is one problem left: The samples are compiled properly, but they can't be run directly because the Qwt
framework is not found by the dynamic library loader (see "man dyld" on a Mac). The reason for this lies in
the fact that in the final executable, the reference to the qwt.framework is relative to some known
locations for frameworks. But since "make install" does not put the qwt.framwork to one of this "well
known" places (like "/Library/Framwork" which is the place, where the official Qt installer places its
frameworks) we are somewhat stuck here.
For now there are two solutions to this problem:
1. You must either set "DYLD_FRAMEWORK_PATH=/usr/local/qwt-6.1.0-svn/lib/"
2. You must create the following symlink:
ln -s /usr/local/qwt-6.1.0-svn/lib/qwt.framework/ /Library/Frameworks/qwt.framework
The first solution works only while you work from command line. There is a way to set this on startup, but
don't bother, take the second solution. The second solution puts the link to the qwt.framework to a "well
known" place where it can be found (by any application and "macdeployqt") which is what I did on my
I do have an idea on how to circumvent this by making the "make install"ed version of qwt.framework use
absolute paths (for the library itself, so the reference in the app using qwt is absolute as well... don't
bother if you don't understand what I'm writing here). But I have to check if "macdeployqt" is still able to
bundle the app correctly...
>> I will also check on building qwt as static lib. I prefer to build
>> release apps statically linked because deploying Mac apps usually
>> means including all the frameworks, which results in larger App
> Simply disable QwtDll in qwtconfig.pri
>> This also means that am thinking of a way to specify
>> configuration options for qwt without editing the qwtconfig.pri file.
> How is this is related to static linkage ?
I'll get into this in a future post...
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.