Hi Paul,
----- Original Message -----
>
> My first question relates to how pmchart gets built, I'm going to guess it's
> the src/pmchart/GNUmakefile. This seems to do some stuff for OSX around
> building the OSX Application bundle.
Yes, thats the starting point. That then uses qmake to do the "real" build,
which reads the actual pmchart.pro file and does platform-specific stuff (on
some platforms, it generates a "Makefile" and builds with that, on Mac OS X
(but maybe not via Homebrew?) the qmake setup when using Qt from qt.io is to
use Xcode projects for the build (IIRC).
> My first confusion is that it appears superficially to be trying to build in
> /Applications/pmchart.app. When my failure occurs, there's a basic shell of
> the OSX bundle in this location, but not much else.
No building should be done in /Application (or any path like that) - that's
more likely to be the final (intended) installation target.
> I do see another OSX bundle here:
>
> ./pcp-3.10.9/src/pmchart/build/release/pmchart.app
>
> More confusion, I see these in the logs:
>
> ./../install-sh -o root -g wheel -m 644
> build/release/pmchart.app/Contents/PkgInfo
> /Applications/pmchart.app/Contents/PkgInfo
> ../../install-sh -o root -g wheel -m 644 pmchart.info
> /Applications/pmchart.app/Contents/Info.plist
> ../../install-sh -o root -g wheel -m 755 -d
> /Applications/pmchart.app/Contents/MacOS
>
> **QUESTION**: So, is the /Applications/pmchart.app the real final destination
> binary? Or is it the ./pcp-3.10.9/src/pmchart/build/release/pmchart.app
> one?
Definitely not the latter - that is the build-generated binary, which would then
be copied *somewhere* (via "make install" or "make install_pcp" before packaging
commences).
> The reason I get confused is that later in the build cycle, I believe as part
> of builddefs.in, where it uses the Xcode `otool` to list dependent
> frameworks, it ends up executing:
>
> [ pmchart ](master)$ otool -L
> build/release/pmchart.app/Contents/MacOS/pmchart
> build/release/pmchart.app/Contents/MacOS/pmchart:
This looks like the initially built binary location for pmchart in your
build BTW.
> libpcp.3.dylib (compatibility version 0.0.0, current version 0.0.0)
>
> /Library/PCP/Frameworks//usr/local/opt/qt/lib/QtSvg.framework/Versions/4/QtSvg
> (compatibility version 4.8.0, current version 4.8.7)
> /usr/local/opt/qt/lib/QtGui.framework/Versions/4/QtGui (compatibility
> version 4.8.0, current version 4.8.7)
> /usr/local/opt/qt/lib/QtCore.framework/Versions/4/QtCore (compatibility
> version 4.8.0, current version 4.8.7)
> /usr/local/opt/qt/lib/QtNetwork.framework/Versions/4/QtNetwork
> (compatibility version 4.8.0, current version 4.8.7)
> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
> 104.1.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1226.10.1)
> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
> 913.0.0)
>
>
> See builddefs.in line 760-ish
That stuff is all rewriting the pmchart binary so that the library paths
embedded in the binary point to the correct locations for the Qt libraries
that will be supplied by the pcp dmg file.
> so we seem to have 2 copies of pmchart.app going on at the same time, what
> each is used for is unclear to me.
There would be an initially built binary (looks like that would be
pcp-3.10.9/build/release/pmchart.app/Contents/MacOS/pmchart for you, I think)
and then a copy of that (possibly after otool-processing) installed somewhere
else temporarily so that packaging can be done (this'd have /usr/local and
similar paths embedded, all below a common temporary root).
> Anyway, next problem I face is that you can see in the above listing of otool
> that the QtSvg library it thinks it's linked against is in a weird location.
>
>
> /Library/PCP/Frameworks//usr/local/opt/qt/lib/QtSvg.framework/Versions/4/QtSvg
> (compatibility version 4.8.0, current version 4.8.7)
>
>
> This path does not exist, and seems to be a a function of an attempt to copy
> the QtSvg Framework. I had manually hacked this file to copy the right
> location by doing this:
AIUI, HomeBrew is more like a Linux/Unix packaging system, with dependency
management between packages. If so, you possibly would be better off just
circumventing all this otool+copying, which is trying to make sure that we
get a copy of the Qt libraries we use inside the DMG file we produce - and
using the HomeBrew-provided libraries via package dependencies?
> diff --git a/src/include/builddefs.in b/src/include/builddefs.in
> index fa83900..15b1acc 100644
> --- a/src/include/builddefs.in
> +++ b/src/include/builddefs.in
> @@ -756,7 +756,7 @@ INSTALL_QT_FRAMEWORKS=\
> $(call
>
> INSTALL_DIRECTORY_HIERARCHY,$(MAC_FRAMEWORKS_DIR)/$$tdir,/Library/PCP);
> \
> mkdir -p frameworks/$$tdir || exit 1; \
> fwqt="frameworks/$$qt"; \
> - cp /Library/Frameworks/$$qt frameworks/$$qt || exit 1; \
> + cp /usr/local/Cellar/qt/4.8.7_1/lib/QtSvg.framework/Versions/4/$$qt
> frameworks/$$qt || exit 1; \
> otool -L $$fwqt | awk '{if (NR != 1) {print $$1}}' |\
> egrep 'Qt.*\.framework' | while read dep; do \
> install_name_tool -change $$dep $(MAC_FRAMEWORKS_DIR)/$$dep
> $$fwqt;\
>
>
>
> Somehow the fully qualified path to the QtSvg framework is being found, and
> then copied into here:
>
> pcp-3.10.9/src/pmchart/frameworks/usr/local/opt/qt/lib/QtSvg.framework
>
> I can't quite work out where that is doing this deep directory tree copy
> rather than just taking that root 'QtSvg.framework' directory and putting
> tin the root of 'framework's ?
>
> This is the bit I can't find, where does it do that directory copy ? By the
> looks of it the `$qt` variable is coming from:
>
> otool -L $(1) | awk '{if (NR != 1) {print $$1}}' |\
> egrep 'Qt.*\.framework' | while read qt; do \
>
> but then I saw this:
>
> $(call
> INSTALL_DIRECTORY_HIERARCHY,$(MAC_FRAMEWORKS_DIR)/$$tdir,/Library/PCP); \
>
> Which looks to be trying to do something in /Library/PCP which contains the
> QtSvg in this root:
>
> [ Frameworks ]$ ll /Library/PCP/Frameworks/
> total 0
> drwxr-xr-x 6 root wheel 204B 30 Oct 14:30 .
> drwxr-xr-x 5 root wheel 170B 30 Oct 14:30 ..
> drwxr-xr-x 3 root wheel 102B 30 Oct 14:30 QtCore.framework
> drwxr-xr-x 3 root wheel 102B 30 Oct 14:30 QtGui.framework
> drwxr-xr-x 3 root wheel 102B 30 Oct 14:30 QtNetwork.framework
> drwxr-xr-x 3 root wheel 102B 30 Oct 14:30 QtSvg.framework
>
> Given the timestamps, this copy of QtSvg might be from a previous install of
> Qt (not homebrew).
>
> So I guess I'm a bit stuck trying to work out where the directory reference
> of '/usr/local/.....' is being appended into one of the copies..?
>
> If this doesn't sound clear, that's probably because it isn't. I'm now lost
> in a bit of a forest of a build system new to me.
The files to concentrate on are all the build* files below src/include -
and the .in ones are used to generate the non-.in variants which are then
actually used in the build. Initial paths like /usr/local come in from
either Makepkgs or configure.ac files.
Beyond that, I can't follow what's going on above either :) - would need to
be sitting there with you helping to debug it I think.
cheers.
--
Nathan
|