Re: [cmake-developers] iOS: direction to official support and questions

2017-09-27 Thread Craig Scott 
On Thu, Sep 28, 2017 at 7:40 AM, Brad King  wrote:

> On 09/27/2017 08:18 AM, Raffi Enficiaud wrote:
> > For cross-compiling a project on iOS or iOS simulator, and since those 2
> > platforms are still Darwin, I believe that:
> >
> > * from a user perspective:
> >* CMAKE_SYSTEM_NAME should be set to "Darwin"
> >* CMAKE_SYSTEM_VERSION should be set to iOS or iOS-simulator,
> > possibly with a version (like "Mac OSX 10.2" in Darwin.cmake)
>
> Although macOS is based on Darwin, it has historically been a mistake
> to make CMAKE_SYSTEM_NAME "Darwin".  macOS and iOS are different
> enough that they each should have their own platform names/modules.
> Also, CMAKE_SYSTEM_VERSION should always be a number.
>
> > However, I just notice the existence of
> > "Modules/Platform/Darwin-Initialize.cmake" that is setting several
> > variables. When is this file sourced? should be before
> > "Modules/Platform/Darwin.cmake" but I failed to see from where.
>
> See comments here:
>
>   https://gitlab.kitware.com/cmake/cmake/blob/v3.9.3/
> Source/cmGlobalGenerator.cxx#L333-372
>
> for how all those files are loaded.  `iOS*.cmake` modules would be
> appropriate for first-class iOS support.  Ideally it should work
> with just `-DCMAKE_SYSTEM_NAME=iOS` without a full toolchain file,
> if that is possible.
>
> > I see several problems with this file if I were to make it iOS aware.
> > For instance it contains variables that are checking for the version,
> > but based only on the macOS scheme.
>
> That's why CMAKE_SYSTEM_NAME should be distinct so we can use a totally
> separate set of modules.  I think that solves most of the other problems
> you raised.
>

(Starting on a tangent, coming back to the above at the end). Note also
that for iOS builds, you don't really want to go fiddling with
the CMAKE_FIND_ROOT_PATH_MODE_... variables, either in toolchain files or
in platform support files that come with CMake. You see this a lot in
toolchain examples online, but that's not really compatible with the way
Xcode allows you to switch between device and simulator builds. There's not
really any 100% satisfactory solution to this in CMake at the moment, as
Eric Wing has summarised rather well in a few recent emails to this list.
As a starting point, I'd recommend only trying to set the minimal things in
iOS platform files which give a successful build. The handling of
find_...() command search paths falls outside of that, in my view.

FWIW, I've been experimenting with this area quite a bit lately after it
became a topic of discussion on this list, in the issue tracker and in
merge requests. At the moment, a minimal toolchain file for iOS which gets
you about as far as you can go seems to be something like this:

set(CMAKE_MACOSX_BUNDLE YES)
if(NOT CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED)
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED NO)
endif()

set(CMAKE_OSX_SYSROOT iphoneos)


All but the last line should ideally be unnecessary, but that's the current
state of things at least. The above setting of CMAKE_OSX_SYSROOT works
because Xcode sees the SDK as iphoneos but recognises that there's an
associated simulator configuration. You can then switch the target platform
(device or simulator) at build time without re-running CMake. This is
highly desirable for iOS devs, so it raises the question of how to not
break that if we make CMAKE_SYSTEM_NAME rather than Darwin +
CMAKE_OSX_SYSROOT as the primary way to set up for iOS. Also keep in mind
that, while most projects will probably just be happy to use the latest
installed SDK by default, it's technically possible to specify a specific
SDK version with an appropriate value in CMAKE_OSX_SYSROOT (e.g.
iphoneos9.3, or something like that, can't exactly recall off the top of my
head). If CMAKE_SYSTEM_NAME is taught to recognise iOS as distinct from
Darwin, we'd need to be very careful not to break existing projects that
assume the (fragile but still workable for some projects) method above.




-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] iOS: direction to official support and questions

2017-09-27 Thread Brad King 
On 09/27/2017 08:18 AM, Raffi Enficiaud wrote:
> For cross-compiling a project on iOS or iOS simulator, and since those 2 
> platforms are still Darwin, I believe that:
> 
> * from a user perspective:
>* CMAKE_SYSTEM_NAME should be set to "Darwin"
>* CMAKE_SYSTEM_VERSION should be set to iOS or iOS-simulator, 
> possibly with a version (like "Mac OSX 10.2" in Darwin.cmake)

