System Requirements Get The Source From GitHub Install The Cocotron Development Tools Build The Cocotron Frameworks Set Up A Project To Build With Cocotron Build A Project With The Cocotron Development Tools Windows App Icon Linux/BSD cross-compilation platform interface

Where to put framework DLL's

Generally speaking Windows will look for DLL's in the EXE's directory or on the PATH environment variable. This means that frameworks do not work as-is on Windows, you need to shuffle files around to execute a program which uses frameworks.

NSBundle implements a couple strategies to deal with this but the simplest is to put the frameworks in the executable's directory like so:

MyApp.app/Contents/Windows/MyApp.exe
MyApp.app/Contents/Windows/AppKit.1.0.dll
MyApp.app/Contents/Windows/AppKit.framework
MyApp.app/Contents/Windows/Foundation.1.0.dll
MyApp.app/Contents/Windows/Foundation.framework

Windows will find the DLL's and the NSBundle code will look for the .framework/ directories for resources

See the retargetBundle page for information on a tool which will do this automatically for you during the build process.

The InstallCDT script installs a tool called 'retargetBundle' for quickly copying the essential runtime pieces of a framework into a .app directory during an Xcode build. The intent is that it is used in a scripted phase of your target, such as.:

This simplifies the problem of post-processing an executable so that the Foundation/AppKit/other framework dll's and resources are in the right location before execution.

  retargetBundle
  
  Synopsis:
  
  Quickly copies the essential parts of a .framework in the Mac OS X layout
  to a layout more suitable for Windows or Unix using the Cocotron runtime.
  
  Options:
  
   -F 
   
   Adds a directory to the beginning of the search path. The initial search
   path is the value of the environment variable FRAMEWORK_SEARCH_PATHS if
   present, typically set by Xcode. The search path can not be empty.
   
   -framework 
   
   Name of framework to copy, e.g. "Foundation". The path of the framework is
   immediately resolved using the current search path. Subsequent changes to
   the search path will not affect the resolved path of this framework. At least
   one framework must be specified.
      
   -destination 
   
   Directory to place the resulting files. If no directory is specified, the
   current directory is used.
  
  Discussion:
  
   While the default OS X framework organization is perfectly suitable as a
   compile/link time solution it poses cumbersome execution time implications
   on Windows and Unix. The OS X layout would require altering the dynamic link
   path or placing frameworks at absolute paths, which is inconvenient for
   developers and users.

   The convention with the Cocotron runtime is locate frameworks alongside the
   executables that need them, typically inside the .app wrapper, or in the same
   directory as a command line tool. Both Windows and Unix have functionality
   which makes this easy to accomplish provided the framework is reorganized.
   
   The Windows dynamic linker will automatically recognize dll's located in the
   same directory as the .exe and most Unix systems allow similar behavior to be
   configured using the -rpath linking option and $ORIGIN.
   
   retargetBundle will copy a framework's dynamic library to the destination 
   directory and copy the .framework directory and resources to the destination
   directory. Symbolic links, headers and link libraries are not copied. 
      
   retargetBundle is intended to be used as the final build stage in an Xcode
   project, copying the essential framework pieces into a .app wrapper for
   immediate execution. The copy is done efficiently, only copying changed files.
   
   retargetBundle will not delete files, if the framework's structure has changed,
   you should clean your target and rebuild.