BUG: Ensure library can be loaded from different place using @rpath

Before this commit, attempt have been made (r18311, r18325, r18581) to
install both built-in CLI and extension CLI executable in a folder
located at some depth of the main Slicer executable. This was needed
because all libraries were referenced based on the location of the main
Slicer executable using "@executable_path". This was working *only* in the
case of built-in CLI but wasn't scaling very well for the extension CLI
executable. Indeed, being able to both differentiate the different
installed extension and keeping the depth to 1 level wasn't easily
feasible:

  /path/to/Slicer.app/Contents/MacOS/Slicer
  /path/to/Slicer.app/Contents/cli-modules/MyCLI
  /path/to/Slicer.app/Contents/Extensions-21855/SkullStripper/cli-modules/MyCLI

A solution could have been to install extensions directly in "Slicer.app"
folder and update the cli install sub dir to get something like:

  /path/to/Slicer.app/Extensions-21855/SkullStripper/MyCLI

While possible, it would have remain a special case to maintain.

Instead, by using "@rpath", CLI modules can now be installed in the Slicer
standard location "Slicer_CLIMODULES_LIB_DIR" instead of "Slicer_CLIMODULES_SUBDIR".
This commit remove the special case which never worked (issue #3051)

Waiting the topic "tweak-bundleutilities-for-rpath" is fully matured and
integrated in CMake, use custom version of BundleUtilities and GetPrerequisites.
See http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/tweak-bundleutilities-for-rpath

Since our custom version of the CMake modules now consider "~/usr/.*/lib",
the implementation of "gp_resolved_file_type_override" has been removed.

Remove the hack specific to LibArchive (introduced by commit r19615), since
the library is fixed up using the default library matching pattern, it
will be installed in the expected location.

SlicerExecutionModel has also been updated to link the CLI executable
and library with "-rpath" so that they can resolve the location of Slicer
libraries.
COMP: Do not include "SlicerBlockSetCMakeOSXVariables" before project()

WORK IN PROGRESS ...

From Jc:

Hi Brad,

To summarize, the user build a building using a line similar to:

  cmake -DSlicer_DIR:PATH=/path/to/Slicer-build -DCMAKE_BUILD_TYPE:STRING=Release ../MyPlugin

  Passing Slicer_DIR is the only requirement.

// ------------------
You are right the file in source/build tree won't help.

// ------------------
Currently, the value for CMAKE_OSX_* are set in SlicerConfig.cmake and I would like the plugin to use these. The current approach is to force the following convention:

    set(EXTENSION_NAME "Foo")

    find_package(Slicer)
    include(${Slicer_USE_FILE})

    [...]

where project() was called within the Slicer use file.

// ------------------
By using this new approach:

   find_package(Slicer COMPONENTS ConfigurationPrerequisites)

   project(Foo)

   find_package(A ..)
   find_package(B ..)

  Can I be sure that the first call to "find_package" will be done before language feature are enabled ?

Thanks
Jc

// --------------------------
From Brad:

On 04/19/2013 10:54 AM, Jean-Christophe Fillion-Robin wrote:
>   cmake -DSlicer_DIR:PATH=/path/to/Slicer-build -DCMAKE_BUILD_TYPE:STRING=Release ../MyPlugin

Great, so find_package doesn't actually need to search but only
load the package config file.

> Currently, the value for CMAKE_OSX_* are set in SlicerConfig.cmake
> and I would like the plugin to use these. The current approach is
> to force the following convention:
>
>     set(EXTENSION_NAME "Foo")
>     find_package(Slicer)
>     include(${Slicer_USE_FILE})
>
> where project() was called within the Slicer use file.

Instead of the above three lines, try these three::

 project(Foo NONE)
 find_package(Slicer)
 SlicerConfigPlugin()

SlicerConfig.cmake provides the SlicerConfigPlugin macro to:

* FATAL_ERROR if languages are already enabled and tell the
  plugin author to add NONE to the project command

* Get the extension name from PROJECT_NAME, or alternatively
  from an optional explicit argument

* Set OS X platform variables and call enable_language()

Larger projects that provide a Slicer plugin along with a bunch
of other unrelated stuff will not want Slicer to control their
enable_language calls.  Therefore SlicerConfig should add another
macro (or options to this one) to just check that an already
enabled language has a matching platform selection and skip its
enable_language calls.

>    find_package(Slicer COMPONENTS ConfigurationPrerequisites)
>    project(Foo)
>    find_package(A ..)
>    find_package(B ..)
>
>   Can I be sure that the first call to "find_package" will be
>   done before language feature are enabled ?

Yes, but the above method may be even simpler.