Although macOS is based on Darwin, it has historically been a mistake
to make CMAKE_SYSTEM_NAME "Darwin".  macOS and iOS are different
enough that they each should have their own platform names/modules.
Also, CMAKE_SYSTEM_VERSION should always be a number.

> However, I just notice the existence of 
> "Modules/Platform/Darwin-Initialize.cmake" that is setting several 
> variables. When is this file sourced? should be before 
> "Modules/Platform/Darwin.cmake" but I failed to see from where.

See comments here:

  
https://gitlab.kitware.com/cmake/cmake/blob/v3.9.3/Source/cmGlobalGenerator.cxx#L333-372

for how all those files are loaded.  `iOS*.cmake` modules would be
appropriate for first-class iOS support.  Ideally it should work
with just `-DCMAKE_SYSTEM_NAME=iOS` without a full toolchain file,
if that is possible.

> I see several problems with this file if I were to make it iOS aware. 
> For instance it contains variables that are checking for the version, 
> but based only on the macOS scheme.

That's why CMAKE_SYSTEM_NAME should be distinct so we can use a totally
separate set of modules.  I think that solves most of the other problems
you raised.

> PS: how should we proceed with the developments? Having a fork on Gitlab 
> based on master and start integrating from there would be ok? Do you 
> need a build machine first?

Yes, this should be integrated through a fork and merge request.
For tests, take a look at how the `Tests/RunCMake/Android` test works.
We should be able to turn on iOS support tests on macOS builds on
hosts that have iOS development infrastructure installed.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Tools for handling cross project dependencies

2017-09-27 Thread Egor Pugin 
> The idea is to include several "packages" (one package ~ one project in 
> Boost) and make those available to the build, exactly as for a regular 
> CMakeLists.txt that adds several directories or subprojects through a 
> sequence of calls to "add_directories".
> However, the difference here is that "packages" have inter-dependencies, and 
> the order of the "add_directories" should honor those dependencies.

I solved the issue of including several dirs (via 'add_directories')
using guards 'if (TARGET name); return(); endif()' in my pkg manager.
See boost libraries there: https://cppan.org/search?q=boost
Each library can be included to project separately with autoincluding
required deps for it.
Config files (CMakeLists.txt, "dependencies.cmake" in you terminology)
autogenerated with the pkg manager client iteself - 1 config per 1
library.
You could try to look how the generated files organized, maybe you
find something useful.

On 27 September 2017 at 15:50, Raffi Enficiaud
 wrote:
> Hi CMake,
>
> I am currently working on a toy cmake prototype for Boost. I am not sure it
> will ever be released but I believe it might be useful beyond this project.
>
> The idea is to include several "packages" (one package ~ one project in
> Boost) and make those available to the build, exactly as for a regular
> CMakeLists.txt that adds several directories or subprojects through a
> sequence of calls to "add_directories".
>
> However, the difference here is that "packages" have inter-dependencies, and
> the order of the "add_directories" should honor those dependencies.
>
> I developed a rather small CMake script that
> * encodes those dependencies in a very simple manner, just by stating parent
> projects in the DAG of dependencies in an appropriate cmake variable,
> * runs the ordered inclusion of those dependencies inside the master
> project,
>
> It works like this:
> 1/ a small "dependencies.cmake" declares the provided components and
> dependencies:
>* a variable that indicates the provided components (say "core", "doc"
> and "test"). Each component defines a CMakeLists.txt
>* a variable that indicates the dependencies to another module (with or
> without components)
>
> 2/ a function parses a build tree (not necessarily flat) and detect all
> those dependencies.cmake, loads the containing variables and extract the
> module and components
>
> 3/ another function reads the variables set by step 2/ and adds the
> components in the right order
>
> Additional filtering can happen after 2 (already implemented in my project)
> to remove all the packages/components that are not needed for the current
> build, but 3/ will bring any necessary dependency to the build.
>
> A possible example, that can of course be adapted, is given below.
>
> My inquiry there is the following:
> * would this be of any interest for the community? I know that some projects
> are struggling with this or provide solutions that, as a developer, dislike
> * is there already any such mechanism in cmake? I failed to see any, and the
> problem statement is a different than the cmake-package facility provided by
> cmake.
>
> I believe it would also be possible to enhance step 3/ by eg. having a logic
> that checks out the package sources instead of doing an "add_directory", and
> by the possible intermediate filter after step 2/, then checking out only
> what is needed for the end-user/developer.
>
> Thanks!
> Raffi
>
>
>
> -- Example for Boost.test 
>
> set(_current_package "TEST")
> # this declares the components
> set(BOOST_LIB_${_current_package}_COMPONENTS "build" "doc" "test")
>
> # this declares the dependencies for the component "build"
> set(BOOST_LIB_${_current_package}_COMPONENTS_BUILD_DEPENDENCY
>   "system:build"
>   "core:build"
>   "config:build"
>   "predef:build"
> )
>
> # same for the component "DOC"
> set(BOOST_LIB_${_current_package}_COMPONENTS_DOC_DEPENDENCY )
> # same for the component "TEST" (or the module TEST)
> set(BOOST_LIB_${_current_package}_COMPONENTS_TEST_DEPENDENCY "test:build")
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers



