COMP: Allow use of 'project()' in CMakeLists.txt of extension/module

The previous approach enforcing to NOT use "project()" in CMakeLists.txt
is not required anymore.
This was done so that SlicerConfig.cmake included after calling
"find_package(Slicer)" could:
(1) include SlicerBlockSetCMakeOSXVariables
(2) then call the project() statement

Using recent version of CMake, this "hack" was preventing extension from
being built.

To prevent the configure error, "SlicerBlockSetCMakeOSXVariables" is not
included anymore automatically after calling "find_package(Slicer)"

That said, to allow the CMAKEOSX* to (optionally) be set automatically,
a different approach is now considered.

This also make it possible to call "project()" within the CMakeLists.txt
of extension or module.

To optionally have the CMAKEOSX* variable set within a project, the
developer could call:

find_package(Slicer COMPONENTS ConfigurePrerequisites)

before any "project()" calls.

For completeness, the discussion with CMake developer regarding the possible
approach to automatically set the CMAKEOSX* variables have been
reported below.

// ------------------
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 CMAKEOSX* 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 CMAKEOSX* 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.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@22038 3bd1e089-480b-0410-8dfb-8563597acbee