<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; " class="">  On Tue, 2006-08-01 at 21:42 +0100, Ippei UKAI wrote: <BLOCKQUOTE type="CITE"> <PRE><FONT color="#000000">Hi,</FONT>

<FONT color="#000000">Briefly about .app package then:</FONT>

<FONT color="#000000">First, you need the right package structure (normal directories). You  </FONT>
<FONT color="#000000">can read about it on apple's documentation, but you can just see any  </FONT>
<FONT color="#000000">existing application bundles.</FONT>

<FONT color="#000000">Second, to be a proper application bundle, the files PkgInfo and  </FONT>
<FONT color="#000000">Info.plist should be in place.</FONT>

<FONT color="#000000">Third, HuginOSX finds many resources inside the bundle, so have to  </FONT>
<FONT color="#000000">place resources in the right places. Again, you can see inside  </FONT>
<FONT color="#000000">HuginOSX and reproduce it, but main idea is thatall resources go in  </FONT>
<FONT color="#000000">to the Resources folder, but localised version goes into the  </FONT>
<FONT color="#000000">languages's .lproj folder. Localising part is done by my hand written  </FONT>
<FONT color="#000000">script which is in the CVS. The xrc is (almost) directly copied into  </FONT>
<FONT color="#000000">the Resource folder.</FONT>

<FONT color="#000000">Lastly, all executable (and other platform-dependent) codes goes to  </FONT>
<FONT color="#000000">Contents/MacOS (HuginOSX and optionally enblend). If you use dynamic  </FONT>
<FONT color="#000000">libraries, you should compile the executables to dynamically link  </FONT>
<FONT color="#000000">@executable_path/lib*.dylib (I have no idea how, by the way... I  </FONT>
<FONT color="#000000">simply use static libs). Some projects choose to store dynamic libs  </FONT>
<FONT color="#000000">in Contents/Frameworks (@executable_path/../Frameworks/lib*.dylib).</FONT>

<FONT color="#000000">Basically, on OSX, no application that is not bundled can handle GUI.  </FONT>
<FONT color="#000000">You definitely need application package. I also chose to simplify the  </FONT>
<FONT color="#000000">install process and linked all the libraries statically. You may  </FONT>
<FONT color="#000000">choose otherwise, but most 'nice' applications are distributed as d&amp;d  </FONT>
<FONT color="#000000">installation than installer packages.</FONT>

<FONT color="#000000">Ippei</FONT>
</PRE> </BLOCKQUOTE> <BR style=""> Thanks, Ippei.  So a Makefile which creates the .app directory heirarchy, and copies components in from the mac/ source directory should be simple to code, yes?  There is no other patching, etc. which your XCode project does (other than gather all the needed libraries, and compile things statically).  <BR style=""> <BR style=""> Could you suggest any thing else the Makefile would have to do?  For example, Emacs' configure.in does:<BR style=""> <BR style=""> <PRE>### Use Mac OS X Carbon API to implement GUI.
if test "${HAVE_CARBON}" = "yes"; then
  AC_DEFINE(HAVE_CARBON, 1, [Define to 1 if you are using the Carbon API on Mac OS X.])
  ## Specify the install directory
  carbon_appdir=
  if test "${carbon_appdir_x}" != ""; then
    case ${carbon_appdir_x} in
      y | ye | yes)  carbon_appdir=/Applications ;;
      * ) carbon_appdir=${carbon_appdir_x} ;;
    esac
  fi
  # We also have mouse menus.
  HAVE_MENUS=yes

  tmp_CFLAGS="$CFLAGS"
  CFLAGS="$CFLAGS -framework Carbon"
  AC_CHECK_FUNC(CancelMenuTracking, have_cmt=yes, have_cmt=no)
  if test "$have_cmt" = yes; then
    AC_DEFINE(HAVE_CANCELMENUTRACKING, 1,
              [Define to 1 if CancelMenuTracking is available (Mac OSX).])
  fi
  CFLAGS="$tmp_CFLAGS"
fi<FONT class="Apple-style-span" face="Helvetica"><SPAN class="Apple-style-span" style="white-space: normal;"></SPAN></FONT></PRE><PRE><FONT class="Apple-style-span" face="Helvetica"><SPAN class="Apple-style-span" style="white-space: normal;">They also have "mac/Emacs.app" already checked into CVS with the PkgInfo, Info.plist, etc. files already setup.  Then make simply copies the created executable to mac/Emacs.app/Contents/MacOS/, if it realizes it must make a mac version.  The src/Makefile is auto-generated by configure (via m4 pre-processing) with the correct things in it, such as:</SPAN></FONT></PRE><DIV style="">${emacsapp}Contents/MacOS/Emacs: emacs${EXEEXT}</DIV><DIV style="">        mkdir -p ${emacsapp}Contents/MacOS/;</DIV><DIV style="">        cd ${emacsapp}Contents/MacOS/; cp ../../../../src/emacs${EXEEXT} Emacs${</DIV><DIV style="">EXEEXT}</DIV><DIV style="">${emacsapp}Contents/Resources/Emacs.rsrc: ../mac/src/Emacs.r</DIV><DIV style="">        /Developer/Tools/Rez -useDF -o ${emacsapp}Contents/Resources/Emacs.rsrc </DIV><DIV style="">/System/Library/Frameworks/Carbon.framework/Headers/Carbon.r $&lt;</DIV><DIV style="">${libsrc}emacstool${EXEEXT}: ${libsrc}emacstool.c</DIV><DIV style="">        cd ${libsrc}; ${MAKE} ${MFLAGS} emacstool${EXEEXT}</DIV><DIV style=""><BR style=""> etc.  So I think it's really just a matter of:</DIV><DIV style=""><BR class="khtml-block-placeholder"></DIV><DIV style="">1. creating and checking into CVS mac/Hugin.app with all the correct structure and handful of pre-existing files from your HuginOSX.app bundle.</DIV><DIV style="">2. arranging for Pablo's configure/Makefile heirarchy to copy the binary into the correct location. <BR style="">3. (optional) Borrow their make-package script to make a compressed installer package .dmg file.</DIV><DIV style=""><BR class="khtml-block-placeholder"></DIV><DIV style="">We could even copy enblend and autopano-sift into Contents/MacOS (assuming license issues with the later don't interfere), and pre-configure Hugin to look for them there.</DIV><DIV style=""><BR class="khtml-block-placeholder"></DIV><DIV style="">Pablo, any suggestions on the best way to hook into your current built system to copy the executable into the mac/Hugin.app directory?</DIV><DIV style=""><BR class="khtml-block-placeholder"></DIV><DIV style="">JD</DIV><DIV style=""><BR class="khtml-block-placeholder"></DIV></BODY></HTML>