Important: Please read the Qt Code of Conduct -


  • When building a Qt app for OS X a template Info.plist file is filtered through sed on its way into the application bundle's Contents/Info.plist file. The template file has placeholder tokens - @ICON@, @EXECUTABLE@ and @TYPEINFO@ - for values that are substituted by sed in the Makefile rules for the bundle's Contest/Info.plist file. If a QMAKE_INFO_PLIST file is specified in the .pro file, the Makefiles generated by qmake will use the specified file instead of the template Info.plist file. So far so good.

    It's seems that the substitution value for @EXECUTABLE@ is the .pro TARGET value. The substitution value for @ICON@ is the basename of the ICON value from the .pro file; the full pathname specified is used with a rule qmake generates to copy the specified file into the bundle's Contents/Resources directory.

    But what about the @TYPEINFO@ substitution value? This is always getting the value "????". Yes, value of the CFBundleSignature key can be changed in the file specified by QMAKE_INFO_PLIST, but this leaves the bundle's Contents/PkgInfo file containing "APPL????" from a Makefile rule generated by qmake, which is unacceptable.

    Also, note that the Info.plist file is expected to contain the version number of the application, but there is no placeholder token for the Info.plist to provide this. The value of VERSION from the .pro file is used by qmake when it generates the dist target rules (and the qmake documentation for the VERSION variable is does say that it "contains the version number of the application"), but is not used to sed the Info.plist.

    It sure would help if the Info.plist handling by qmake was done more thoroughly. This would save developers a lot of effort. Is there a workaround that can be implemented under the auspices of qmake that can provide a firm grasp of the OS X app bundle configuration?

  • The solution was to define new targets, with their dependencies and commands, in a macx scope (the TARGET name is HiView):

    macx {
    # Application signature (4 characters).

    #   Adds the Mac icons to the application bundle.
    ICON                =   Images/HiView_Icons.icns   =   Info.plist
    Info_plist.depends  =   Info.plist.template $${TARGET}.app/Contents/Info.plist
    Info_plist.commands =   @$(DEL_FILE) $${TARGET}.app/Contents/Info.plist$$escape_expand(\n\t) \
                            @$(SED) -e "s,@EXECUTABLE@,$$TARGET,g" -e "s,@VERSION@,$$MODULE_VERSION,g" -e "s,@TYPEINFO@,$$HiView_SIGNATURE,g" -e "s,@ICON@,$$basename(ICON),g" Info.plist.template > $${TARGET}.app/Contents/Info.plist
    QMAKE_EXTRA_TARGETS +=  Info_plist
    PRE_TARGETDEPS      +=  $$      =   PkgInfo
    PkgInfo.depends     =   $${TARGET}.app/Contents/PkgInfo
    PkgInfo.commands    =   @$(DEL_FILE) $$PkgInfo.depends$$escape_expand(\n\t) \
                            @echo "APPL$$HiView_SIGNATURE" > $$PkgInfo.depends
    PRE_TARGETDEPS      +=  $$


    The builtin targets for the bundle Contents files are still present, but the additional targets replace the results of the builtin targets with files having the desired contents. The bundle's Contents/Info.plist deleted and then regenerated from an Info.plist.template file; and the Contents/PkgInfo is deleted and rewritten with appropriate 8 characters. The new target commands will always be run because the they are pseudo targets (no files are created), and the targets are placed at the head of the $(TARGET) target dependency list using PRE_TARGETDEPS.

    This solution is something of a hack. but it works in a way that provides the application developer with complete control over specifying the contents of the bundle's key Contents/Info.plist file and sibling PkgInfo file. This solution could easily be extended to manage additional contents of the application bundle.

Log in to reply