-- 
Egor Pugin
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on

[cmake-developers] Seeking feedback for new DownloadDependency module

2017-09-27 Thread Craig Scott 
Devs,

Merge request 1306
 implements a
new module *DownloadDependency* and this email is to solicit feedback, with
a focus on the API the module presents. Brief summary follows so you can
get an idea if you're interested in the topic.

The new module provides three functions which together provide facilities
for downloading dependencies at configure time rather than at build time.
The main motivating case is to allow project dependencies to be downloaded
during configure so they can be brought into the build immediately via
add_subdirectory() or however the main project wants to make use of the
downloaded content (could also be things like certificates, assets, CMake
helper modules, etc.). The key feature is that you don't have to wait until
build time before the contents are available, so you can do things that
would not otherwise be possible with, for example, ExternalProject used in
the usual way. Another alternative, the file(DOWNLOAD) command, only
supports limited download methods, whereas DownloadProject supports all the
methods that ExternalProject_Add() supports (DownloadProject is implemented
in terms of ExternalProject_Add() via a sub-build executed via
execute_process()).

The module conveniently supports project hierarchies and gives parent
projects override control over any dependencies that child projects might
define. It also facilitates ensuring that a particular dependency is only
downloaded once if multiple child projects require it. No central
repository of build recipes is required, parent projects are in control of
any settings they wish to adjust before pulling in a child dependency via
add_subdirectory() or include() or whatever.

The module has been evolved in a real-world environment for the past 2
years on complex project hierarchies, with builds across Linux, Windows,
Mac and iOS. The module as presented in the merge request is a cleaned up
version of that. The three functions provided by the module are:


   - download_dependency_details()
   - download_dependency_state()
   - download_dependency()


See the documentation included in the merge request for an explanation of
each of these and the overall module. Examples are included in the docs.
Your feedback would be welcome.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Tools for handling cross project dependencies

2017-09-27 Thread Raffi Enficiaud 

Hi CMake,

I am currently working on a toy cmake prototype for Boost. I am not sure 
it will ever be released but I believe it might be useful beyond this 
project.


The idea is to include several "packages" (one package ~ one project in 
Boost) and make those available to the build, exactly as for a regular 
CMakeLists.txt that adds several directories or subprojects through a 
sequence of calls to "add_directories".


However, the difference here is that "packages" have inter-dependencies, 
and the order of the "add_directories" should honor those dependencies.


I developed a rather small CMake script that
* encodes those dependencies in a very simple manner, just by stating 
parent projects in the DAG of dependencies in an appropriate cmake variable,
* runs the ordered inclusion of those dependencies inside the master 
project,


It works like this:
1/ a small "dependencies.cmake" declares the provided components and 
dependencies:
   * a variable that indicates the provided components (say "core", 
"doc" and "test"). Each component defines a CMakeLists.txt
   * a variable that indicates the dependencies to another module (with 
or without components)


2/ a function parses a build tree (not necessarily flat) and detect all 
those dependencies.cmake, loads the containing variables and extract the 
module and components


3/ another function reads the variables set by step 2/ and adds the 
components in the right order


Additional filtering can happen after 2 (already implemented in my 
project) to remove all the packages/components that are not needed for 
the current build, but 3/ will bring any necessary dependency to the build.


A possible example, that can of course be adapted, is given below.

My inquiry there is the following:
* would this be of any interest for the community? I know that some 
projects are struggling with this or provide solutions that, as a 
developer, dislike
* is there already any such mechanism in cmake? I failed to see any, and 
the problem statement is a different than the cmake-package facility 
provided by cmake.


I believe it would also be possible to enhance step 3/ by eg. having a 
logic that checks out the package sources instead of doing an 
"add_directory", and by the possible intermediate filter after step 2/, 
then checking out only what is needed for the end-user/developer.


Thanks!
Raffi



-- Example for Boost.test 

set(_current_package "TEST")
# this declares the components
set(BOOST_LIB_${_current_package}_COMPONENTS "build" "doc" "test")

# this declares the dependencies for the component "build"
set(BOOST_LIB_${_current_package}_COMPONENTS_BUILD_DEPENDENCY
  "system:build"
  "core:build"
  "config:build"
  "predef:build"
)

# same for the component "DOC"
set(BOOST_LIB_${_current_package}_COMPONENTS_DOC_DEPENDENCY )
# same for the component "TEST" (or the module TEST)
set(BOOST_LIB_${_current_package}_COMPONENTS_TEST_DEPENDENCY "test:build")

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMP0071

2017-09-27 Thread Sebastian Holtermann 
On Dienstag, 26. September 2017 11:49:18 CEST Brad King wrote:
> On 09/26/2017 11:15 AM, Sebastian Holtermann wrote:
> > "cmake --help-policy CMP0071" already mentions SKIP_AUTOMOC.
> > Should the warning mention SKIP_AUTOMOC as well?
> 
> Yes, please.  It removes an indirection.

The merge request:
https://gitlab.kitware.com/cmake/cmake/merge_requests/1322

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] iOS: direction to official support and questions

2017-09-27 Thread Raffi Enficiaud 

Le 27.09.17 à 12:34, Brad King a écrit :

On 09/26/2017 05:05 PM, Raffi Enficiaud wrote:

Is it possible to source the default setup and to override some parts
when a toolchain is given on the command line?


The toolchain file is loaded very early, before any of the platform
information files.  It is supposed to provide information, not consume it.
It is loaded too early to even know CMAKE_SYSTEM_NAME, because it is
supposed to provide this value.


Thanks for the answers!

From what I understand, I missed the point of the cross compilation 
file a bit, and I should rather go for platform files.


For cross-compiling a project on iOS or iOS simulator, and since those 2 
platforms are still Darwin, I believe that:


* from a user perspective:
  * CMAKE_SYSTEM_NAME should be set to "Darwin"
  * CMAKE_SYSTEM_VERSION should be set to iOS or iOS-simulator, 
possibly with a version (like "Mac OSX 10.2" in Darwin.cmake)


* inside "Modules/Platform/Darwin.cmake"
   * CMAKE_SYSTEM_PROCESSOR should default to armXX for iOS and 
i386/x86_64 for the simulator
   * I do not think that any other compiler than AppleClang is 
supported, but we leave the detection as it is right now. This should 
default to AppleClang anyway.
   * the detection of the base SDKs should be performed inside 
"Platform/Darwin.cmake"
   * the file "Modules/Platform/Darwin-Clang.cmake" should check the 
"CMAKE_SYSTEM_VERSION" to add appropriate flags when 
CMAKE_SYSTEM_VERSION is iOS or simulator. This should include clang and 
apple clang.


If things work ok and if I understand more or less the scope of those 
files, the base SDKs will then be detected from the 
"Modules/Platform/Darwin.cmake".


However, I just notice the existence of 
"Modules/Platform/Darwin-Initialize.cmake" that is setting several 
variables. When is this file sourced? should be before 
"Modules/Platform/Darwin.cmake" but I failed to see from where.


I see several problems with this file if I were to make it iOS aware. 
For instance it contains variables that are checking for the version, 
but based only on the macOS scheme.


Should the CMAKE_SYSTEM_VERSION include the "iOS" or "iOSSimulator" 
part? (like for instance "iOS-10.1" ?) or we stick to a clean version 
name and:


1/ either we change the CMAKE_SYSTEM_NAME to DarwinIOS (we also need to 
distinguish between real device and simulator)
2/ or we carry another variable IOS=TRUE and be careful inside the 
Darwin specific platform files.


My preference goes for 2/ above because:
* having something like DarwinIOS would need to create a full new branch 
of platform support, while the overlap with Darwin is almost 95%.
* iOS is clearly a Darwin platform, just another version, but version 
carries more than a revision number (eg "10.5") that needs to be encoded 
in another variable (eg. IOS=TRUE)
* we will benefit from all the build logic (Darwin, policies, etc) that 
are currently working for OSX





Also, is it possible to check for policies directly from the toolchain
file, or is it too early?


In a project that starts with `cmake_minimum_required(...)` as its first
call (the recommended approach) then policies it sets will be available
when the toolchain file is first loaded by a following `project()` or
`enable_language()` command.  However, toolchain files are not meant to
be general-purpose infrastructure shared by many projects.  They are
meant to be specific to a project and host machine.  Common info about
a platform belongs in CMake's modules, e.g. a Platform/iOS.cmake module
for use with CMAKE_SYSTEM_NAME set to "iOS".  Lacking that, a toolchain
file trying to work without it will undoubtedly need to be hacky.


I believe if I integrate well with the platform files, all things would 
be good again, and the policies will apply naturally (so no hack needed).





This is what I added in the toolchain file, but I feel like this is too
hacky:

set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR TRUE)
set(CMAKE_INSTALL_NAME_DIR "@rpath/")
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH "@rpath/")


If that is universally needed when deploying to iOS then CMake should
be taught this information in a corresponding platform file.


I do not think this is universally needed, I just wanted to mimic the 
default I got when compiling the same source tree but with the OSX 
target platform. Without great success ...




Keeping
it in the toolchain file may work but is an example of the hacky nature
discussed above.  OTOH this looks project-specific to me.  One could
use `@executable_path/` in INSTALL_NAME_DIR for everything and not need
any rpath.


Yes, I was not convinced neither and totally fine with removing this.


and I need to also do this:
set_target_properties(mymainexecutable
   PROPERTIES
 BUILD_WITH_INSTALL_RPATH TRUE
 INSTALL_RPATH "@executable_path/"
)


This encodes knowledge of the relative install destination of the
libraries to the executable, which only the project code itself
can know.

Re: [cmake-developers] iOS: direction to official support and questions

2017-09-27 Thread Brad King 
On 09/26/2017 05:05 PM, Raffi Enficiaud wrote:
> Is it possible to source the default setup and to override some parts 
> when a toolchain is given on the command line?

The toolchain file is loaded very early, before any of the platform
information files.  It is supposed to provide information, not consume it.
It is loaded too early to even know CMAKE_SYSTEM_NAME, because it is
supposed to provide this value.

> Also, is it possible to check for policies directly from the toolchain 
> file, or is it too early?

In a project that starts with `cmake_minimum_required(...)` as its first
call (the recommended approach) then policies it sets will be available
when the toolchain file is first loaded by a following `project()` or
`enable_language()` command.  However, toolchain files are not meant to
be general-purpose infrastructure shared by many projects.  They are
meant to be specific to a project and host machine.  Common info about
a platform belongs in CMake's modules, e.g. a Platform/iOS.cmake module
for use with CMAKE_SYSTEM_NAME set to "iOS".  Lacking that, a toolchain
file trying to work without it will undoubtedly need to be hacky.

> This is what I added in the toolchain file, but I feel like this is too 
> hacky:
> 
> set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR TRUE)
> set(CMAKE_INSTALL_NAME_DIR "@rpath/")
> set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> set(CMAKE_INSTALL_RPATH "@rpath/")

If that is universally needed when deploying to iOS then CMake should
be taught this information in a corresponding platform file.  Keeping
it in the toolchain file may work but is an example of the hacky nature
discussed above.  OTOH this looks project-specific to me.  One could
use `@executable_path/` in INSTALL_NAME_DIR for everything and not need
any rpath.

> and I need to also do this:
> set_target_properties(mymainexecutable
>PROPERTIES
>  BUILD_WITH_INSTALL_RPATH TRUE
>  INSTALL_RPATH "@executable_path/"
> )

This encodes knowledge of the relative install destination of the
libraries to the executable, which only the project code itself
can know.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers