Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by phamelin on Tue, 2011-06-07 19:52

RTT-dev

Hello,

I'm having troubles integrating some orocos components in my build system. I
have a project with multiple targets where some are orocos components. The
problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX to C:\Program
Files\orocos. Here is the problematic snippet of the UseOROCOS-RTT.cmake
file:

  # Detect user flag: install with orocos
  if (INSTALL_PATH STREQUAL "orocos")
    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same location
as Orocos RTT." FORCE)
    mark_as_advanced(INSTALL_PATH)
    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package install
prefix forced by INSTALL_PATH" FORCE)
  else (INSTALL_PATH STREQUAL "orocos")
    if (WIN32)
      set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
location as Orocos RTT." FORCE)
      mark_as_advanced(INSTALL_PATH)
      set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
install prefix forced by INSTALL_PATH" FORCE)
    endif (WIN32)
  endif (INSTALL_PATH STREQUAL "orocos")

This leads to an important limitation: once you have an orocos component in
your project, your whole project will be installed in C:\Program
Files\orocos. Is there a particular reason why this has been done so? I
would like to suggest to remove these lines:

    if (WIN32)
      set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
location as Orocos RTT." FORCE)
      mark_as_advanced(INSTALL_PATH)
      set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
install prefix forced by INSTALL_PATH" FORCE)
    endif (WIN32)

Anyways, if someone want to install in the same folder as orocos, we can
always set the INSTALL_PATH to "orocos". If this is accepted, I could bundle
this patch with the others I made for win32 some days ago.

Philippe

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by peter on Tue, 2011-06-07 20:08.

On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
<philippe [dot] hamelin [..] ...> wrote:
> Hello,
> I'm having troubles integrating some orocos components in my build system. I
> have a project with multiple targets where some are orocos components. The
> problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX to C:\Program
> Files\orocos. Here is the problematic snippet of the UseOROCOS-RTT.cmake
> file:
>

>   # Detect user flag: install with orocos
>   if (INSTALL_PATH STREQUAL "orocos")
>     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same location
> as Orocos RTT." FORCE)
>     mark_as_advanced(INSTALL_PATH)
>     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package install
> prefix forced by INSTALL_PATH" FORCE)
>   else (INSTALL_PATH STREQUAL "orocos")
>     if (WIN32)
>       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> location as Orocos RTT." FORCE)
>       mark_as_advanced(INSTALL_PATH)
>       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> install prefix forced by INSTALL_PATH" FORCE)
>     endif (WIN32)
>   endif (INSTALL_PATH STREQUAL "orocos")
>

> This leads to an important limitation: once you have an orocos component in
> your project, your whole project will be installed in C:\Program
> Files\orocos. Is there a particular reason why this has been done so? I
> would like to suggest to remove these lines:
>

>     if (WIN32)
>       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> location as Orocos RTT." FORCE)
>       mark_as_advanced(INSTALL_PATH)
>       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> install prefix forced by INSTALL_PATH" FORCE)
>     endif (WIN32)
>

> Anyways, if someone want to install in the same folder as orocos, we can
> always set the INSTALL_PATH to "orocos". If this is accepted, I could bundle
> this patch with the others I made for win32 some days ago.
> Philippe

The rationale was/is twofold:
1. on Windows, you prefer to install all build results of Orocos MSVS
projects in program files\orocos. This eases setting up the deployment
component, plugin loader etc, since the RTT_COMPONENT_PATH is set to
that location by default
2. With orocreate-pkg and the UseOrocos.cmake macros, it's dead-easy
to create new packages and to depend on other packages (use their
headers and link with their libs).So it's feasible to split software
in multiple, smaller packages. I don't know how well this works on
Windows though...
3. To have as much as possible out-of-the-box building, the standard
path for each of these package is set to the RTT installation path,
such that no extra cmake variable needs to be set, except where to
find RTT.

That said, UseOrocos.cmake is not well tuned yet for win32 usage...so
any input/proposals is certainly welcome.

But I would prefer the default 'install with rtt' still in action, but
let it override at cmake-gui level or before you include the
useorocos.cmake file.

Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by phamelin on Wed, 2011-06-08 13:16.

2011/6/7 Peter Soetens <peter [..] ...>

> On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
> <philippe [dot] hamelin [..] ...> wrote:
> > Hello,
> > I'm having troubles integrating some orocos components in my build
> system. I
> > have a project with multiple targets where some are orocos components.
> The
> > problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX to
> C:\Program
> > Files\orocos. Here is the problematic snippet of the UseOROCOS-RTT.cmake
> > file:
> >

> >   # Detect user flag: install with orocos
> >   if (INSTALL_PATH STREQUAL "orocos")
> >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> location
> > as Orocos RTT." FORCE)
> >     mark_as_advanced(INSTALL_PATH)
> >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> install
> > prefix forced by INSTALL_PATH" FORCE)
> >   else (INSTALL_PATH STREQUAL "orocos")
> >     if (WIN32)
> >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > location as Orocos RTT." FORCE)
> >       mark_as_advanced(INSTALL_PATH)
> >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > install prefix forced by INSTALL_PATH" FORCE)
> >     endif (WIN32)
> >   endif (INSTALL_PATH STREQUAL "orocos")
> >

> > This leads to an important limitation: once you have an
> orocos component in
> > your project, your whole project will be installed in C:\Program
> > Files\orocos. Is there a particular reason why this has been done so? I
> > would like to suggest to remove these lines:
> >

> >     if (WIN32)
> >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > location as Orocos RTT." FORCE)
> >       mark_as_advanced(INSTALL_PATH)
> >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > install prefix forced by INSTALL_PATH" FORCE)
> >     endif (WIN32)
> >

> > Anyways, if someone want to install in the same folder as orocos, we can
> > always set the INSTALL_PATH to "orocos". If this is accepted, I could
> bundle
> > this patch with the others I made for win32 some days ago.
> > Philippe
>
> The rationale was/is twofold:
> 1. on Windows, you prefer to install all build results of Orocos MSVS
> projects in program files\orocos. This eases setting up the deployment
> component, plugin loader etc, since the RTT_COMPONENT_PATH is set to
> that location by default
> 2. With orocreate-pkg and the UseOrocos.cmake macros, it's dead-easy
> to create new packages and to depend on other packages (use their
> headers and link with their libs).So it's feasible to split software
> in multiple, smaller packages. I don't know how well this works on
> Windows though...
> 3. To have as much as possible out-of-the-box building, the standard
> path for each of these package is set to the RTT installation path,
> such that no extra cmake variable needs to be set, except where to
> find RTT.
>
> That said, UseOrocos.cmake is not well tuned yet for win32 usage...so
> any input/proposals is certainly welcome.
>
> But I would prefer the default 'install with rtt' still in action, but
> let it override at cmake-gui level or before you include the
> useorocos.cmake file.
>
> Peter
>

I do not agree with all of the rationales since I prefer to separate orocos
from the application-specific components. However, I can live with the
default value of 'install with rtt'. Here is the logic we could have:

  # On win32, packages install at same location as Orocos by default
  if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
ORO_DISABLE_DEFAULT_INSTALL_PATH)
    set (INSTALL_PATH "orocos")
  endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
ORO_DISABLE_DEFAULT_INSTALL_PATH)
 
  # Detect user flag: install with orocos
  if (INSTALL_PATH STREQUAL "orocos")
    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same location
as Orocos RTT." FORCE)
    mark_as_advanced(INSTALL_PATH)
    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package install
prefix forced by INSTALL_PATH" FORCE)
  endif(INSTALL_PATH STREQUAL "orocos")

Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains unchanged. On
win32, it defaults to "C:\Program Files\orocos" and someone can disable that
behavior by just defining ORO_DISABLE_DEFAULT_INSTALL_PATH. Also, I think
that the variable name INSTALL_PATH is a bit too general and may lead to
conflicts when combining orocos with other cmake projects. Would you care to
rename it to something like ORO_INSTALL_PATH? If you agree on that I will
then submit a patch.

Philippe

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by peter on Thu, 2011-06-09 11:04.

On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
> 2011/6/7 Peter Soetens <peter [..] ...>
>
> > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
> >
> > <philippe [dot] hamelin [..] ...> wrote:
> > > Hello,
> > > I'm having troubles integrating some orocos components in my build
> >
> > system. I
> >
> > > have a project with multiple targets where some are orocos components.
> >
> > The
> >
> > > problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX to
> >
> > C:\Program
> >
> > > Files\orocos. Here is the problematic snippet of the
> > > UseOROCOS-RTT.cmake file:
> > >

> > > 
> > >   # Detect user flag: install with orocos
> > >   if (INSTALL_PATH STREQUAL "orocos")
> > >   
> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > 
> > location
> > 
> > > as Orocos RTT." FORCE)
> > > 
> > >     mark_as_advanced(INSTALL_PATH)
> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > 
> > install
> > 
> > > prefix forced by INSTALL_PATH" FORCE)
> > > 
> > >   else (INSTALL_PATH STREQUAL "orocos")
> > >   
> > >     if (WIN32)
> > >     
> > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > > 
> > > location as Orocos RTT." FORCE)
> > > 
> > >       mark_as_advanced(INSTALL_PATH)
> > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > > 
> > > install prefix forced by INSTALL_PATH" FORCE)
> > > 
> > >     endif (WIN32)
> > >   
> > >   endif (INSTALL_PATH STREQUAL "orocos")
> > > 
> > >

> > > This leads to an important limitation: once you have an
> >
> > orocos component in
> >
> > > your project, your whole project will be installed in C:\Program
> > > Files\orocos. Is there a particular reason why this has been done so? I
> > > would like to suggest to remove these lines:
> > >

> > > 
> > >     if (WIN32)
> > >     
> > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > > 
> > > location as Orocos RTT." FORCE)
> > > 
> > >       mark_as_advanced(INSTALL_PATH)
> > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > > 
> > > install prefix forced by INSTALL_PATH" FORCE)
> > > 
> > >     endif (WIN32)
> > > 
> > >

> > > Anyways, if someone want to install in the same folder as orocos, we
> > > can always set the INSTALL_PATH to "orocos". If this is accepted, I
> > > could
> >
> > bundle
> >
> > > this patch with the others I made for win32 some days ago.
> > > Philippe
> >
> > The rationale was/is twofold:
> > 1. on Windows, you prefer to install all build results of Orocos MSVS
> > projects in program files\orocos. This eases setting up the deployment
> > component, plugin loader etc, since the RTT_COMPONENT_PATH is set to
> > that location by default
> > 2. With orocreate-pkg and the UseOrocos.cmake macros, it's dead-easy
> > to create new packages and to depend on other packages (use their
> > headers and link with their libs).So it's feasible to split software
> > in multiple, smaller packages. I don't know how well this works on
> > Windows though...
> > 3. To have as much as possible out-of-the-box building, the standard
> > path for each of these package is set to the RTT installation path,
> > such that no extra cmake variable needs to be set, except where to
> > find RTT.
> >
> > That said, UseOrocos.cmake is not well tuned yet for win32 usage...so
> > any input/proposals is certainly welcome.
> >
> > But I would prefer the default 'install with rtt' still in action, but
> > let it override at cmake-gui level or before you include the
> > useorocos.cmake file.
> >
> > Peter
>
> I do not agree with all of the rationales since I prefer to separate
> orocos from the application-specific components. However, I can live with
> the default value of 'install with rtt'. Here is the logic we could have:

I see your point...

>
>

>   # On win32, packages install at same location as Orocos by default
>   if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> ORO_DISABLE_DEFAULT_INSTALL_PATH)
>     set (INSTALL_PATH "orocos")
>   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> ORO_DISABLE_DEFAULT_INSTALL_PATH)
> 
>   # Detect user flag: install with orocos
>   if (INSTALL_PATH STREQUAL "orocos")
>     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> location as Orocos RTT." FORCE)
>     mark_as_advanced(INSTALL_PATH)
>     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> install prefix forced by INSTALL_PATH" FORCE)
>   endif(INSTALL_PATH STREQUAL "orocos")
>

>
> Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains unchanged. On
> win32, it defaults to "C:\Program Files\orocos" and someone can disable
> that behavior by just defining ORO_DISABLE_DEFAULT_INSTALL_PATH. Also, I
> think that the variable name INSTALL_PATH is a bit too general and may
> lead to conflicts when combining orocos with other cmake projects. Would
> you care to rename it to something like ORO_INSTALL_PATH? If you agree on
> that I will then submit a patch.

Maybe we can do even better/cleaner :-) I think part of this code exists
because at the time of writing, we were not aware of the
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT cmake variable.

What we could do is make this uniform for all platforms and write it like
this:

  # If cmake install prefix is default, use 'orocos' instead
  if(NOT DEFINED INSTALL_PATH AND CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
    set (INSTALL_PATH "orocos")
  endif()
 
  # Detect user flag: install with orocos
  if (INSTALL_PATH STREQUAL "orocos")
    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same location 
as Orocos RTT." FORCE)
    mark_as_advanced(INSTALL_PATH)
    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package install 
prefix forced by INSTALL_PATH" FORCE)
  endif(INSTALL_PATH STREQUAL "orocos")

In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH, got equal
semantics for all targets and allow to set the INSTALL_PATH variable. A next
step would be to eliminate INSTALL_PATH all together and only rely on
CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We would then take 'orocos'
as a special value:

  # If cmake install prefix is default, use 'orocos' instead
  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR CMAKE_INSTALL_PREFIX 
STREQUAL "orocos" )
    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package install 
prefix forced to RTT install prefix path." FORCE)
  endif()

We can deprecate INSTALL_PATH with some extra code but I doubt it is in use
actually, since it's undocumented.... what do you think ?

Peter

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by phamelin on Thu, 2011-06-09 13:04.

2011/6/9 Peter Soetens <peter [..] ...>

> On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
> > 2011/6/7 Peter Soetens <peter [..] ...>
> >
> > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
> > >
> > > <philippe [dot] hamelin [..] ...> wrote:
> > > > Hello,
> > > > I'm having troubles integrating some orocos components in my build
> > >
> > > system. I
> > >
> > > > have a project with multiple targets where some are orocos
> components.
> > >
> > > The
> > >
> > > > problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX to
> > >
> > > C:\Program
> > >
> > > > Files\orocos. Here is the problematic snippet of the
> > > > UseOROCOS-RTT.cmake file:
> > > >

> > > >
> > > >   # Detect user flag: install with orocos
> > > >   if (INSTALL_PATH STREQUAL "orocos")
> > > >
> > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > >
> > > location
> > >
> > > > as Orocos RTT." FORCE)
> > > >
> > > >     mark_as_advanced(INSTALL_PATH)
> > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > >
> > > install
> > >
> > > > prefix forced by INSTALL_PATH" FORCE)
> > > >
> > > >   else (INSTALL_PATH STREQUAL "orocos")
> > > >
> > > >     if (WIN32)
> > > >
> > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > > >
> > > > location as Orocos RTT." FORCE)
> > > >
> > > >       mark_as_advanced(INSTALL_PATH)
> > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> "Package
> > > >
> > > > install prefix forced by INSTALL_PATH" FORCE)
> > > >
> > > >     endif (WIN32)
> > > >
> > > >   endif (INSTALL_PATH STREQUAL "orocos")
> > > >
> > > >

> > > > This leads to an important limitation: once you have an
> > >
> > > orocos component in
> > >
> > > > your project, your whole project will be installed in C:\Program
> > > > Files\orocos. Is there a particular reason why this has been done so?
> I
> > > > would like to suggest to remove these lines:
> > > >

> > > >
> > > >     if (WIN32)
> > > >
> > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > > >
> > > > location as Orocos RTT." FORCE)
> > > >
> > > >       mark_as_advanced(INSTALL_PATH)
> > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> "Package
> > > >
> > > > install prefix forced by INSTALL_PATH" FORCE)
> > > >
> > > >     endif (WIN32)
> > > >
> > > >

> > > > Anyways, if someone want to install in the same folder as orocos, we
> > > > can always set the INSTALL_PATH to "orocos". If this is accepted, I
> > > > could
> > >
> > > bundle
> > >
> > > > this patch with the others I made for win32 some days ago.
> > > > Philippe
> > >
> > > The rationale was/is twofold:
> > > 1. on Windows, you prefer to install all build results of Orocos MSVS
> > > projects in program files\orocos. This eases setting up the deployment
> > > component, plugin loader etc, since the RTT_COMPONENT_PATH is set to
> > > that location by default
> > > 2. With orocreate-pkg and the UseOrocos.cmake macros, it's dead-easy
> > > to create new packages and to depend on other packages (use their
> > > headers and link with their libs).So it's feasible to split software
> > > in multiple, smaller packages. I don't know how well this works on
> > > Windows though...
> > > 3. To have as much as possible out-of-the-box building, the standard
> > > path for each of these package is set to the RTT installation path,
> > > such that no extra cmake variable needs to be set, except where to
> > > find RTT.
> > >
> > > That said, UseOrocos.cmake is not well tuned yet for win32 usage...so
> > > any input/proposals is certainly welcome.
> > >
> > > But I would prefer the default 'install with rtt' still in action, but
> > > let it override at cmake-gui level or before you include the
> > > useorocos.cmake file.
> > >
> > > Peter
> >
> > I do not agree with all of the rationales since I prefer to separate
> > orocos from the application-specific components. However, I can live with
> > the default value of 'install with rtt'. Here is the logic we could have:
>
> I see your point...
>
> >
> >

> >   # On win32, packages install at same location as Orocos by default
> >   if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> >     set (INSTALL_PATH "orocos")
> >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> >
> >   # Detect user flag: install with orocos
> >   if (INSTALL_PATH STREQUAL "orocos")
> >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > location as Orocos RTT." FORCE)
> >     mark_as_advanced(INSTALL_PATH)
> >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > install prefix forced by INSTALL_PATH" FORCE)
> >   endif(INSTALL_PATH STREQUAL "orocos")
> >

> >
> > Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains unchanged. On
> > win32, it defaults to "C:\Program Files\orocos" and someone can disable
> > that behavior by just defining ORO_DISABLE_DEFAULT_INSTALL_PATH. Also, I
> > think that the variable name INSTALL_PATH is a bit too general and may
> > lead to conflicts when combining orocos with other cmake projects. Would
> > you care to rename it to something like ORO_INSTALL_PATH? If you agree on
> > that I will then submit a patch.
>
> Maybe we can do even better/cleaner :-) I think part of this code exists
> because at the time of writing, we were not aware of the
> CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT cmake variable.
>
> What we could do is make this uniform for all platforms and write it like
> this:
>
>

>  # If cmake install prefix is default, use 'orocos' instead
>  if(NOT DEFINED INSTALL_PATH AND
> CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>    set (INSTALL_PATH "orocos")
>  endif()
>
>  # Detect user flag: install with orocos
>  if (INSTALL_PATH STREQUAL "orocos")
>    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same location
> as Orocos RTT." FORCE)
>    mark_as_advanced(INSTALL_PATH)
>    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package install
> prefix forced by INSTALL_PATH" FORCE)
>  endif(INSTALL_PATH STREQUAL "orocos")
>

>
> In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH, got equal
> semantics for all targets and allow to set the INSTALL_PATH variable. A
> next
> step would be to eliminate INSTALL_PATH all together and only rely on
> CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We would then take
> 'orocos'
> as a special value:
>
>

>  # If cmake install prefix is default, use 'orocos' instead
>  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR CMAKE_INSTALL_PREFIX
> STREQUAL "orocos" )
>     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> install
> prefix forced to RTT install prefix path." FORCE)
>  endif()
>

>
> We can deprecate INSTALL_PATH with some extra code but I doubt it is in use
> actually, since it's undocumented.... what do you think ?
>
>
I also prefer to remove the INSTALL_PATH variable. However, the problem is
that I want to use the CMake default, which is C:\Program
Files< x86>\${PROJET_NAME}. In that case,
the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable is set and the
proposed logic won't work. There is two reasons why I want to use the
default:

1. It installs in a subfolder with the ${PROJECT_NAME} suffix
2. It has the logic to select either C:\Program Files\${PROJECT_NAME}
or C:\Program Files (x86)\${PROJECT_NAME}

One workaround would be to set the CMAKE_INSTALL_PREFIX in the
CMakeLists.txt before calling the project() macro so
the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not set. However, I must
admit I really don't like this one because I would have to recode the CMake
logic to detect if I have to install in C:\Program Files\[...] or C:\Program
Files (x86)\[...]. There is a macro for that in CMake 2.8.3 that I could
use, but I would prefer to let CMake make the choice and then be compatible
with older versions of CMake.

The other workaround, which is more portable, would be to unset
the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT just after the project()
macro. Then, it will use the default CMAKE_INSTALL_PREFIX but the orocos
macros will think it's a custom value. What do you think about that?

Philippe

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by snrkiwi on Thu, 2011-06-09 13:12.

On Jun 9, 2011, at 09:03 , Philippe Hamelin wrote:

> 2011/6/9 Peter Soetens <peter [..] ...>
> On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
> > 2011/6/7 Peter Soetens <peter [..] ...>
> >
> > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
> > >
> > > <philippe [dot] hamelin [..] ...> wrote:
> > > > Hello,
> > > > I'm having troubles integrating some orocos components in my build
> > >
> > > system. I
> > >
> > > > have a project with multiple targets where some are orocos components.
> > >
> > > The
> > >
> > > > problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX to
> > >
> > > C:\Program
> > >
> > > > Files\orocos. Here is the problematic snippet of the
> > > > UseOROCOS-RTT.cmake file:
> > > >

> > > >
> > > >   # Detect user flag: install with orocos
> > > >   if (INSTALL_PATH STREQUAL "orocos")
> > > >
> > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > >
> > > location
> > >
> > > > as Orocos RTT." FORCE)
> > > >
> > > >     mark_as_advanced(INSTALL_PATH)
> > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > >
> > > install
> > >
> > > > prefix forced by INSTALL_PATH" FORCE)
> > > >
> > > >   else (INSTALL_PATH STREQUAL "orocos")
> > > >
> > > >     if (WIN32)
> > > >
> > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > > >
> > > > location as Orocos RTT." FORCE)
> > > >
> > > >       mark_as_advanced(INSTALL_PATH)
> > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > > >
> > > > install prefix forced by INSTALL_PATH" FORCE)
> > > >
> > > >     endif (WIN32)
> > > >
> > > >   endif (INSTALL_PATH STREQUAL "orocos")
> > > >
> > > >

> > > > This leads to an important limitation: once you have an
> > >
> > > orocos component in
> > >
> > > > your project, your whole project will be installed in C:\Program
> > > > Files\orocos. Is there a particular reason why this has been done so? I
> > > > would like to suggest to remove these lines:
> > > >

> > > >
> > > >     if (WIN32)
> > > >
> > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > > >
> > > > location as Orocos RTT." FORCE)
> > > >
> > > >       mark_as_advanced(INSTALL_PATH)
> > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > > >
> > > > install prefix forced by INSTALL_PATH" FORCE)
> > > >
> > > >     endif (WIN32)
> > > >
> > > >

> >   # On win32, packages install at same location as Orocos by default
> >   if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> >     set (INSTALL_PATH "orocos")
> >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> >
> >   # Detect user flag: install with orocos
> >   if (INSTALL_PATH STREQUAL "orocos")
> >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > location as Orocos RTT." FORCE)
> >     mark_as_advanced(INSTALL_PATH)
> >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > install prefix forced by INSTALL_PATH" FORCE)
> >   endif(INSTALL_PATH STREQUAL "orocos")
> >

>  # If cmake install prefix is default, use 'orocos' instead
>  if(NOT DEFINED INSTALL_PATH AND CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>    set (INSTALL_PATH "orocos")
>  endif()
> 
>  # Detect user flag: install with orocos
>  if (INSTALL_PATH STREQUAL "orocos")
>    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same location
> as Orocos RTT." FORCE)
>    mark_as_advanced(INSTALL_PATH)
>    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package install
> prefix forced by INSTALL_PATH" FORCE)
>  endif(INSTALL_PATH STREQUAL "orocos")
>

>
> In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH, got equal
> semantics for all targets and allow to set the INSTALL_PATH variable. A next
> step would be to eliminate INSTALL_PATH all together and only rely on
> CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We would then take 'orocos'
> as a special value:
>
>

>  # If cmake install prefix is default, use 'orocos' instead
>  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR CMAKE_INSTALL_PREFIX
> STREQUAL "orocos" )
>    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package install
> prefix forced to RTT install prefix path." FORCE)
>  endif()
>

>
> We can deprecate INSTALL_PATH with some extra code but I doubt it is in use
> actually, since it's undocumented.... what do you think ?
>
>
>
> I also prefer to remove the INSTALL_PATH variable. However, the problem is that I want to use the CMake default, which is C:\Program Files< x86>\${PROJET_NAME}. In that case, the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable is set and the proposed logic won't work. There is two reasons why I want to use the default:
>
> 1. It installs in a subfolder with the ${PROJECT_NAME} suffix
> 2. It has the logic to select either C:\Program Files\${PROJECT_NAME} or C:\Program Files (x86)\${PROJECT_NAME}
>
> One workaround would be to set the CMAKE_INSTALL_PREFIX in the CMakeLists.txt before calling the project() macro so the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not set. However, I must admit I really don't like this one because I would have to recode the CMake logic to detect if I have to install in C:\Program Files\[...] or C:\Program Files (x86)\[...]. There is a macro for that in CMake 2.8.3 that I could use, but I would prefer to let CMake make the choice and then be compatible with older versions of CMake.

Are we just trying to support
- a default INSTALL location it none given
- a method for the user to override the default INSTALL location if none given (and optionally just use the CMake default)
- (?) a method for the user to force the INSTALL location

And this has to work on all supported platforms, or are you trying to do the above just for Windows?

> The other workaround, which is more portable, would be to unset the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT just after the project() macro. Then, it will use the default CMAKE_INSTALL_PREFIX but the orocos macros will think it's a custom value. What do you think about that?

Which would break standard CMake behaviour, making it hard for other people to figure out what is going on. I would not want that as a project-wide default.
S

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by phamelin on Thu, 2011-06-09 14:28.

2011/6/9 S Roderick <kiwi [dot] net [..] ...>

> On Jun 9, 2011, at 09:03 , Philippe Hamelin wrote:
>
> > 2011/6/9 Peter Soetens <peter [..] ...>
> > On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
> > > 2011/6/7 Peter Soetens <peter [..] ...>
> > >
> > > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
> > > >
> > > > <philippe [dot] hamelin [..] ...> wrote:
> > > > > Hello,
> > > > > I'm having troubles integrating some orocos components in my build
> > > >
> > > > system. I
> > > >
> > > > > have a project with multiple targets where some are orocos
> components.
> > > >
> > > > The
> > > >
> > > > > problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX to
> > > >
> > > > C:\Program
> > > >
> > > > > Files\orocos. Here is the problematic snippet of the
> > > > > UseOROCOS-RTT.cmake file:
> > > > >

> > > > >
> > > > >   # Detect user flag: install with orocos
> > > > >   if (INSTALL_PATH STREQUAL "orocos")
> > > > >
> > > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > > >
> > > > location
> > > >
> > > > > as Orocos RTT." FORCE)
> > > > >
> > > > >     mark_as_advanced(INSTALL_PATH)
> > > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> "Package
> > > >
> > > > install
> > > >
> > > > > prefix forced by INSTALL_PATH" FORCE)
> > > > >
> > > > >   else (INSTALL_PATH STREQUAL "orocos")
> > > > >
> > > > >     if (WIN32)
> > > > >
> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> same
> > > > >
> > > > > location as Orocos RTT." FORCE)
> > > > >
> > > > >       mark_as_advanced(INSTALL_PATH)
> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> "Package
> > > > >
> > > > > install prefix forced by INSTALL_PATH" FORCE)
> > > > >
> > > > >     endif (WIN32)
> > > > >
> > > > >   endif (INSTALL_PATH STREQUAL "orocos")
> > > > >
> > > > >

> > > > > This leads to an important limitation: once you have an
> > > >
> > > > orocos component in
> > > >
> > > > > your project, your whole project will be installed in C:\Program
> > > > > Files\orocos. Is there a particular reason why this has been done
> so? I
> > > > > would like to suggest to remove these lines:
> > > > >

> > > > >
> > > > >     if (WIN32)
> > > > >
> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> same
> > > > >
> > > > > location as Orocos RTT." FORCE)
> > > > >
> > > > >       mark_as_advanced(INSTALL_PATH)
> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> "Package
> > > > >
> > > > > install prefix forced by INSTALL_PATH" FORCE)
> > > > >
> > > > >     endif (WIN32)
> > > > >
> > > > >

> > > > > Anyways, if someone want to install in the same folder as orocos,
> we
> > > > > can always set the INSTALL_PATH to "orocos". If this is accepted, I
> > > > > could
> > > >
> > > > bundle
> > > >
> > > > > this patch with the others I made for win32 some days ago.
> > > > > Philippe
> > > >
> > > > The rationale was/is twofold:
> > > > 1. on Windows, you prefer to install all build results of Orocos MSVS
> > > > projects in program files\orocos. This eases setting up the
> deployment
> > > > component, plugin loader etc, since the RTT_COMPONENT_PATH is set to
> > > > that location by default
> > > > 2. With orocreate-pkg and the UseOrocos.cmake macros, it's dead-easy
> > > > to create new packages and to depend on other packages (use their
> > > > headers and link with their libs).So it's feasible to split software
> > > > in multiple, smaller packages. I don't know how well this works on
> > > > Windows though...
> > > > 3. To have as much as possible out-of-the-box building, the standard
> > > > path for each of these package is set to the RTT installation path,
> > > > such that no extra cmake variable needs to be set, except where to
> > > > find RTT.
> > > >
> > > > That said, UseOrocos.cmake is not well tuned yet for win32 usage...so
> > > > any input/proposals is certainly welcome.
> > > >
> > > > But I would prefer the default 'install with rtt' still in action,
> but
> > > > let it override at cmake-gui level or before you include the
> > > > useorocos.cmake file.
> > > >
> > > > Peter
> > >
> > > I do not agree with all of the rationales since I prefer to separate
> > > orocos from the application-specific components. However, I can live
> with
> > > the default value of 'install with rtt'. Here is the logic we could
> have:
> >
> > I see your point...
> >
> > >
> > >

> > >   # On win32, packages install at same location as Orocos by default
> > >   if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> > >     set (INSTALL_PATH "orocos")
> > >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> > >
> > >   # Detect user flag: install with orocos
> > >   if (INSTALL_PATH STREQUAL "orocos")
> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > > location as Orocos RTT." FORCE)
> > >     mark_as_advanced(INSTALL_PATH)
> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > > install prefix forced by INSTALL_PATH" FORCE)
> > >   endif(INSTALL_PATH STREQUAL "orocos")
> > >

> > >
> > > Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains unchanged. On
> > > win32, it defaults to "C:\Program Files\orocos" and someone can disable
> > > that behavior by just defining ORO_DISABLE_DEFAULT_INSTALL_PATH. Also,
> I
> > > think that the variable name INSTALL_PATH is a bit too general and may
> > > lead to conflicts when combining orocos with other cmake projects.
> Would
> > > you care to rename it to something like ORO_INSTALL_PATH? If you agree
> on
> > > that I will then submit a patch.
> >
> > Maybe we can do even better/cleaner :-) I think part of this code exists
> > because at the time of writing, we were not aware of the
> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT cmake variable.
> >
> > What we could do is make this uniform for all platforms and write it like
> > this:
> >
> >

> >  # If cmake install prefix is default, use 'orocos' instead
> >  if(NOT DEFINED INSTALL_PATH AND
> CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> >    set (INSTALL_PATH "orocos")
> >  endif()
> >
> >  # Detect user flag: install with orocos
> >  if (INSTALL_PATH STREQUAL "orocos")
> >    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> location
> > as Orocos RTT." FORCE)
> >    mark_as_advanced(INSTALL_PATH)
> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> install
> > prefix forced by INSTALL_PATH" FORCE)
> >  endif(INSTALL_PATH STREQUAL "orocos")
> >

> >
> > In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH, got equal
> > semantics for all targets and allow to set the INSTALL_PATH variable. A
> next
> > step would be to eliminate INSTALL_PATH all together and only rely on
> > CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We would then take
> 'orocos'
> > as a special value:
> >
> >

> >  # If cmake install prefix is default, use 'orocos' instead
> >  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR CMAKE_INSTALL_PREFIX
> > STREQUAL "orocos" )
> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> install
> > prefix forced to RTT install prefix path." FORCE)
> >  endif()
> >

> >
> > We can deprecate INSTALL_PATH with some extra code but I doubt it is in
> use
> > actually, since it's undocumented.... what do you think ?
> >
> >
> >
> > I also prefer to remove the INSTALL_PATH variable. However, the problem
> is that I want to use the CMake default, which is C:\Program Files<
> x86>\${PROJET_NAME}. In that case, the
> CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable is set and the proposed
> logic won't work. There is two reasons why I want to use the default:
> >
> > 1. It installs in a subfolder with the ${PROJECT_NAME} suffix
> > 2. It has the logic to select either C:\Program Files\${PROJECT_NAME} or
> C:\Program Files (x86)\${PROJECT_NAME}
> >
> > One workaround would be to set the CMAKE_INSTALL_PREFIX in the
> CMakeLists.txt before calling the project() macro so the
> CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not set. However, I must
> admit I really don't like this one because I would have to recode the CMake
> logic to detect if I have to install in C:\Program Files\[...] or C:\Program
> Files (x86)\[...]. There is a macro for that in CMake 2.8.3 that I could
> use, but I would prefer to let CMake make the choice and then be compatible
> with older versions of CMake.
>
> Are we just trying to support
> - a default INSTALL location it none given
>

Yes

> - a method for the user to override the default INSTALL location if none
> given (and optionally just use the CMake default)
>

Yes

> - (?) a method for the user to force the INSTALL location
>
> And this has to work on all supported platforms, or are you trying to do
> the above just for Windows?
>
>
The current logic only forces the install path on Windows, but I think it's
a good idea to have a common logic for all platforms. The install prefix on
Linux is /usr/local by default anyways, so it should not break anything. On
windows, the project name is appended so this is more complex.

> > The other workaround, which is more portable, would be to unset the
> CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT just after the project() macro.
> Then, it will use the default CMAKE_INSTALL_PREFIX but the orocos macros
> will think it's a custom value. What do you think about that?
>
> Which would break standard CMake behaviour, making it hard for other people
> to figure out what is going on. I would not want that as a project-wide
> default.
>
>
I agree that this is a hack and it may breaks other cmake logic inside
projects.

I think we will need to keep an additionnal CMake variable to configure the
install path. How about this logic:

# The user should set the variable ORO_INSTALL_PREFIX to force the
installation prefix of orocos components/plugins/...
# If none is given, then the ORO_INSTALL_PREFIX is set to
CMAKE_INSTALL_PREFIX if it's non-default
# If both ORO_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX are not explicitly
set, the installation prefix
# is set to the Orocos-RTT directory.
if(NOT ORO_INSTALL_PREFIX)
  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
    set(ORO_INSTALL_PREFIX "orocos")
  else(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
    set(ORO_INSTALL_PREFIX CMAKE_PREFIX_PATH)
  endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
endif(NOT ORO_INSTALL_PREFIX)
 
# Check for special case of ORO_INSTALL_PATH="orocos"
if(ORO_INSTALL_PREFIX STREQUAL "orocos")
   set (ORO_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package installs
at same location as Orocos RTT." FORCE)
   mark_as_advanced(ORO_INSTALL_PATH)
endif(ORO_INSTALL_PREFIX STREQUAL "orocos")

I think we should not override the CMAKE_INSTALL_PREFIX variable since it
can break many things in other cmake projects. That's why I propose that the
UseOROCOS-RTT macros should now use ORO_INSTALL_PATH to configure the full
install paths instead of using the CMAKE_INSTALL_PREFIX.

Philippe

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by peter on Thu, 2011-06-09 17:52.

On Thu, Jun 9, 2011 at 4:26 PM, Philippe Hamelin
<philippe [dot] hamelin [..] ...> wrote:
> 2011/6/9 S Roderick <kiwi [dot] net [..] ...>
>>
>> On Jun 9, 2011, at 09:03 , Philippe Hamelin wrote:
>>
>> > 2011/6/9 Peter Soetens <peter [..] ...>
>> > On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
>> > > 2011/6/7 Peter Soetens <peter [..] ...>
>> > >
>> > > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
>> > > >
>> > > > <philippe [dot] hamelin [..] ...> wrote:
>> > > > > Hello,
>> > > > > I'm having troubles integrating some orocos components in my build
>> > > >
>> > > > system. I
>> > > >
>> > > > > have a project with multiple targets where some are orocos
>> > > > > components.
>> > > >
>> > > > The
>> > > >
>> > > > > problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX to
>> > > >
>> > > > C:\Program
>> > > >
>> > > > > Files\orocos. Here is the problematic snippet of the
>> > > > > UseOROCOS-RTT.cmake file:
>> > > > >

>> > > > >
>> > > > >   # Detect user flag: install with orocos
>> > > > >   if (INSTALL_PATH STREQUAL "orocos")
>> > > > >
>> > > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
>> > > > > same
>> > > >
>> > > > location
>> > > >
>> > > > > as Orocos RTT." FORCE)
>> > > > >
>> > > > >     mark_as_advanced(INSTALL_PATH)
>> > > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> > > > > "Package
>> > > >
>> > > > install
>> > > >
>> > > > > prefix forced by INSTALL_PATH" FORCE)
>> > > > >
>> > > > >   else (INSTALL_PATH STREQUAL "orocos")
>> > > > >
>> > > > >     if (WIN32)
>> > > > >
>> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
>> > > > > same
>> > > > >
>> > > > > location as Orocos RTT." FORCE)
>> > > > >
>> > > > >       mark_as_advanced(INSTALL_PATH)
>> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> > > > > "Package
>> > > > >
>> > > > > install prefix forced by INSTALL_PATH" FORCE)
>> > > > >
>> > > > >     endif (WIN32)
>> > > > >
>> > > > >   endif (INSTALL_PATH STREQUAL "orocos")
>> > > > >
>> > > > >

>> > > > > This leads to an important limitation: once you have an
>> > > >
>> > > > orocos component in
>> > > >
>> > > > > your project, your whole project will be installed in C:\Program
>> > > > > Files\orocos. Is there a particular reason why this has been done
>> > > > > so? I
>> > > > > would like to suggest to remove these lines:
>> > > > >

>> > > > >
>> > > > >     if (WIN32)
>> > > > >
>> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
>> > > > > same
>> > > > >
>> > > > > location as Orocos RTT." FORCE)
>> > > > >
>> > > > >       mark_as_advanced(INSTALL_PATH)
>> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> > > > > "Package
>> > > > >
>> > > > > install prefix forced by INSTALL_PATH" FORCE)
>> > > > >
>> > > > >     endif (WIN32)
>> > > > >
>> > > > >

>> > > > > Anyways, if someone want to install in the same folder as orocos,
>> > > > > we
>> > > > > can always set the INSTALL_PATH to "orocos". If this is accepted,
>> > > > > I
>> > > > > could
>> > > >
>> > > > bundle
>> > > >
>> > > > > this patch with the others I made for win32 some days ago.
>> > > > > Philippe
>> > > >
>> > > > The rationale was/is twofold:
>> > > > 1. on Windows, you prefer to install all build results of Orocos
>> > > > MSVS
>> > > > projects in program files\orocos. This eases setting up the
>> > > > deployment
>> > > > component, plugin loader etc, since the RTT_COMPONENT_PATH is set to
>> > > > that location by default
>> > > > 2. With orocreate-pkg and the UseOrocos.cmake macros, it's dead-easy
>> > > > to create new packages and to depend on other packages (use their
>> > > > headers and link with their libs).So it's feasible to split software
>> > > > in multiple, smaller packages. I don't know how well this works on
>> > > > Windows though...
>> > > > 3. To have as much as possible out-of-the-box building, the standard
>> > > > path for each of these package is set to the RTT installation path,
>> > > > such that no extra cmake variable needs to be set, except where to
>> > > > find RTT.
>> > > >
>> > > > That said, UseOrocos.cmake is not well tuned yet for win32
>> > > > usage...so
>> > > > any input/proposals is certainly welcome.
>> > > >
>> > > > But I would prefer the default 'install with rtt' still in action,
>> > > > but
>> > > > let it override at cmake-gui level or before you include the
>> > > > useorocos.cmake file.
>> > > >
>> > > > Peter
>> > >
>> > > I do not agree with all of the rationales since I prefer to separate
>> > > orocos from the application-specific components. However, I can live
>> > > with
>> > > the default value of 'install with rtt'. Here is the logic we could
>> > > have:
>> >
>> > I see your point...
>> >
>> > >
>> > >

>> > >   # On win32, packages install at same location as Orocos by default
>> > >   if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
>> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
>> > >     set (INSTALL_PATH "orocos")
>> > >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
>> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
>> > >
>> > >   # Detect user flag: install with orocos
>> > >   if (INSTALL_PATH STREQUAL "orocos")
>> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
>> > > location as Orocos RTT." FORCE)
>> > >     mark_as_advanced(INSTALL_PATH)
>> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
>> > > install prefix forced by INSTALL_PATH" FORCE)
>> > >   endif(INSTALL_PATH STREQUAL "orocos")
>> > >

>> > >
>> > > Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains unchanged.
>> > > On
>> > > win32, it defaults to "C:\Program Files\orocos" and someone can
>> > > disable
>> > > that behavior by just defining ORO_DISABLE_DEFAULT_INSTALL_PATH. Also,
>> > > I
>> > > think that the variable name INSTALL_PATH is a bit too general and may
>> > > lead to conflicts when combining orocos with other cmake projects.
>> > > Would
>> > > you care to rename it to something like ORO_INSTALL_PATH? If you agree
>> > > on
>> > > that I will then submit a patch.
>> >
>> > Maybe we can do even better/cleaner :-) I think part of this code exists
>> > because at the time of writing, we were not aware of the
>> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT cmake variable.
>> >
>> > What we could do is make this uniform for all platforms and write it
>> > like
>> > this:
>> >
>> >

>> >  # If cmake install prefix is default, use 'orocos' instead
>> >  if(NOT DEFINED INSTALL_PATH AND
>> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> >    set (INSTALL_PATH "orocos")
>> >  endif()
>> >
>> >  # Detect user flag: install with orocos
>> >  if (INSTALL_PATH STREQUAL "orocos")
>> >    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
>> > location
>> > as Orocos RTT." FORCE)
>> >    mark_as_advanced(INSTALL_PATH)
>> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
>> > install
>> > prefix forced by INSTALL_PATH" FORCE)
>> >  endif(INSTALL_PATH STREQUAL "orocos")
>> >

>> >
>> > In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH, got
>> > equal
>> > semantics for all targets and allow to set the INSTALL_PATH variable. A
>> > next
>> > step would be to eliminate INSTALL_PATH all together and only rely on
>> > CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We would then take
>> > 'orocos'
>> > as a special value:
>> >
>> >

>> >  # If cmake install prefix is default, use 'orocos' instead
>> >  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR CMAKE_INSTALL_PREFIX
>> > STREQUAL "orocos" )
>> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
>> > install
>> > prefix forced to RTT install prefix path." FORCE)
>> >  endif()
>> >

>> >
>> > We can deprecate INSTALL_PATH with some extra code but I doubt it is in
>> > use
>> > actually, since it's undocumented.... what do you think ?
>> >
>> >
>> >
>> > I also prefer to remove the INSTALL_PATH variable. However, the problem
>> > is that I want to use the CMake default, which is C:\Program Files<
>> > x86>\${PROJET_NAME}. In that case, the
>> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable is set and the proposed
>> > logic won't work. There is two reasons why I want to use the default:
>> >
>> > 1. It installs in a subfolder with the ${PROJECT_NAME} suffix
>> > 2. It has the logic to select either C:\Program Files\${PROJECT_NAME} or
>> > C:\Program Files (x86)\${PROJECT_NAME}
>> >
>> > One workaround would be to set the CMAKE_INSTALL_PREFIX in the
>> > CMakeLists.txt before calling the project() macro so the
>> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not set. However, I must
>> > admit I really don't like this one because I would have to recode the CMake
>> > logic to detect if I have to install in C:\Program Files\[...] or C:\Program
>> > Files (x86)\[...]. There is a macro for that in CMake 2.8.3 that I could
>> > use, but I would prefer to let CMake make the choice and then be compatible
>> > with older versions of CMake.
>>
>> Are we just trying to support
>> - a default INSTALL location it none given
>
> Yes
>
>>
>> - a method for the user to override the default INSTALL location if none
>> given (and optionally just use the CMake default)
>
> Yes
>
>>
>> - (?) a method for the user to force the INSTALL location
>>
>> And this has to work on all supported platforms, or are you trying to do
>> the above just for Windows?
>>
>
> The current logic only forces the install path on Windows, but I think it's
> a good idea to have a common logic for all platforms. The install prefix on
> Linux is /usr/local by default anyways, so it should not break anything. On
> windows, the project name is appended so this is more complex.
>
>>
>> > The other workaround, which is more portable, would be to unset the
>> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT just after the project() macro.
>> > Then, it will use the default CMAKE_INSTALL_PREFIX but the orocos macros
>> > will think it's a custom value. What do you think about that?
>>
>> Which would break standard CMake behaviour, making it hard for other
>> people to figure out what is going on. I would not want that as a
>> project-wide default.
>>
>
> I agree that this is a hack and it may breaks other cmake logic inside
> projects.
> I think we will need to keep an additionnal CMake variable to configure the
> install path. How about this logic:
>

> # The user should set the variable ORO_INSTALL_PREFIX to force the
> installation prefix of orocos components/plugins/...
> # If none is given, then the ORO_INSTALL_PREFIX is set to
> CMAKE_INSTALL_PREFIX if it's non-default
> # If both ORO_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX are not explicitly
> set, the installation prefix
> # is set to the Orocos-RTT directory.
> if(NOT ORO_INSTALL_PREFIX)
>   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>     set(ORO_INSTALL_PREFIX "orocos")
>   else(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>     set(ORO_INSTALL_PREFIX CMAKE_PREFIX_PATH)
>   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> endif(NOT ORO_INSTALL_PREFIX)
> # Check for special case of ORO_INSTALL_PATH="orocos"
> if(ORO_INSTALL_PREFIX STREQUAL "orocos")
>    set (ORO_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package installs
> at same location as Orocos RTT." FORCE)
>    mark_as_advanced(ORO_INSTALL_PATH)
 
typo here: ORO_INSTALL_PATH
 
> endif(ORO_INSTALL_PREFIX STREQUAL "orocos")
>

> I think we should not override the CMAKE_INSTALL_PREFIX variable since it
> can break many things in other cmake projects. That's why I propose that the
> UseOROCOS-RTT macros should now use ORO_INSTALL_PATH to configure the full
> install paths instead of using the CMAKE_INSTALL_PREFIX.

I agree fully with your proposal. However, it will also require
updates to all the other orocos_
macros such that they use ORO_INSTALL_PREFIX instead of CMAKE_INSTALL_PREFIX

Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by phamelin on Tue, 2011-06-14 07:28.

2011/6/9 Peter Soetens <peter [..] ...>

> On Thu, Jun 9, 2011 at 4:26 PM, Philippe Hamelin
> <philippe [dot] hamelin [..] ...> wrote:
> > 2011/6/9 S Roderick <kiwi [dot] net [..] ...>
> >>
> >> On Jun 9, 2011, at 09:03 , Philippe Hamelin wrote:
> >>
> >> > 2011/6/9 Peter Soetens <peter [..] ...>
> >> > On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
> >> > > 2011/6/7 Peter Soetens <peter [..] ...>
> >> > >
> >> > > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
> >> > > >
> >> > > > <philippe [dot] hamelin [..] ...> wrote:
> >> > > > > Hello,
> >> > > > > I'm having troubles integrating some orocos components in my
> build
> >> > > >
> >> > > > system. I
> >> > > >
> >> > > > > have a project with multiple targets where some are orocos
> >> > > > > components.
> >> > > >
> >> > > > The
> >> > > >
> >> > > > > problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX
> to
> >> > > >
> >> > > > C:\Program
> >> > > >
> >> > > > > Files\orocos. Here is the problematic snippet of the
> >> > > > > UseOROCOS-RTT.cmake file:
> >> > > > >

> >> > > > >
> >> > > > >   # Detect user flag: install with orocos
> >> > > > >   if (INSTALL_PATH STREQUAL "orocos")
> >> > > > >
> >> > > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> >> > > > > same
> >> > > >
> >> > > > location
> >> > > >
> >> > > > > as Orocos RTT." FORCE)
> >> > > > >
> >> > > > >     mark_as_advanced(INSTALL_PATH)
> >> > > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> >> > > > > "Package
> >> > > >
> >> > > > install
> >> > > >
> >> > > > > prefix forced by INSTALL_PATH" FORCE)
> >> > > > >
> >> > > > >   else (INSTALL_PATH STREQUAL "orocos")
> >> > > > >
> >> > > > >     if (WIN32)
> >> > > > >
> >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> >> > > > > same
> >> > > > >
> >> > > > > location as Orocos RTT." FORCE)
> >> > > > >
> >> > > > >       mark_as_advanced(INSTALL_PATH)
> >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> >> > > > > "Package
> >> > > > >
> >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> >> > > > >
> >> > > > >     endif (WIN32)
> >> > > > >
> >> > > > >   endif (INSTALL_PATH STREQUAL "orocos")
> >> > > > >
> >> > > > >

> >> > > > > This leads to an important limitation: once you have an
> >> > > >
> >> > > > orocos component in
> >> > > >
> >> > > > > your project, your whole project will be installed in C:\Program
> >> > > > > Files\orocos. Is there a particular reason why this has been
> done
> >> > > > > so? I
> >> > > > > would like to suggest to remove these lines:
> >> > > > >

> >> > > > >
> >> > > > >     if (WIN32)
> >> > > > >
> >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> >> > > > > same
> >> > > > >
> >> > > > > location as Orocos RTT." FORCE)
> >> > > > >
> >> > > > >       mark_as_advanced(INSTALL_PATH)
> >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> >> > > > > "Package
> >> > > > >
> >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> >> > > > >
> >> > > > >     endif (WIN32)
> >> > > > >
> >> > > > >

> >> > > > > Anyways, if someone want to install in the same folder as
> orocos,
> >> > > > > we
> >> > > > > can always set the INSTALL_PATH to "orocos". If this is
> accepted,
> >> > > > > I
> >> > > > > could
> >> > > >
> >> > > > bundle
> >> > > >
> >> > > > > this patch with the others I made for win32 some days ago.
> >> > > > > Philippe
> >> > > >
> >> > > > The rationale was/is twofold:
> >> > > > 1. on Windows, you prefer to install all build results of Orocos
> >> > > > MSVS
> >> > > > projects in program files\orocos. This eases setting up the
> >> > > > deployment
> >> > > > component, plugin loader etc, since the RTT_COMPONENT_PATH is set
> to
> >> > > > that location by default
> >> > > > 2. With orocreate-pkg and the UseOrocos.cmake macros, it's
> dead-easy
> >> > > > to create new packages and to depend on other packages (use their
> >> > > > headers and link with their libs).So it's feasible to split
> software
> >> > > > in multiple, smaller packages. I don't know how well this works on
> >> > > > Windows though...
> >> > > > 3. To have as much as possible out-of-the-box building, the
> standard
> >> > > > path for each of these package is set to the RTT installation
> path,
> >> > > > such that no extra cmake variable needs to be set, except where to
> >> > > > find RTT.
> >> > > >
> >> > > > That said, UseOrocos.cmake is not well tuned yet for win32
> >> > > > usage...so
> >> > > > any input/proposals is certainly welcome.
> >> > > >
> >> > > > But I would prefer the default 'install with rtt' still in action,
> >> > > > but
> >> > > > let it override at cmake-gui level or before you include the
> >> > > > useorocos.cmake file.
> >> > > >
> >> > > > Peter
> >> > >
> >> > > I do not agree with all of the rationales since I prefer to
> separate
> >> > > orocos from the application-specific components. However, I can live
> >> > > with
> >> > > the default value of 'install with rtt'. Here is the logic we could
> >> > > have:
> >> >
> >> > I see your point...
> >> >
> >> > >
> >> > >

> >> > >   # On win32, packages install at same location as Orocos by default
> >> > >   if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> >> > >     set (INSTALL_PATH "orocos")
> >> > >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> >> > >
> >> > >   # Detect user flag: install with orocos
> >> > >   if (INSTALL_PATH STREQUAL "orocos")
> >> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> >> > > location as Orocos RTT." FORCE)
> >> > >     mark_as_advanced(INSTALL_PATH)
> >> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> >> > > install prefix forced by INSTALL_PATH" FORCE)
> >> > >   endif(INSTALL_PATH STREQUAL "orocos")
> >> > >

> >> > >
> >> > > Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains unchanged.
> >> > > On
> >> > > win32, it defaults to "C:\Program Files\orocos" and someone can
> >> > > disable
> >> > > that behavior by just defining ORO_DISABLE_DEFAULT_INSTALL_PATH.
> Also,
> >> > > I
> >> > > think that the variable name INSTALL_PATH is a bit too general and
> may
> >> > > lead to conflicts when combining orocos with other cmake projects.
> >> > > Would
> >> > > you care to rename it to something like ORO_INSTALL_PATH? If you
> agree
> >> > > on
> >> > > that I will then submit a patch.
> >> >
> >> > Maybe we can do even better/cleaner :-) I think part of this code
> exists
> >> > because at the time of writing, we were not aware of the
> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT cmake variable.
> >> >
> >> > What we could do is make this uniform for all platforms and write it
> >> > like
> >> > this:
> >> >
> >> >

> >> >  # If cmake install prefix is default, use 'orocos' instead
> >> >  if(NOT DEFINED INSTALL_PATH AND
> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> >> >    set (INSTALL_PATH "orocos")
> >> >  endif()
> >> >
> >> >  # Detect user flag: install with orocos
> >> >  if (INSTALL_PATH STREQUAL "orocos")
> >> >    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> >> > location
> >> > as Orocos RTT." FORCE)
> >> >    mark_as_advanced(INSTALL_PATH)
> >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> >> > install
> >> > prefix forced by INSTALL_PATH" FORCE)
> >> >  endif(INSTALL_PATH STREQUAL "orocos")
> >> >

> >> >
> >> > In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH, got
> >> > equal
> >> > semantics for all targets and allow to set the INSTALL_PATH variable.
> A
> >> > next
> >> > step would be to eliminate INSTALL_PATH all together and only rely on
> >> > CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We would then
> take
> >> > 'orocos'
> >> > as a special value:
> >> >
> >> >

> >> >  # If cmake install prefix is default, use 'orocos' instead
> >> >  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR
> CMAKE_INSTALL_PREFIX
> >> > STREQUAL "orocos" )
> >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> >> > install
> >> > prefix forced to RTT install prefix path." FORCE)
> >> >  endif()
> >> >

> >> >
> >> > We can deprecate INSTALL_PATH with some extra code but I doubt it is
> in
> >> > use
> >> > actually, since it's undocumented.... what do you think ?
> >> >
> >> >
> >> >
> >> > I also prefer to remove the INSTALL_PATH variable. However, the
> problem
> >> > is that I want to use the CMake default, which is C:\Program Files<
> >> > x86>\${PROJET_NAME}. In that case, the
> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable is set and the
> proposed
> >> > logic won't work. There is two reasons why I want to use the default:
> >> >
> >> > 1. It installs in a subfolder with the ${PROJECT_NAME} suffix
> >> > 2. It has the logic to select either C:\Program Files\${PROJECT_NAME}
> or
> >> > C:\Program Files (x86)\${PROJECT_NAME}
> >> >
> >> > One workaround would be to set the CMAKE_INSTALL_PREFIX in the
> >> > CMakeLists.txt before calling the project() macro so the
> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not set. However, I
> must
> >> > admit I really don't like this one because I would have to recode the
> CMake
> >> > logic to detect if I have to install in C:\Program Files\[...] or
> C:\Program
> >> > Files (x86)\[...]. There is a macro for that in CMake 2.8.3 that I
> could
> >> > use, but I would prefer to let CMake make the choice and then be
> compatible
> >> > with older versions of CMake.
> >>
> >> Are we just trying to support
> >> - a default INSTALL location it none given
> >
> > Yes
> >
> >>
> >> - a method for the user to override the default INSTALL location if none
> >> given (and optionally just use the CMake default)
> >
> > Yes
> >
> >>
> >> - (?) a method for the user to force the INSTALL location
> >>
> >> And this has to work on all supported platforms, or are you trying to do
> >> the above just for Windows?
> >>
> >
> > The current logic only forces the install path on Windows, but I think
> it's
> > a good idea to have a common logic for all platforms. The install prefix
> on
> > Linux is /usr/local by default anyways, so it should not break anything.
> On
> > windows, the project name is appended so this is more complex.
> >
> >>
> >> > The other workaround, which is more portable, would be to unset the
> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT just after the project()
> macro.
> >> > Then, it will use the default CMAKE_INSTALL_PREFIX but the orocos
> macros
> >> > will think it's a custom value. What do you think about that?
> >>
> >> Which would break standard CMake behaviour, making it hard for other
> >> people to figure out what is going on. I would not want that as a
> >> project-wide default.
> >>
> >
> > I agree that this is a hack and it may breaks other cmake logic inside
> > projects.
> > I think we will need to keep an additionnal CMake variable to configure
> the
> > install path. How about this logic:
> >

> > # The user should set the variable ORO_INSTALL_PREFIX to force the
> > installation prefix of orocos components/plugins/...
> > # If none is given, then the ORO_INSTALL_PREFIX is set to
> > CMAKE_INSTALL_PREFIX if it's non-default
> > # If both ORO_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX are not explicitly
> > set, the installation prefix
> > # is set to the Orocos-RTT directory.
> > if(NOT ORO_INSTALL_PREFIX)
> >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> >     set(ORO_INSTALL_PREFIX "orocos")
> >   else(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> >     set(ORO_INSTALL_PREFIX CMAKE_PREFIX_PATH)
> >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > endif(NOT ORO_INSTALL_PREFIX)
> > # Check for special case of ORO_INSTALL_PATH="orocos"
> > if(ORO_INSTALL_PREFIX STREQUAL "orocos")
> >    set (ORO_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> installs
> > at same location as Orocos RTT." FORCE)
> >    mark_as_advanced(ORO_INSTALL_PATH)
>
> typo here: ORO_INSTALL_PATH
>
> > endif(ORO_INSTALL_PREFIX STREQUAL "orocos")
> >

> > I think we should not override the CMAKE_INSTALL_PREFIX variable since it
> > can break many things in other cmake projects. That's why I propose that
> the
> > UseOROCOS-RTT macros should now use ORO_INSTALL_PATH to configure the
> full
> > install paths instead of using the CMAKE_INSTALL_PREFIX.
>
> I agree fully with your proposal. However, it will also require
> updates to all the other orocos_
> macros such that they use ORO_INSTALL_PREFIX instead of
> CMAKE_INSTALL_PREFIX
>
>
I made some tests regarding the proposed method and I'm getting the
conclusion that the use of the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT
isn't a good idea. The problem is that this variable is valid only for the
first cmake 'configure'. Indeed, during the first 'configure' of cmake, the
CMAKE_INSTALL_PREFIX is put into the cache and
the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT if set to true if
applicable. During the second 'configure', cmake detects that the
CMAKE_INSTALL_PREFIX is already initialized by the user (reading it from
cache) and thus unset CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT. This
leads to two limitations of the proposed method:

1. You must make sure that the UseOROCOS-RTT.cmake file is included in the
first cmake 'configure', otherwise the default 'orocos' install path will
never be used.

2. If someone doesn't define it's own ORO_INSTALL_PREFIX, he can not change
the install path of orocos component after the first cmake 'configure',
because the install path is put in the cache during the first 'configure'.
This mean that any modification of the CMAKE_INSTALL_PREFIX through the
cmake-gui won't make any change to the orocos install path if this is not
done before executing cmake for the first time.

The initial goal wasn't to support different installation paths for targets
non related to orocos and those related to orocos. Also, the orocos macros
should always honor any modifications to the CMAKE_INSTALL_PREFIX variable.
It is now clear to me that this is not a good idea and it's difficult to
have both CMAKE_INSTALL_PREFIX and ORO_INSTALL_PREFIX coexists. Anyway, the
actual behavior is really what we want, with the exception of one missing
thing: be able to disable the overriding of the CMAKE_INSTALL_PREFIX by the
UseOROCOS-RTT.cmake file in order to use the default CMAKE_INSTALL_PREFIX
value. Until we see the need to have a per-package installation logic or
something more complex, we could just end with something like this:

  # On windows, the CMAKE_INSTALL_PREFIX is forced to the Orocos-RTT path.
  # There's two alternatives to disable this behavior:
  #
  # 1. Use the ORO_DEFAULT_INSTALL_PREFIX variable to modify the default
  #    installation path:
  #
  #     set(ORO_DEFAULT_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
  #     include(${OROCOS-RTT_USE_FILE_PATH}/UseOROCOS-RTT.cmake)
  #
  # 2. Force a non-default CMAKE_INSTALL_PREFIX prior to executing cmake:
  #
  #     cmake -DCMAKE_INSTALL_PREFIX="<your install prefix>" [...]
  #
  # In all cases, the Orocos macros will always honor any change to the
cached
  # CMAKE_INSTALL_PREFIX variable.
 
  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
ORO_DEFAULT_INSTALL_PREFIX)
    if(WIN32)
        set(ORO_DEFAULT_INSTALL_PREFIX "orocos")
    endif(WIN32)
  endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
ORO_DEFAULT_INSTALL_PREFIX)
 
  if(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
    if(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
        set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Install
prefix forced to orocos by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
    else(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
        set (CMAKE_INSTALL_PREFIX ${ORO_DEFAULT_INSTALL_PREFIX} CACHE PATH
"Install prefix forced by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
    endif(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
  endif(DEFINED ORO_DEFAULT_INSTALL_PREFIX)

We still have the limitation that the UseOROCOS-RTT.cmake file still needs
to be included in the first cmake 'configure' so that
the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable may be set to true.

What do you think about that?

Philippe

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by peter on Wed, 2011-06-15 15:40.

On Monday 13 June 2011 18:58:18 Philippe Hamelin wrote:
> 2011/6/9 Peter Soetens <peter [..] ...>
>
> > On Thu, Jun 9, 2011 at 4:26 PM, Philippe Hamelin
> >
> > <philippe [dot] hamelin [..] ...> wrote:
> > > 2011/6/9 S Roderick <kiwi [dot] net [..] ...>
> > >
> > >> On Jun 9, 2011, at 09:03 , Philippe Hamelin wrote:
> > >> > 2011/6/9 Peter Soetens <peter [..] ...>
> > >> >
> > >> > On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
> > >> > > 2011/6/7 Peter Soetens <peter [..] ...>
> > >> > >
> > >> > > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
> > >> > > >
> > >> > > > <philippe [dot] hamelin [..] ...> wrote:
> > >> > > > > Hello,
> > >> > > > > I'm having troubles integrating some orocos components in my
> >
> > build
> >
> > >> > > > system. I
> > >> > > >
> > >> > > > > have a project with multiple targets where some are orocos
> > >> > > > > components.
> > >> > > >
> > >> > > > The
> > >> > > >
> > >> > > > > problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX
> >
> > to
> >
> > >> > > > C:\Program
> > >> > > >
> > >> > > > > Files\orocos. Here is the problematic snippet of the
> > >> > > > > UseOROCOS-RTT.cmake file:
> > >> > > > >

> > >> > > > > 
> > >> > > > >   # Detect user flag: install with orocos
> > >> > > > >   if (INSTALL_PATH STREQUAL "orocos")
> > >> > > > >   
> > >> > > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> > >> > > > > 
> > >> > > > > same
> > >> > > > 
> > >> > > > location
> > >> > > > 
> > >> > > > > as Orocos RTT." FORCE)
> > >> > > > > 
> > >> > > > >     mark_as_advanced(INSTALL_PATH)
> > >> > > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > >> > > > > 
> > >> > > > > "Package
> > >> > > > 
> > >> > > > install
> > >> > > > 
> > >> > > > > prefix forced by INSTALL_PATH" FORCE)
> > >> > > > > 
> > >> > > > >   else (INSTALL_PATH STREQUAL "orocos")
> > >> > > > >   
> > >> > > > >     if (WIN32)
> > >> > > > >     
> > >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs
> > >> > > > >       at
> > >> > > > > 
> > >> > > > > same
> > >> > > > > 
> > >> > > > > location as Orocos RTT." FORCE)
> > >> > > > > 
> > >> > > > >       mark_as_advanced(INSTALL_PATH)
> > >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > >> > > > > 
> > >> > > > > "Package
> > >> > > > > 
> > >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> > >> > > > > 
> > >> > > > >     endif (WIN32)
> > >> > > > >   
> > >> > > > >   endif (INSTALL_PATH STREQUAL "orocos")
> > >> > > > > 
> > >> > > > >

> > >> > > > > This leads to an important limitation: once you have an
> > >> > > >
> > >> > > > orocos component in
> > >> > > >
> > >> > > > > your project, your whole project will be installed in
> > >> > > > > C:\Program Files\orocos. Is there a particular reason why
> > >> > > > > this has been
> >
> > done
> >
> > >> > > > > so? I
> > >> > > > > would like to suggest to remove these lines:
> > >> > > > >

> > >> > > > > 
> > >> > > > >     if (WIN32)
> > >> > > > >     
> > >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs
> > >> > > > >       at
> > >> > > > > 
> > >> > > > > same
> > >> > > > > 
> > >> > > > > location as Orocos RTT." FORCE)
> > >> > > > > 
> > >> > > > >       mark_as_advanced(INSTALL_PATH)
> > >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > >> > > > > 
> > >> > > > > "Package
> > >> > > > > 
> > >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> > >> > > > > 
> > >> > > > >     endif (WIN32)
> > >> > > > > 
> > >> > > > >

> > >> > > > > Anyways, if someone want to install in the same folder as
> >
> > orocos,
> >
> > >> > > > > we
> > >> > > > > can always set the INSTALL_PATH to "orocos". If this is
> >
> > accepted,
> >
> > >> > > > > I
> > >> > > > > could
> > >> > > >
> > >> > > > bundle
> > >> > > >
> > >> > > > > this patch with the others I made for win32 some days ago.
> > >> > > > > Philippe
> > >> > > >
> > >> > > > The rationale was/is twofold:
> > >> > > > 1. on Windows, you prefer to install all build results of Orocos
> > >> > > > MSVS
> > >> > > > projects in program files\orocos. This eases setting up the
> > >> > > > deployment
> > >> > > > component, plugin loader etc, since the RTT_COMPONENT_PATH is
> > >> > > > set
> >
> > to
> >
> > >> > > > that location by default
> > >> > > > 2. With orocreate-pkg and the UseOrocos.cmake macros, it's
> >
> > dead-easy
> >
> > >> > > > to create new packages and to depend on other packages (use
> > >> > > > their headers and link with their libs).So it's feasible to
> > >> > > > split
> >
> > software
> >
> > >> > > > in multiple, smaller packages. I don't know how well this works
> > >> > > > on Windows though...
> > >> > > > 3. To have as much as possible out-of-the-box building, the
> >
> > standard
> >
> > >> > > > path for each of these package is set to the RTT installation
> >
> > path,
> >
> > >> > > > such that no extra cmake variable needs to be set, except where
> > >> > > > to find RTT.
> > >> > > >
> > >> > > > That said, UseOrocos.cmake is not well tuned yet for win32
> > >> > > > usage...so
> > >> > > > any input/proposals is certainly welcome.
> > >> > > >
> > >> > > > But I would prefer the default 'install with rtt' still in
> > >> > > > action, but
> > >> > > > let it override at cmake-gui level or before you include the
> > >> > > > useorocos.cmake file.
> > >> > > >
> > >> > > > Peter
> > >> > >
> > >> > > I do not agree with all of the rationales since I prefer to
> >
> > separate
> >
> > >> > > orocos from the application-specific components. However, I can
> > >> > > live with
> > >> > > the default value of 'install with rtt'. Here is the logic we
> > >> > > could
> > >> >
> > >> > > have:
> > >> > I see your point...
> > >> >
> > >> > >

> > >> > > 
> > >> > >   # On win32, packages install at same location as Orocos by
> > >> > >   default if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > >> > > 
> > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> > >> > > 
> > >> > >     set (INSTALL_PATH "orocos")
> > >> > >   
> > >> > >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > >> > > 
> > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> > >> > > 
> > >> > >   # Detect user flag: install with orocos
> > >> > >   if (INSTALL_PATH STREQUAL "orocos")
> > >> > >   
> > >> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> > >> > >     same
> > >> > > 
> > >> > > location as Orocos RTT." FORCE)
> > >> > > 
> > >> > >     mark_as_advanced(INSTALL_PATH)
> > >> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > >> > >     "Package
> > >> > > 
> > >> > > install prefix forced by INSTALL_PATH" FORCE)
> > >> > > 
> > >> > >   endif(INSTALL_PATH STREQUAL "orocos")
> > >> > > 
> > >> > >

> > >> > >
> > >> > > Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains
> > >> > > unchanged. On
> > >> > > win32, it defaults to "C:\Program Files\orocos" and someone can
> > >> > > disable
> > >> > > that behavior by just defining ORO_DISABLE_DEFAULT_INSTALL_PATH.
> >
> > Also,
> >
> > >> > > I
> > >> > > think that the variable name INSTALL_PATH is a bit too general and
> >
> > may
> >
> > >> > > lead to conflicts when combining orocos with other cmake projects.
> > >> > > Would
> > >> > > you care to rename it to something like ORO_INSTALL_PATH? If you
> >
> > agree
> >
> > >> > > on
> > >> > > that I will then submit a patch.
> > >> >
> > >> > Maybe we can do even better/cleaner :-) I think part of this code
> >
> > exists
> >
> > >> > because at the time of writing, we were not aware of the
> > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT cmake variable.
> > >> >
> > >> > What we could do is make this uniform for all platforms and write it
> > >> > like
> > >> > this:
> > >> >
> > >> >

> > >> > 
> > >> >  # If cmake install prefix is default, use 'orocos' instead
> > >> >  if(NOT DEFINED INSTALL_PATH AND
> > >> > 
> > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > >> > 
> > >> >    set (INSTALL_PATH "orocos")
> > >> >  
> > >> >  endif()
> > >> >  
> > >> >  # Detect user flag: install with orocos
> > >> >  if (INSTALL_PATH STREQUAL "orocos")
> > >> >  
> > >> >    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > >> > 
> > >> > location
> > >> > as Orocos RTT." FORCE)
> > >> > 
> > >> >    mark_as_advanced(INSTALL_PATH)
> > >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > >> > 
> > >> > install
> > >> > prefix forced by INSTALL_PATH" FORCE)
> > >> > 
> > >> >  endif(INSTALL_PATH STREQUAL "orocos")
> > >> > 
> > >> >

> > >> >
> > >> > In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH, got
> > >> > equal
> > >> > semantics for all targets and allow to set the INSTALL_PATH
> > >> > variable.
> >
> > A
> >
> > >> > next
> > >> > step would be to eliminate INSTALL_PATH all together and only rely
> > >> > on CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We would
> > >> > then
> >
> > take
> >
> > >> > 'orocos'
> > >> > as a special value:
> > >> >
> > >> >

> > >> > 
> > >> >  # If cmake install prefix is default, use 'orocos' instead
> > >> >  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR
> > 
> > CMAKE_INSTALL_PREFIX
> > 
> > >> > STREQUAL "orocos" )
> > >> > 
> > >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > >> > 
> > >> > install
> > >> > prefix forced to RTT install prefix path." FORCE)
> > >> > 
> > >> >  endif()
> > >> > 
> > >> >

> > >> >
> > >> > We can deprecate INSTALL_PATH with some extra code but I doubt it is
> >
> > in
> >
> > >> > use
> > >> > actually, since it's undocumented.... what do you think ?
> > >> >
> > >> >
> > >> >
> > >> > I also prefer to remove the INSTALL_PATH variable. However, the
> >
> > problem
> >
> > >> > is that I want to use the CMake default, which is C:\Program Files<
> > >> > x86>\${PROJET_NAME}. In that case, the
> > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable is set and the
> >
> > proposed
> >
> > >> > logic won't work. There is two reasons why I want to use the
> > >> > default:
> > >> >
> > >> > 1. It installs in a subfolder with the ${PROJECT_NAME} suffix
> > >> > 2. It has the logic to select either C:\Program
> > >> > Files\${PROJECT_NAME}
> >
> > or
> >
> > >> > C:\Program Files (x86)\${PROJECT_NAME}
> > >> >
> > >> > One workaround would be to set the CMAKE_INSTALL_PREFIX in the
> > >> > CMakeLists.txt before calling the project() macro so the
> > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not set. However, I
> >
> > must
> >
> > >> > admit I really don't like this one because I would have to recode
> > >> > the
> >
> > CMake
> >
> > >> > logic to detect if I have to install in C:\Program Files\[...] or
> >
> > C:\Program
> >
> > >> > Files (x86)\[...]. There is a macro for that in CMake 2.8.3 that I
> >
> > could
> >
> > >> > use, but I would prefer to let CMake make the choice and then be
> >
> > compatible
> >
> > >> > with older versions of CMake.
> > >>
> > >> Are we just trying to support
> > >> - a default INSTALL location it none given
> > >
> > > Yes
> > >
> > >> - a method for the user to override the default INSTALL location if
> > >> none given (and optionally just use the CMake default)
> > >
> > > Yes
> > >
> > >> - (?) a method for the user to force the INSTALL location
> > >>
> > >> And this has to work on all supported platforms, or are you trying to
> > >> do the above just for Windows?
> > >
> > > The current logic only forces the install path on Windows, but I think
> >
> > it's
> >
> > > a good idea to have a common logic for all platforms. The install
> > > prefix
> >
> > on
> >
> > > Linux is /usr/local by default anyways, so it should not break
> > > anything.
> >
> > On
> >
> > > windows, the project name is appended so this is more complex.
> > >
> > >> > The other workaround, which is more portable, would be to unset the
> > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT just after the project()
> >
> > macro.
> >
> > >> > Then, it will use the default CMAKE_INSTALL_PREFIX but the orocos
> >
> > macros
> >
> > >> > will think it's a custom value. What do you think about that?
> > >>
> > >> Which would break standard CMake behaviour, making it hard for other
> > >> people to figure out what is going on. I would not want that as a
> > >> project-wide default.
> > >
> > > I agree that this is a hack and it may breaks other cmake logic inside
> > > projects.
> > > I think we will need to keep an additionnal CMake variable to configure
> >
> > the
> >
> > > install path. How about this logic:
> > >

> > > # The user should set the variable ORO_INSTALL_PREFIX to force the
> > > installation prefix of orocos components/plugins/...
> > > # If none is given, then the ORO_INSTALL_PREFIX is set to
> > > CMAKE_INSTALL_PREFIX if it's non-default
> > > # If both ORO_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX are not
> > > explicitly set, the installation prefix
> > > # is set to the Orocos-RTT directory.
> > > if(NOT ORO_INSTALL_PREFIX)
> > > 
> > >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > >   
> > >     set(ORO_INSTALL_PREFIX "orocos")
> > >   
> > >   else(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > >   
> > >     set(ORO_INSTALL_PREFIX CMAKE_PREFIX_PATH)
> > >   
> > >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > 
> > > endif(NOT ORO_INSTALL_PREFIX)
> > > # Check for special case of ORO_INSTALL_PATH="orocos"
> > > if(ORO_INSTALL_PREFIX STREQUAL "orocos")
> > > 
> > >    set (ORO_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > 
> > installs
> > 
> > > at same location as Orocos RTT." FORCE)
> > > 
> > >    mark_as_advanced(ORO_INSTALL_PATH)
> > 
> > typo here: ORO_INSTALL_PATH
> > 
> > > endif(ORO_INSTALL_PREFIX STREQUAL "orocos")
> > >

> > > I think we should not override the CMAKE_INSTALL_PREFIX variable since
> > > it can break many things in other cmake projects. That's why I propose
> > > that
> >
> > the
> >
> > > UseOROCOS-RTT macros should now use ORO_INSTALL_PATH to configure the
> >
> > full
> >
> > > install paths instead of using the CMAKE_INSTALL_PREFIX.
> >
> > I agree fully with your proposal. However, it will also require
> > updates to all the other orocos_
> > macros such that they use ORO_INSTALL_PREFIX instead of
> > CMAKE_INSTALL_PREFIX
>
> I made some tests regarding the proposed method and I'm getting the
> conclusion that the use of the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT
> isn't a good idea. The problem is that this variable is valid only for the
> first cmake 'configure'. Indeed, during the first 'configure' of cmake, the
> CMAKE_INSTALL_PREFIX is put into the cache and
> the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT if set to true if
> applicable. During the second 'configure', cmake detects that the
> CMAKE_INSTALL_PREFIX is already initialized by the user (reading it from
> cache) and thus unset CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT. This
> leads to two limitations of the proposed method:
>
> 1. You must make sure that the UseOROCOS-RTT.cmake file is included in the
> first cmake 'configure', otherwise the default 'orocos' install path will
> never be used.
>
> 2. If someone doesn't define it's own ORO_INSTALL_PREFIX, he can not change
> the install path of orocos component after the first cmake 'configure',
> because the install path is put in the cache during the first 'configure'.
> This mean that any modification of the CMAKE_INSTALL_PREFIX through the
> cmake-gui won't make any change to the orocos install path if this is not
> done before executing cmake for the first time.
>
> The initial goal wasn't to support different installation paths for targets
> non related to orocos and those related to orocos. Also, the orocos macros
> should always honor any modifications to the CMAKE_INSTALL_PREFIX variable.
> It is now clear to me that this is not a good idea and it's difficult to
> have both CMAKE_INSTALL_PREFIX and ORO_INSTALL_PREFIX coexists. Anyway, the
> actual behavior is really what we want, with the exception of one missing
> thing: be able to disable the overriding of the CMAKE_INSTALL_PREFIX by the
> UseOROCOS-RTT.cmake file in order to use the default CMAKE_INSTALL_PREFIX
> value. Until we see the need to have a per-package installation logic or
> something more complex, we could just end with something like this:
>
>

>   # On windows, the CMAKE_INSTALL_PREFIX is forced to the Orocos-RTT path.
>   # There's two alternatives to disable this behavior:
>   #
>   # 1. Use the ORO_DEFAULT_INSTALL_PREFIX variable to modify the default
>   #    installation path:
>   #
>   #     set(ORO_DEFAULT_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
>   #     include(${OROCOS-RTT_USE_FILE_PATH}/UseOROCOS-RTT.cmake)
>   #
>   # 2. Force a non-default CMAKE_INSTALL_PREFIX prior to executing cmake:
>   #
>   #     cmake -DCMAKE_INSTALL_PREFIX="<your install prefix>" [...]
>   #
>   # In all cases, the Orocos macros will always honor any change to the
> cached
>   # CMAKE_INSTALL_PREFIX variable.
> 
>   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
> ORO_DEFAULT_INSTALL_PREFIX)
>     if(WIN32)
>         set(ORO_DEFAULT_INSTALL_PREFIX "orocos")
>     endif(WIN32)
>   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
> ORO_DEFAULT_INSTALL_PREFIX)
> 
>   if(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
>     if(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
>         set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Install
> prefix forced to orocos by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
>     else(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
>         set (CMAKE_INSTALL_PREFIX ${ORO_DEFAULT_INSTALL_PREFIX} CACHE PATH
> "Install prefix forced by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
>     endif(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
>   endif(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
>

>
> We still have the limitation that the UseOROCOS-RTT.cmake file still needs
> to be included in the first cmake 'configure' so that
> the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable may be set to
> true.
>
> What do you think about that?

My head is spinning from all this swinging :-)

So you opt to not cache ORO_DEFAULT_INSTALL_PREFIX ... I'm happy with the
simpler solution and I can't think of a way that this will go wrong.

I have also applied your other pending win32 patches on rtt/ocl/log4cpp. The
only issue was with the PluginLoader checking for the -target'd' suffix, since
Stephen had also been patching that for filtering out the dylib loading on
macos-x.

I have RTT unit tests almost flawlessly running on win32 on the 2.4 branch so I
think we're getting there. The next round is for macos-x fixing :-)

See https://build.mech.kuleuven.be/jenkins/job/orocos-rtt-master-WinXP/

Peter

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by phamelin on Wed, 2011-06-15 16:20.

2011/6/15 Peter Soetens <peter [..] ...>

> On Monday 13 June 2011 18:58:18 Philippe Hamelin wrote:
> > 2011/6/9 Peter Soetens <peter [..] ...>
> >
> > > On Thu, Jun 9, 2011 at 4:26 PM, Philippe Hamelin
> > >
> > > <philippe [dot] hamelin [..] ...> wrote:
> > > > 2011/6/9 S Roderick <kiwi [dot] net [..] ...>
> > > >
> > > >> On Jun 9, 2011, at 09:03 , Philippe Hamelin wrote:
> > > >> > 2011/6/9 Peter Soetens <peter [..] ...>
> > > >> >
> > > >> > On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
> > > >> > > 2011/6/7 Peter Soetens <peter [..] ...>
> > > >> > >
> > > >> > > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
> > > >> > > >
> > > >> > > > <philippe [dot] hamelin [..] ...> wrote:
> > > >> > > > > Hello,
> > > >> > > > > I'm having troubles integrating some orocos components in my
> > >
> > > build
> > >
> > > >> > > > system. I
> > > >> > > >
> > > >> > > > > have a project with multiple targets where some are orocos
> > > >> > > > > components.
> > > >> > > >
> > > >> > > > The
> > > >> > > >
> > > >> > > > > problem is that UseOrocos file forces the
> CMAKE_INSTALL_PREFIX
> > >
> > > to
> > >
> > > >> > > > C:\Program
> > > >> > > >
> > > >> > > > > Files\orocos. Here is the problematic snippet of the
> > > >> > > > > UseOROCOS-RTT.cmake file:
> > > >> > > > >

> > > >> > > > >
> > > >> > > > >   # Detect user flag: install with orocos
> > > >> > > > >   if (INSTALL_PATH STREQUAL "orocos")
> > > >> > > > >
> > > >> > > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs
> at
> > > >> > > > >
> > > >> > > > > same
> > > >> > > >
> > > >> > > > location
> > > >> > > >
> > > >> > > > > as Orocos RTT." FORCE)
> > > >> > > > >
> > > >> > > > >     mark_as_advanced(INSTALL_PATH)
> > > >> > > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > > >> > > > >
> > > >> > > > > "Package
> > > >> > > >
> > > >> > > > install
> > > >> > > >
> > > >> > > > > prefix forced by INSTALL_PATH" FORCE)
> > > >> > > > >
> > > >> > > > >   else (INSTALL_PATH STREQUAL "orocos")
> > > >> > > > >
> > > >> > > > >     if (WIN32)
> > > >> > > > >
> > > >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package
> installs
> > > >> > > > >       at
> > > >> > > > >
> > > >> > > > > same
> > > >> > > > >
> > > >> > > > > location as Orocos RTT." FORCE)
> > > >> > > > >
> > > >> > > > >       mark_as_advanced(INSTALL_PATH)
> > > >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE
> PATH
> > > >> > > > >
> > > >> > > > > "Package
> > > >> > > > >
> > > >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> > > >> > > > >
> > > >> > > > >     endif (WIN32)
> > > >> > > > >
> > > >> > > > >   endif (INSTALL_PATH STREQUAL "orocos")
> > > >> > > > >
> > > >> > > > >

> > > >> > > > > This leads to an important limitation: once you have an
> > > >> > > >
> > > >> > > > orocos component in
> > > >> > > >
> > > >> > > > > your project, your whole project will be installed in
> > > >> > > > > C:\Program Files\orocos. Is there a particular reason why
> > > >> > > > > this has been
> > >
> > > done
> > >
> > > >> > > > > so? I
> > > >> > > > > would like to suggest to remove these lines:
> > > >> > > > >

> > > >> > > > >
> > > >> > > > >     if (WIN32)
> > > >> > > > >
> > > >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package
> installs
> > > >> > > > >       at
> > > >> > > > >
> > > >> > > > > same
> > > >> > > > >
> > > >> > > > > location as Orocos RTT." FORCE)
> > > >> > > > >
> > > >> > > > >       mark_as_advanced(INSTALL_PATH)
> > > >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE
> PATH
> > > >> > > > >
> > > >> > > > > "Package
> > > >> > > > >
> > > >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> > > >> > > > >
> > > >> > > > >     endif (WIN32)
> > > >> > > > >
> > > >> > > > >

> > > >> > > > > Anyways, if someone want to install in the same folder as
> > >
> > > orocos,
> > >
> > > >> > > > > we
> > > >> > > > > can always set the INSTALL_PATH to "orocos". If this is
> > >
> > > accepted,
> > >
> > > >> > > > > I
> > > >> > > > > could
> > > >> > > >
> > > >> > > > bundle
> > > >> > > >
> > > >> > > > > this patch with the others I made for win32 some days ago.
> > > >> > > > > Philippe
> > > >> > > >
> > > >> > > > The rationale was/is twofold:
> > > >> > > > 1. on Windows, you prefer to install all build results of
> Orocos
> > > >> > > > MSVS
> > > >> > > > projects in program files\orocos. This eases setting up the
> > > >> > > > deployment
> > > >> > > > component, plugin loader etc, since the RTT_COMPONENT_PATH is
> > > >> > > > set
> > >
> > > to
> > >
> > > >> > > > that location by default
> > > >> > > > 2. With orocreate-pkg and the UseOrocos.cmake macros, it's
> > >
> > > dead-easy
> > >
> > > >> > > > to create new packages and to depend on other packages (use
> > > >> > > > their headers and link with their libs).So it's feasible to
> > > >> > > > split
> > >
> > > software
> > >
> > > >> > > > in multiple, smaller packages. I don't know how well this
> works
> > > >> > > > on Windows though...
> > > >> > > > 3. To have as much as possible out-of-the-box building, the
> > >
> > > standard
> > >
> > > >> > > > path for each of these package is set to the RTT installation
> > >
> > > path,
> > >
> > > >> > > > such that no extra cmake variable needs to be set, except
> where
> > > >> > > > to find RTT.
> > > >> > > >
> > > >> > > > That said, UseOrocos.cmake is not well tuned yet for win32
> > > >> > > > usage...so
> > > >> > > > any input/proposals is certainly welcome.
> > > >> > > >
> > > >> > > > But I would prefer the default 'install with rtt' still in
> > > >> > > > action, but
> > > >> > > > let it override at cmake-gui level or before you include the
> > > >> > > > useorocos.cmake file.
> > > >> > > >
> > > >> > > > Peter
> > > >> > >
> > > >> > > I do not agree with all of the rationales since I prefer to
> > >
> > > separate
> > >
> > > >> > > orocos from the application-specific components. However, I can
> > > >> > > live with
> > > >> > > the default value of 'install with rtt'. Here is the logic we
> > > >> > > could
> > > >> >
> > > >> > > have:
> > > >> > I see your point...
> > > >> >
> > > >> > >

> > > >> > >
> > > >> > >   # On win32, packages install at same location as Orocos by
> > > >> > >   default if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > > >> > >
> > > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> > > >> > >
> > > >> > >     set (INSTALL_PATH "orocos")
> > > >> > >
> > > >> > >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > > >> > >
> > > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> > > >> > >
> > > >> > >   # Detect user flag: install with orocos
> > > >> > >   if (INSTALL_PATH STREQUAL "orocos")
> > > >> > >
> > > >> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> > > >> > >     same
> > > >> > >
> > > >> > > location as Orocos RTT." FORCE)
> > > >> > >
> > > >> > >     mark_as_advanced(INSTALL_PATH)
> > > >> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > > >> > >     "Package
> > > >> > >
> > > >> > > install prefix forced by INSTALL_PATH" FORCE)
> > > >> > >
> > > >> > >   endif(INSTALL_PATH STREQUAL "orocos")
> > > >> > >
> > > >> > >

> > > >> > >
> > > >> > > Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains
> > > >> > > unchanged. On
> > > >> > > win32, it defaults to "C:\Program Files\orocos" and someone can
> > > >> > > disable
> > > >> > > that behavior by just defining ORO_DISABLE_DEFAULT_INSTALL_PATH.
> > >
> > > Also,
> > >
> > > >> > > I
> > > >> > > think that the variable name INSTALL_PATH is a bit too general
> and
> > >
> > > may
> > >
> > > >> > > lead to conflicts when combining orocos with other cmake
> projects.
> > > >> > > Would
> > > >> > > you care to rename it to something like ORO_INSTALL_PATH? If you
> > >
> > > agree
> > >
> > > >> > > on
> > > >> > > that I will then submit a patch.
> > > >> >
> > > >> > Maybe we can do even better/cleaner :-) I think part of this code
> > >
> > > exists
> > >
> > > >> > because at the time of writing, we were not aware of the
> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT cmake variable.
> > > >> >
> > > >> > What we could do is make this uniform for all platforms and write
> it
> > > >> > like
> > > >> > this:
> > > >> >
> > > >> >

> > > >> >
> > > >> >  # If cmake install prefix is default, use 'orocos' instead
> > > >> >  if(NOT DEFINED INSTALL_PATH AND
> > > >> >
> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > >> >
> > > >> >    set (INSTALL_PATH "orocos")
> > > >> >
> > > >> >  endif()
> > > >> >
> > > >> >  # Detect user flag: install with orocos
> > > >> >  if (INSTALL_PATH STREQUAL "orocos")
> > > >> >
> > > >> >    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > > >> >
> > > >> > location
> > > >> > as Orocos RTT." FORCE)
> > > >> >
> > > >> >    mark_as_advanced(INSTALL_PATH)
> > > >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> "Package
> > > >> >
> > > >> > install
> > > >> > prefix forced by INSTALL_PATH" FORCE)
> > > >> >
> > > >> >  endif(INSTALL_PATH STREQUAL "orocos")
> > > >> >
> > > >> >

> > > >> >
> > > >> > In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH,
> got
> > > >> > equal
> > > >> > semantics for all targets and allow to set the INSTALL_PATH
> > > >> > variable.
> > >
> > > A
> > >
> > > >> > next
> > > >> > step would be to eliminate INSTALL_PATH all together and only rely
> > > >> > on CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We would
> > > >> > then
> > >
> > > take
> > >
> > > >> > 'orocos'
> > > >> > as a special value:
> > > >> >
> > > >> >

> > > >> >
> > > >> >  # If cmake install prefix is default, use 'orocos' instead
> > > >> >  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR
> > >
> > > CMAKE_INSTALL_PREFIX
> > >
> > > >> > STREQUAL "orocos" )
> > > >> >
> > > >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> "Package
> > > >> >
> > > >> > install
> > > >> > prefix forced to RTT install prefix path." FORCE)
> > > >> >
> > > >> >  endif()
> > > >> >
> > > >> >

> > > >> >
> > > >> > We can deprecate INSTALL_PATH with some extra code but I doubt it
> is
> > >
> > > in
> > >
> > > >> > use
> > > >> > actually, since it's undocumented.... what do you think ?
> > > >> >
> > > >> >
> > > >> >
> > > >> > I also prefer to remove the INSTALL_PATH variable. However, the
> > >
> > > problem
> > >
> > > >> > is that I want to use the CMake default, which is C:\Program
> Files<
> > > >> > x86>\${PROJET_NAME}. In that case, the
> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable is set and
> the
> > >
> > > proposed
> > >
> > > >> > logic won't work. There is two reasons why I want to use the
> > > >> > default:
> > > >> >
> > > >> > 1. It installs in a subfolder with the ${PROJECT_NAME} suffix
> > > >> > 2. It has the logic to select either C:\Program
> > > >> > Files\${PROJECT_NAME}
> > >
> > > or
> > >
> > > >> > C:\Program Files (x86)\${PROJECT_NAME}
> > > >> >
> > > >> > One workaround would be to set the CMAKE_INSTALL_PREFIX in the
> > > >> > CMakeLists.txt before calling the project() macro so the
> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not set. However,
> I
> > >
> > > must
> > >
> > > >> > admit I really don't like this one because I would have to recode
> > > >> > the
> > >
> > > CMake
> > >
> > > >> > logic to detect if I have to install in C:\Program Files\[...] or
> > >
> > > C:\Program
> > >
> > > >> > Files (x86)\[...]. There is a macro for that in CMake 2.8.3 that I
> > >
> > > could
> > >
> > > >> > use, but I would prefer to let CMake make the choice and then be
> > >
> > > compatible
> > >
> > > >> > with older versions of CMake.
> > > >>
> > > >> Are we just trying to support
> > > >> - a default INSTALL location it none given
> > > >
> > > > Yes
> > > >
> > > >> - a method for the user to override the default INSTALL location if
> > > >> none given (and optionally just use the CMake default)
> > > >
> > > > Yes
> > > >
> > > >> - (?) a method for the user to force the INSTALL location
> > > >>
> > > >> And this has to work on all supported platforms, or are you trying
> to
> > > >> do the above just for Windows?
> > > >
> > > > The current logic only forces the install path on Windows, but I
> think
> > >
> > > it's
> > >
> > > > a good idea to have a common logic for all platforms. The install
> > > > prefix
> > >
> > > on
> > >
> > > > Linux is /usr/local by default anyways, so it should not break
> > > > anything.
> > >
> > > On
> > >
> > > > windows, the project name is appended so this is more complex.
> > > >
> > > >> > The other workaround, which is more portable, would be to unset
> the
> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT just after the
> project()
> > >
> > > macro.
> > >
> > > >> > Then, it will use the default CMAKE_INSTALL_PREFIX but the orocos
> > >
> > > macros
> > >
> > > >> > will think it's a custom value. What do you think about that?
> > > >>
> > > >> Which would break standard CMake behaviour, making it hard for other
> > > >> people to figure out what is going on. I would not want that as a
> > > >> project-wide default.
> > > >
> > > > I agree that this is a hack and it may breaks other cmake logic
> inside
> > > > projects.
> > > > I think we will need to keep an additionnal CMake variable to
> configure
> > >
> > > the
> > >
> > > > install path. How about this logic:
> > > >

> > > > # The user should set the variable ORO_INSTALL_PREFIX to force the
> > > > installation prefix of orocos components/plugins/...
> > > > # If none is given, then the ORO_INSTALL_PREFIX is set to
> > > > CMAKE_INSTALL_PREFIX if it's non-default
> > > > # If both ORO_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX are not
> > > > explicitly set, the installation prefix
> > > > # is set to the Orocos-RTT directory.
> > > > if(NOT ORO_INSTALL_PREFIX)
> > > >
> > > >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > >
> > > >     set(ORO_INSTALL_PREFIX "orocos")
> > > >
> > > >   else(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > >
> > > >     set(ORO_INSTALL_PREFIX CMAKE_PREFIX_PATH)
> > > >
> > > >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > >
> > > > endif(NOT ORO_INSTALL_PREFIX)
> > > > # Check for special case of ORO_INSTALL_PATH="orocos"
> > > > if(ORO_INSTALL_PREFIX STREQUAL "orocos")
> > > >
> > > >    set (ORO_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > >
> > > installs
> > >
> > > > at same location as Orocos RTT." FORCE)
> > > >
> > > >    mark_as_advanced(ORO_INSTALL_PATH)
> > >
> > > typo here: ORO_INSTALL_PATH
> > >
> > > > endif(ORO_INSTALL_PREFIX STREQUAL "orocos")
> > > >

> > > > I think we should not override the CMAKE_INSTALL_PREFIX variable
> since
> > > > it can break many things in other cmake projects. That's why I
> propose
> > > > that
> > >
> > > the
> > >
> > > > UseOROCOS-RTT macros should now use ORO_INSTALL_PATH to configure the
> > >
> > > full
> > >
> > > > install paths instead of using the CMAKE_INSTALL_PREFIX.
> > >
> > > I agree fully with your proposal. However, it will also require
> > > updates to all the other orocos_
> > > macros such that they use ORO_INSTALL_PREFIX instead of
> > > CMAKE_INSTALL_PREFIX
> >
> > I made some tests regarding the proposed method and I'm getting the
> > conclusion that the use of the
> CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT
> > isn't a good idea. The problem is that this variable is valid only for
> the
> > first cmake 'configure'. Indeed, during the first 'configure' of cmake,
> the
> > CMAKE_INSTALL_PREFIX is put into the cache and
> > the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT if set to true if
> > applicable. During the second 'configure', cmake detects that the
> > CMAKE_INSTALL_PREFIX is already initialized by the user (reading it from
> > cache) and thus unset CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT. This
> > leads to two limitations of the proposed method:
> >
> > 1. You must make sure that the UseOROCOS-RTT.cmake file is included in
> the
> > first cmake 'configure', otherwise the default 'orocos' install path will
> > never be used.
> >
> > 2. If someone doesn't define it's own ORO_INSTALL_PREFIX, he can not
> change
> > the install path of orocos component after the first cmake 'configure',
> > because the install path is put in the cache during the first
> 'configure'.
> > This mean that any modification of the CMAKE_INSTALL_PREFIX through the
> > cmake-gui won't make any change to the orocos install path if this is not
> > done before executing cmake for the first time.
> >
> > The initial goal wasn't to support different installation paths for
> targets
> > non related to orocos and those related to orocos. Also, the orocos
> macros
> > should always honor any modifications to the CMAKE_INSTALL_PREFIX
> variable.
> > It is now clear to me that this is not a good idea and it's difficult to
> > have both CMAKE_INSTALL_PREFIX and ORO_INSTALL_PREFIX coexists. Anyway,
> the
> > actual behavior is really what we want, with the exception of one missing
> > thing: be able to disable the overriding of the CMAKE_INSTALL_PREFIX by
> the
> > UseOROCOS-RTT.cmake file in order to use the default CMAKE_INSTALL_PREFIX
> > value. Until we see the need to have a per-package installation logic or
> > something more complex, we could just end with something like this:
> >
> >

> >   # On windows, the CMAKE_INSTALL_PREFIX is forced to the Orocos-RTT
> path.
> >   # There's two alternatives to disable this behavior:
> >   #
> >   # 1. Use the ORO_DEFAULT_INSTALL_PREFIX variable to modify the default
> >   #    installation path:
> >   #
> >   #     set(ORO_DEFAULT_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
> >   #     include(${OROCOS-RTT_USE_FILE_PATH}/UseOROCOS-RTT.cmake)
> >   #
> >   # 2. Force a non-default CMAKE_INSTALL_PREFIX prior to executing cmake:
> >   #
> >   #     cmake -DCMAKE_INSTALL_PREFIX="<your install prefix>" [...]
> >   #
> >   # In all cases, the Orocos macros will always honor any change to the
> > cached
> >   # CMAKE_INSTALL_PREFIX variable.
> >
> >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
> > ORO_DEFAULT_INSTALL_PREFIX)
> >     if(WIN32)
> >         set(ORO_DEFAULT_INSTALL_PREFIX "orocos")
> >     endif(WIN32)
> >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
> > ORO_DEFAULT_INSTALL_PREFIX)
> >
> >   if(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
> >     if(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
> >         set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Install
> > prefix forced to orocos by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
> >     else(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
> >         set (CMAKE_INSTALL_PREFIX ${ORO_DEFAULT_INSTALL_PREFIX} CACHE
> PATH
> > "Install prefix forced by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
> >     endif(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
> >   endif(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
> >

> >
> > We still have the limitation that the UseOROCOS-RTT.cmake file still
> needs
> > to be included in the first cmake 'configure' so that
> > the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable may be set to
> > true.
> >
> > What do you think about that?
>
> My head is spinning from all this swinging :-)
>
> So you opt to not cache ORO_DEFAULT_INSTALL_PREFIX ... I'm happy with the
> simpler solution and I can't think of a way that this will go wrong.
>
> I have also applied your other pending win32 patches on rtt/ocl/log4cpp.
> The
> only issue was with the PluginLoader checking for the -target'd' suffix,
> since
> Stephen had also been patching that for filtering out the dylib loading on
> macos-x.
>
> I have RTT unit tests almost flawlessly running on win32 on the 2.4 branch
> so I
> think we're getting there. The next round is for macos-x fixing :-)
>
>
Did you push the commits for OCL? I don't see any recent commits in
gitorious.

Philippe

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by phamelin on Wed, 2011-06-15 16:00.

2011/6/15 Peter Soetens <peter [..] ...>

> > > >> > > > >
> > > >> > > > >   # Detect user flag: install with orocos
> > > >> > > > >   if (INSTALL_PATH STREQUAL "orocos")
> > > >> > > > >
> > > >> > > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs
> at
> > > >> > > > >
> > > >> > > > > same
> > > >> > > >
> > > >> > > > location
> > > >> > > >
> > > >> > > > > as Orocos RTT." FORCE)
> > > >> > > > >
> > > >> > > > >     mark_as_advanced(INSTALL_PATH)
> > > >> > > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > > >> > > > >
> > > >> > > > > "Package
> > > >> > > >
> > > >> > > > install
> > > >> > > >
> > > >> > > > > prefix forced by INSTALL_PATH" FORCE)
> > > >> > > > >
> > > >> > > > >   else (INSTALL_PATH STREQUAL "orocos")
> > > >> > > > >
> > > >> > > > >     if (WIN32)
> > > >> > > > >
> > > >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package
> installs
> > > >> > > > >       at
> > > >> > > > >
> > > >> > > > > same
> > > >> > > > >
> > > >> > > > > location as Orocos RTT." FORCE)
> > > >> > > > >
> > > >> > > > >       mark_as_advanced(INSTALL_PATH)
> > > >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE
> PATH
> > > >> > > > >
> > > >> > > > > "Package
> > > >> > > > >
> > > >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> > > >> > > > >
> > > >> > > > >     endif (WIN32)
> > > >> > > > >
> > > >> > > > >   endif (INSTALL_PATH STREQUAL "orocos")
> > > >> > > > >
> > > >> > > > >

> > > >> > > > >
> > > >> > > > >     if (WIN32)
> > > >> > > > >
> > > >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package
> installs
> > > >> > > > >       at
> > > >> > > > >
> > > >> > > > > same
> > > >> > > > >
> > > >> > > > > location as Orocos RTT." FORCE)
> > > >> > > > >
> > > >> > > > >       mark_as_advanced(INSTALL_PATH)
> > > >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE
> PATH
> > > >> > > > >
> > > >> > > > > "Package
> > > >> > > > >
> > > >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> > > >> > > > >
> > > >> > > > >     endif (WIN32)
> > > >> > > > >
> > > >> > > > >

> > > >> > >
> > > >> > >   # On win32, packages install at same location as Orocos by
> > > >> > >   default if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > > >> > >
> > > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> > > >> > >
> > > >> > >     set (INSTALL_PATH "orocos")
> > > >> > >
> > > >> > >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > > >> > >
> > > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> > > >> > >
> > > >> > >   # Detect user flag: install with orocos
> > > >> > >   if (INSTALL_PATH STREQUAL "orocos")
> > > >> > >
> > > >> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> > > >> > >     same
> > > >> > >
> > > >> > > location as Orocos RTT." FORCE)
> > > >> > >
> > > >> > >     mark_as_advanced(INSTALL_PATH)
> > > >> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > > >> > >     "Package
> > > >> > >
> > > >> > > install prefix forced by INSTALL_PATH" FORCE)
> > > >> > >
> > > >> > >   endif(INSTALL_PATH STREQUAL "orocos")
> > > >> > >
> > > >> > >

> > > >> >
> > > >> >  # If cmake install prefix is default, use 'orocos' instead
> > > >> >  if(NOT DEFINED INSTALL_PATH AND
> > > >> >
> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > >> >
> > > >> >    set (INSTALL_PATH "orocos")
> > > >> >
> > > >> >  endif()
> > > >> >
> > > >> >  # Detect user flag: install with orocos
> > > >> >  if (INSTALL_PATH STREQUAL "orocos")
> > > >> >
> > > >> >    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> > > >> >
> > > >> > location
> > > >> > as Orocos RTT." FORCE)
> > > >> >
> > > >> >    mark_as_advanced(INSTALL_PATH)
> > > >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> "Package
> > > >> >
> > > >> > install
> > > >> > prefix forced by INSTALL_PATH" FORCE)
> > > >> >
> > > >> >  endif(INSTALL_PATH STREQUAL "orocos")
> > > >> >
> > > >> >

> > > >> >
> > > >> >  # If cmake install prefix is default, use 'orocos' instead
> > > >> >  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR
> > >
> > > CMAKE_INSTALL_PREFIX
> > >
> > > >> > STREQUAL "orocos" )
> > > >> >
> > > >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> "Package
> > > >> >
> > > >> > install
> > > >> > prefix forced to RTT install prefix path." FORCE)
> > > >> >
> > > >> >  endif()
> > > >> >
> > > >> >

> > > > # The user should set the variable ORO_INSTALL_PREFIX to force the
> > > > installation prefix of orocos components/plugins/...
> > > > # If none is given, then the ORO_INSTALL_PREFIX is set to
> > > > CMAKE_INSTALL_PREFIX if it's non-default
> > > > # If both ORO_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX are not
> > > > explicitly set, the installation prefix
> > > > # is set to the Orocos-RTT directory.
> > > > if(NOT ORO_INSTALL_PREFIX)
> > > >
> > > >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > >
> > > >     set(ORO_INSTALL_PREFIX "orocos")
> > > >
> > > >   else(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > >
> > > >     set(ORO_INSTALL_PREFIX CMAKE_PREFIX_PATH)
> > > >
> > > >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > >
> > > > endif(NOT ORO_INSTALL_PREFIX)
> > > > # Check for special case of ORO_INSTALL_PATH="orocos"
> > > > if(ORO_INSTALL_PREFIX STREQUAL "orocos")
> > > >
> > > >    set (ORO_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > >
> > > installs
> > >
> > > > at same location as Orocos RTT." FORCE)
> > > >
> > > >    mark_as_advanced(ORO_INSTALL_PATH)
> > >
> > > typo here: ORO_INSTALL_PATH
> > >
> > > > endif(ORO_INSTALL_PREFIX STREQUAL "orocos")
> > > >

> >   # On windows, the CMAKE_INSTALL_PREFIX is forced to the Orocos-RTT
> path.
> >   # There's two alternatives to disable this behavior:
> >   #
> >   # 1. Use the ORO_DEFAULT_INSTALL_PREFIX variable to modify the default
> >   #    installation path:
> >   #
> >   #     set(ORO_DEFAULT_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
> >   #     include(${OROCOS-RTT_USE_FILE_PATH}/UseOROCOS-RTT.cmake)
> >   #
> >   # 2. Force a non-default CMAKE_INSTALL_PREFIX prior to executing cmake:
> >   #
> >   #     cmake -DCMAKE_INSTALL_PREFIX="<your install prefix>" [...]
> >   #
> >   # In all cases, the Orocos macros will always honor any change to the
> > cached
> >   # CMAKE_INSTALL_PREFIX variable.
> >
> >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
> > ORO_DEFAULT_INSTALL_PREFIX)
> >     if(WIN32)
> >         set(ORO_DEFAULT_INSTALL_PREFIX "orocos")
> >     endif(WIN32)
> >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
> > ORO_DEFAULT_INSTALL_PREFIX)
> >
> >   if(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
> >     if(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
> >         set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Install
> > prefix forced to orocos by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
> >     else(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
> >         set (CMAKE_INSTALL_PREFIX ${ORO_DEFAULT_INSTALL_PREFIX} CACHE
> PATH
> > "Install prefix forced by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
> >     endif(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
> >   endif(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
> >

https://github.com/phamelin/orocos-rtt/commit/36b74eb1704cd0c9ebba573f0b...

> I have also applied your other pending win32 patches on rtt/ocl/log4cpp.
> The
> only issue was with the PluginLoader checking for the -target'd' suffix,
> since
> Stephen had also been patching that for filtering out the dylib loading on
> macos-x.
>
> I have RTT unit tests almost flawlessly running on win32 on the 2.4 branch
> so I
> think we're getting there. The next round is for macos-x fixing :-)
>

Ok thank you. I will look at it to make sure everything is merged and runs
fine here.

>
> See https://build.mech.kuleuven.be/jenkins/job/orocos-rtt-master-WinXP/
>
>
Nice Jenkins Jobs! I would be happy to have a screenshot of your Jenkins
configuration to see how to setup the unit tests for RTT. Did you had to
"make install" orocos-rtt to make sure that unit tests correctly finds all
DLLs?

Philippe

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by peter on Wed, 2011-06-15 16:40.

On Wednesday 15 June 2011 17:56:28 Philippe Hamelin wrote:
> 2011/6/15 Peter Soetens <peter [..] ...>
>
> > On Monday 13 June 2011 18:58:18 Philippe Hamelin wrote:
> > > 2011/6/9 Peter Soetens <peter [..] ...>
> > >
> > > > On Thu, Jun 9, 2011 at 4:26 PM, Philippe Hamelin
> > > >
> > > > <philippe [dot] hamelin [..] ...> wrote:
> > > > > 2011/6/9 S Roderick <kiwi [dot] net [..] ...>
> > > > >
> > > > >> On Jun 9, 2011, at 09:03 , Philippe Hamelin wrote:
> > > > >> > 2011/6/9 Peter Soetens <peter [..] ...>
> > > > >> >
> > > > >> > On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
> > > > >> > > 2011/6/7 Peter Soetens <peter [..] ...>
> > > > >> > >
> > > > >> > > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
> > > > >> > > >
> > > > >> > > > <philippe [dot] hamelin [..] ...> wrote:
> > > > >> > > > > Hello,
> > > > >> > > > > I'm having troubles integrating some orocos components in
> > > > >> > > > > my
> > > >
> > > > build
> > > >
> > > > >> > > > system. I
> > > > >> > > >
> > > > >> > > > > have a project with multiple targets where some are orocos
> > > > >> > > > > components.
> > > > >> > > >
> > > > >> > > > The
> > > > >> > > >
> > > > >> > > > > problem is that UseOrocos file forces the
> >
> > CMAKE_INSTALL_PREFIX
> >
> > > > to
> > > >
> > > > >> > > > C:\Program
> > > > >> > > >
> > > > >> > > > > Files\orocos. Here is the problematic snippet of the
> > > > >> > > > > UseOROCOS-RTT.cmake file:
> > > > >> > > > >

> > > > >> > > > > 
> > > > >> > > > >   # Detect user flag: install with orocos
> > > > >> > > > >   if (INSTALL_PATH STREQUAL "orocos")
> > > > >> > > > >   
> > > > >> > > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package
> > > > >> > > > >     installs
> > 
> > at
> > 
> > > > >> > > > > same
> > > > >> > > > 
> > > > >> > > > location
> > > > >> > > > 
> > > > >> > > > > as Orocos RTT." FORCE)
> > > > >> > > > > 
> > > > >> > > > >     mark_as_advanced(INSTALL_PATH)
> > > > >> > > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE
> > > > >> > > > >     PATH
> > > > >> > > > > 
> > > > >> > > > > "Package
> > > > >> > > > 
> > > > >> > > > install
> > > > >> > > > 
> > > > >> > > > > prefix forced by INSTALL_PATH" FORCE)
> > > > >> > > > > 
> > > > >> > > > >   else (INSTALL_PATH STREQUAL "orocos")
> > > > >> > > > >   
> > > > >> > > > >     if (WIN32)
> > > > >> > > > >     
> > > > >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package
> > 
> > installs
> > 
> > > > >> > > > >       at
> > > > >> > > > > 
> > > > >> > > > > same
> > > > >> > > > > 
> > > > >> > > > > location as Orocos RTT." FORCE)
> > > > >> > > > > 
> > > > >> > > > >       mark_as_advanced(INSTALL_PATH)
> > > > >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE
> > 
> > PATH
> > 
> > > > >> > > > > "Package
> > > > >> > > > > 
> > > > >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> > > > >> > > > > 
> > > > >> > > > >     endif (WIN32)
> > > > >> > > > >   
> > > > >> > > > >   endif (INSTALL_PATH STREQUAL "orocos")
> > > > >> > > > > 
> > > > >> > > > >

> > > > >> > > > > This leads to an important limitation: once you have an
> > > > >> > > >
> > > > >> > > > orocos component in
> > > > >> > > >
> > > > >> > > > > your project, your whole project will be installed in
> > > > >> > > > > C:\Program Files\orocos. Is there a particular reason why
> > > > >> > > > > this has been
> > > >
> > > > done
> > > >
> > > > >> > > > > so? I
> > > > >> > > > > would like to suggest to remove these lines:
> > > > >> > > > >

> > > > >> > > > > 
> > > > >> > > > >     if (WIN32)
> > > > >> > > > >     
> > > > >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package
> > 
> > installs
> > 
> > > > >> > > > >       at
> > > > >> > > > > 
> > > > >> > > > > same
> > > > >> > > > > 
> > > > >> > > > > location as Orocos RTT." FORCE)
> > > > >> > > > > 
> > > > >> > > > >       mark_as_advanced(INSTALL_PATH)
> > > > >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE
> > 
> > PATH
> > 
> > > > >> > > > > "Package
> > > > >> > > > > 
> > > > >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> > > > >> > > > > 
> > > > >> > > > >     endif (WIN32)
> > > > >> > > > > 
> > > > >> > > > >

> > > > >> > > > > Anyways, if someone want to install in the same folder as
> > > >
> > > > orocos,
> > > >
> > > > >> > > > > we
> > > > >> > > > > can always set the INSTALL_PATH to "orocos". If this is
> > > >
> > > > accepted,
> > > >
> > > > >> > > > > I
> > > > >> > > > > could
> > > > >> > > >
> > > > >> > > > bundle
> > > > >> > > >
> > > > >> > > > > this patch with the others I made for win32 some days ago.
> > > > >> > > > > Philippe
> > > > >> > > >
> > > > >> > > > The rationale was/is twofold:
> > > > >> > > > 1. on Windows, you prefer to install all build results of
> >
> > Orocos
> >
> > > > >> > > > MSVS
> > > > >> > > > projects in program files\orocos. This eases setting up the
> > > > >> > > > deployment
> > > > >> > > > component, plugin loader etc, since the RTT_COMPONENT_PATH
> > > > >> > > > is set
> > > >
> > > > to
> > > >
> > > > >> > > > that location by default
> > > > >> > > > 2. With orocreate-pkg and the UseOrocos.cmake macros, it's
> > > >
> > > > dead-easy
> > > >
> > > > >> > > > to create new packages and to depend on other packages (use
> > > > >> > > > their headers and link with their libs).So it's feasible to
> > > > >> > > > split
> > > >
> > > > software
> > > >
> > > > >> > > > in multiple, smaller packages. I don't know how well this
> >
> > works
> >
> > > > >> > > > on Windows though...
> > > > >> > > > 3. To have as much as possible out-of-the-box building, the
> > > >
> > > > standard
> > > >
> > > > >> > > > path for each of these package is set to the RTT
> > > > >> > > > installation
> > > >
> > > > path,
> > > >
> > > > >> > > > such that no extra cmake variable needs to be set, except
> >
> > where
> >
> > > > >> > > > to find RTT.
> > > > >> > > >
> > > > >> > > > That said, UseOrocos.cmake is not well tuned yet for win32
> > > > >> > > > usage...so
> > > > >> > > > any input/proposals is certainly welcome.
> > > > >> > > >
> > > > >> > > > But I would prefer the default 'install with rtt' still in
> > > > >> > > > action, but
> > > > >> > > > let it override at cmake-gui level or before you include the
> > > > >> > > > useorocos.cmake file.
> > > > >> > > >
> > > > >> > > > Peter
> > > > >> > >
> > > > >> > > I do not agree with all of the rationales since I prefer to
> > > >
> > > > separate
> > > >
> > > > >> > > orocos from the application-specific components. However, I
> > > > >> > > can live with
> > > > >> > > the default value of 'install with rtt'. Here is the logic we
> > > > >> > > could
> > > > >> >
> > > > >> > > have:
> > > > >> > I see your point...
> > > > >> >
> > > > >> > >

> > > > >> > > 
> > > > >> > >   # On win32, packages install at same location as Orocos by
> > > > >> > >   default if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > > > >> > > 
> > > > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> > > > >> > > 
> > > > >> > >     set (INSTALL_PATH "orocos")
> > > > >> > >   
> > > > >> > >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> > > > >> > > 
> > > > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> > > > >> > > 
> > > > >> > >   # Detect user flag: install with orocos
> > > > >> > >   if (INSTALL_PATH STREQUAL "orocos")
> > > > >> > >   
> > > > >> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> > > > >> > >     same
> > > > >> > > 
> > > > >> > > location as Orocos RTT." FORCE)
> > > > >> > > 
> > > > >> > >     mark_as_advanced(INSTALL_PATH)
> > > > >> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > > > >> > >     "Package
> > > > >> > > 
> > > > >> > > install prefix forced by INSTALL_PATH" FORCE)
> > > > >> > > 
> > > > >> > >   endif(INSTALL_PATH STREQUAL "orocos")
> > > > >> > > 
> > > > >> > >

> > > > >> > >
> > > > >> > > Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains
> > > > >> > > unchanged. On
> > > > >> > > win32, it defaults to "C:\Program Files\orocos" and someone
> > > > >> > > can disable
> > > > >> > > that behavior by just defining
> > > > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH.
> > > >
> > > > Also,
> > > >
> > > > >> > > I
> > > > >> > > think that the variable name INSTALL_PATH is a bit too general
> >
> > and
> >
> > > > may
> > > >
> > > > >> > > lead to conflicts when combining orocos with other cmake
> >
> > projects.
> >
> > > > >> > > Would
> > > > >> > > you care to rename it to something like ORO_INSTALL_PATH? If
> > > > >> > > you
> > > >
> > > > agree
> > > >
> > > > >> > > on
> > > > >> > > that I will then submit a patch.
> > > > >> >
> > > > >> > Maybe we can do even better/cleaner :-) I think part of this
> > > > >> > code
> > > >
> > > > exists
> > > >
> > > > >> > because at the time of writing, we were not aware of the
> > > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT cmake variable.
> > > > >> >
> > > > >> > What we could do is make this uniform for all platforms and
> > > > >> > write
> >
> > it
> >
> > > > >> > like
> > > > >> > this:
> > > > >> >
> > > > >> >

> > > > >> > 
> > > > >> >  # If cmake install prefix is default, use 'orocos' instead
> > > > >> >  if(NOT DEFINED INSTALL_PATH AND
> > > > >> > 
> > > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > > >> > 
> > > > >> >    set (INSTALL_PATH "orocos")
> > > > >> >  
> > > > >> >  endif()
> > > > >> >  
> > > > >> >  # Detect user flag: install with orocos
> > > > >> >  if (INSTALL_PATH STREQUAL "orocos")
> > > > >> >  
> > > > >> >    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> > > > >> >    same
> > > > >> > 
> > > > >> > location
> > > > >> > as Orocos RTT." FORCE)
> > > > >> > 
> > > > >> >    mark_as_advanced(INSTALL_PATH)
> > > > >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > 
> > "Package
> > 
> > > > >> > install
> > > > >> > prefix forced by INSTALL_PATH" FORCE)
> > > > >> > 
> > > > >> >  endif(INSTALL_PATH STREQUAL "orocos")
> > > > >> > 
> > > > >> >

> > > > >> >
> > > > >> > In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH,
> >
> > got
> >
> > > > >> > equal
> > > > >> > semantics for all targets and allow to set the INSTALL_PATH
> > > > >> > variable.
> > > >
> > > > A
> > > >
> > > > >> > next
> > > > >> > step would be to eliminate INSTALL_PATH all together and only
> > > > >> > rely on CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We
> > > > >> > would then
> > > >
> > > > take
> > > >
> > > > >> > 'orocos'
> > > > >> > as a special value:
> > > > >> >
> > > > >> >

> > > > >> > 
> > > > >> >  # If cmake install prefix is default, use 'orocos' instead
> > > > >> >  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR
> > > > 
> > > > CMAKE_INSTALL_PREFIX
> > > > 
> > > > >> > STREQUAL "orocos" )
> > > > >> > 
> > > > >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > 
> > "Package
> > 
> > > > >> > install
> > > > >> > prefix forced to RTT install prefix path." FORCE)
> > > > >> > 
> > > > >> >  endif()
> > > > >> > 
> > > > >> >

> > > > >> >
> > > > >> > We can deprecate INSTALL_PATH with some extra code but I doubt
> > > > >> > it
> >
> > is
> >
> > > > in
> > > >
> > > > >> > use
> > > > >> > actually, since it's undocumented.... what do you think ?
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > I also prefer to remove the INSTALL_PATH variable. However, the
> > > >
> > > > problem
> > > >
> > > > >> > is that I want to use the CMake default, which is C:\Program
> >
> > Files<
> >
> > > > >> > x86>\${PROJET_NAME}. In that case, the
> > > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable is set and
> >
> > the
> >
> > > > proposed
> > > >
> > > > >> > logic won't work. There is two reasons why I want to use the
> > > > >> > default:
> > > > >> >
> > > > >> > 1. It installs in a subfolder with the ${PROJECT_NAME} suffix
> > > > >> > 2. It has the logic to select either C:\Program
> > > > >> > Files\${PROJECT_NAME}
> > > >
> > > > or
> > > >
> > > > >> > C:\Program Files (x86)\${PROJECT_NAME}
> > > > >> >
> > > > >> > One workaround would be to set the CMAKE_INSTALL_PREFIX in the
> > > > >> > CMakeLists.txt before calling the project() macro so the
> > > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not set.
> > > > >> > However,
> >
> > I
> >
> > > > must
> > > >
> > > > >> > admit I really don't like this one because I would have to
> > > > >> > recode the
> > > >
> > > > CMake
> > > >
> > > > >> > logic to detect if I have to install in C:\Program Files\[...]
> > > > >> > or
> > > >
> > > > C:\Program
> > > >
> > > > >> > Files (x86)\[...]. There is a macro for that in CMake 2.8.3 that
> > > > >> > I
> > > >
> > > > could
> > > >
> > > > >> > use, but I would prefer to let CMake make the choice and then be
> > > >
> > > > compatible
> > > >
> > > > >> > with older versions of CMake.
> > > > >>
> > > > >> Are we just trying to support
> > > > >> - a default INSTALL location it none given
> > > > >
> > > > > Yes
> > > > >
> > > > >> - a method for the user to override the default INSTALL location
> > > > >> if none given (and optionally just use the CMake default)
> > > > >
> > > > > Yes
> > > > >
> > > > >> - (?) a method for the user to force the INSTALL location
> > > > >>
> > > > >> And this has to work on all supported platforms, or are you trying
> >
> > to
> >
> > > > >> do the above just for Windows?
> > > > >
> > > > > The current logic only forces the install path on Windows, but I
> >
> > think
> >
> > > > it's
> > > >
> > > > > a good idea to have a common logic for all platforms. The install
> > > > > prefix
> > > >
> > > > on
> > > >
> > > > > Linux is /usr/local by default anyways, so it should not break
> > > > > anything.
> > > >
> > > > On
> > > >
> > > > > windows, the project name is appended so this is more complex.
> > > > >
> > > > >> > The other workaround, which is more portable, would be to unset
> >
> > the
> >
> > > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT just after the
> >
> > project()
> >
> > > > macro.
> > > >
> > > > >> > Then, it will use the default CMAKE_INSTALL_PREFIX but the
> > > > >> > orocos
> > > >
> > > > macros
> > > >
> > > > >> > will think it's a custom value. What do you think about that?
> > > > >>
> > > > >> Which would break standard CMake behaviour, making it hard for
> > > > >> other people to figure out what is going on. I would not want
> > > > >> that as a project-wide default.
> > > > >
> > > > > I agree that this is a hack and it may breaks other cmake logic
> >
> > inside
> >
> > > > > projects.
> > > > > I think we will need to keep an additionnal CMake variable to
> >
> > configure
> >
> > > > the
> > > >
> > > > > install path. How about this logic:
> > > > >

> > > > > # The user should set the variable ORO_INSTALL_PREFIX to force the
> > > > > installation prefix of orocos components/plugins/...
> > > > > # If none is given, then the ORO_INSTALL_PREFIX is set to
> > > > > CMAKE_INSTALL_PREFIX if it's non-default
> > > > > # If both ORO_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX are not
> > > > > explicitly set, the installation prefix
> > > > > # is set to the Orocos-RTT directory.
> > > > > if(NOT ORO_INSTALL_PREFIX)
> > > > > 
> > > > >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > > >   
> > > > >     set(ORO_INSTALL_PREFIX "orocos")
> > > > >   
> > > > >   else(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > > >   
> > > > >     set(ORO_INSTALL_PREFIX CMAKE_PREFIX_PATH)
> > > > >   
> > > > >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > > > > 
> > > > > endif(NOT ORO_INSTALL_PREFIX)
> > > > > # Check for special case of ORO_INSTALL_PATH="orocos"
> > > > > if(ORO_INSTALL_PREFIX STREQUAL "orocos")
> > > > > 
> > > > >    set (ORO_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> > > > 
> > > > installs
> > > > 
> > > > > at same location as Orocos RTT." FORCE)
> > > > > 
> > > > >    mark_as_advanced(ORO_INSTALL_PATH)
> > > > 
> > > > typo here: ORO_INSTALL_PATH
> > > > 
> > > > > endif(ORO_INSTALL_PREFIX STREQUAL "orocos")
> > > > >

> > > > > I think we should not override the CMAKE_INSTALL_PREFIX variable
> >
> > since
> >
> > > > > it can break many things in other cmake projects. That's why I
> >
> > propose
> >
> > > > > that
> > > >
> > > > the
> > > >
> > > > > UseOROCOS-RTT macros should now use ORO_INSTALL_PATH to configure
> > > > > the
> > > >
> > > > full
> > > >
> > > > > install paths instead of using the CMAKE_INSTALL_PREFIX.
> > > >
> > > > I agree fully with your proposal. However, it will also require
> > > > updates to all the other orocos_
> > > > macros such that they use ORO_INSTALL_PREFIX instead of
> > > > CMAKE_INSTALL_PREFIX
> > >
> > > I made some tests regarding the proposed method and I'm getting the
> > > conclusion that the use of the
> >
> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT
> >
> > > isn't a good idea. The problem is that this variable is valid only for
> >
> > the
> >
> > > first cmake 'configure'. Indeed, during the first 'configure' of cmake,
> >
> > the
> >
> > > CMAKE_INSTALL_PREFIX is put into the cache and
> > > the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT if set to true if
> > > applicable. During the second 'configure', cmake detects that the
> > > CMAKE_INSTALL_PREFIX is already initialized by the user (reading it
> > > from cache) and thus unset
> > > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT. This leads to two
> > > limitations of the proposed method:
> > >
> > > 1. You must make sure that the UseOROCOS-RTT.cmake file is included in
> >
> > the
> >
> > > first cmake 'configure', otherwise the default 'orocos' install path
> > > will never be used.
> > >
> > > 2. If someone doesn't define it's own ORO_INSTALL_PREFIX, he can not
> >
> > change
> >
> > > the install path of orocos component after the first cmake 'configure',
> > > because the install path is put in the cache during the first
> >
> > 'configure'.
> >
> > > This mean that any modification of the CMAKE_INSTALL_PREFIX through the
> > > cmake-gui won't make any change to the orocos install path if this is
> > > not done before executing cmake for the first time.
> > >
> > > The initial goal wasn't to support different installation paths for
> >
> > targets
> >
> > > non related to orocos and those related to orocos. Also, the orocos
> >
> > macros
> >
> > > should always honor any modifications to the CMAKE_INSTALL_PREFIX
> >
> > variable.
> >
> > > It is now clear to me that this is not a good idea and it's difficult
> > > to have both CMAKE_INSTALL_PREFIX and ORO_INSTALL_PREFIX coexists.
> > > Anyway,
> >
> > the
> >
> > > actual behavior is really what we want, with the exception of one
> > > missing thing: be able to disable the overriding of the
> > > CMAKE_INSTALL_PREFIX by
> >
> > the
> >
> > > UseOROCOS-RTT.cmake file in order to use the default
> > > CMAKE_INSTALL_PREFIX value. Until we see the need to have a
> > > per-package installation logic or something more complex, we could
> > > just end with something like this:
> > >
> > >

> > > 
> > >   # On windows, the CMAKE_INSTALL_PREFIX is forced to the Orocos-RTT
> > 
> > path.
> > 
> > >   # There's two alternatives to disable this behavior:
> > >   #
> > >   # 1. Use the ORO_DEFAULT_INSTALL_PREFIX variable to modify the
> > >   default #    installation path:
> > >   #
> > >   #     set(ORO_DEFAULT_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
> > >   #     include(${OROCOS-RTT_USE_FILE_PATH}/UseOROCOS-RTT.cmake)
> > >   #
> > >   # 2. Force a non-default CMAKE_INSTALL_PREFIX prior to executing
> > >   cmake: #
> > >   #     cmake -DCMAKE_INSTALL_PREFIX="<your install prefix>" [...]
> > >   #
> > >   # In all cases, the Orocos macros will always honor any change to the
> > > 
> > > cached
> > > 
> > >   # CMAKE_INSTALL_PREFIX variable.
> > >   
> > >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
> > > 
> > > ORO_DEFAULT_INSTALL_PREFIX)
> > > 
> > >     if(WIN32)
> > >     
> > >         set(ORO_DEFAULT_INSTALL_PREFIX "orocos")
> > >     
> > >     endif(WIN32)
> > >   
> > >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
> > > 
> > > ORO_DEFAULT_INSTALL_PREFIX)
> > > 
> > >   if(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
> > >   
> > >     if(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
> > >     
> > >         set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> > >         "Install
> > > 
> > > prefix forced to orocos by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
> > > 
> > >     else(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
> > >     
> > >         set (CMAKE_INSTALL_PREFIX ${ORO_DEFAULT_INSTALL_PREFIX} CACHE
> > 
> > PATH
> > 
> > > "Install prefix forced by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
> > > 
> > >     endif(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
> > >   
> > >   endif(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
> > > 
> > >

> > >
> > > We still have the limitation that the UseOROCOS-RTT.cmake file still
> >
> > needs
> >
> > > to be included in the first cmake 'configure' so that
> > > the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable may be set to
> > > true.
> > >
> > > What do you think about that?
> >
> > My head is spinning from all this swinging :-)
> >
> > So you opt to not cache ORO_DEFAULT_INSTALL_PREFIX ... I'm happy with the
> > simpler solution and I can't think of a way that this will go wrong.
>
> Yes. You can find the patch here:
>
> https://github.com/phamelin/orocos-rtt/commit/36b74eb1704cd0c9ebba573f0b86e
> f25c40189ac
>
> > I have also applied your other pending win32 patches on rtt/ocl/log4cpp.
> >
> > The
> >
> > only issue was with the PluginLoader checking for the -target'd' suffix,
> > since
> > Stephen had also been patching that for filtering out the dylib loading
> > on macos-x.
> >
> > I have RTT unit tests almost flawlessly running on win32 on the 2.4
> > branch so I
> > think we're getting there. The next round is for macos-x fixing :-)
>
> Ok thank you. I will look at it to make sure everything is merged and runs
> fine here.
>
> > See https://build.mech.kuleuven.be/jenkins/job/orocos-rtt-master-WinXP/
>
> Nice Jenkins Jobs! I would be happy to have a screenshot of your Jenkins
> configuration to see how to setup the unit tests for RTT. Did you had to
> "make install" orocos-rtt to make sure that unit tests correctly finds all
> DLLs?

Yes, of course :-) My jenkins job looks like this (was extremely trial-and-
error):

echo PATH is: %PATH%
echo INCLUDE is: %INCLUDE%
echo LIB is: %LIB%
call "c:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat" x86
call "c:\Program Files\Microsoft Platform SDK\SetEnv.Cmd" /RETAIL
echo PATH is: %PATH%
echo INCLUDE is: %INCLUDE%
echo LIB is: %LIB%
echo on
set NameServiceIOR=corbaloc:iiop:vader:2809/NameService
 
REM generate project in Build dir
mkdir Build
rmdir /S /Q Install
cd Build
"c:\Program Files\CMake 2.8\bin\cmake.exe"  -G "Visual Studio 8 2005" -
DCMAKE_INSTALL_PREFIX="%WORKSPACE%\Install" "%WORKSPACE%" -DOS_NO_ASM=OFF -
DENABLE_TESTS=ON -DENABLE_CORBA=ON -DCORBA_IMPLEMENTATION=TAO
 
REM build all
msbuild.exe orocos-rtt.sln /p:VCBuildAdditionalOptions="/useenv" /t:ALL_BUILD 
/p:Configuration=Release
 
REM install -- only works on vcproj, not on .sln file.
msbuild.exe INSTALL.vcproj /p:VCBuildAdditionalOptions="/useenv" 
/p:Configuration=Release
 
REM run tests
set PATH=%PATH%;%WORKSPACE%\Install\bin;
%WORKSPACE%\Install\lib\orocos\win32\plugins
cd tests
REM ctest -C Release
cd release
rem FOR %%T IN ( *test.exe ) DO ( IF %%T neq main-test ( %%T --
output_format=XML --report_level=detailed --log_level=all --result_code=no > 
%%T-result.xml 2>&1 || echo -- Failed to run %%T ) )
FOR %%T IN ( *test.exe ) DO ( IF %%T neq main-test ( %%T --log_format=XML --
log_level=all --result_code=no > %%T-result.xml || echo -- Failed to run %%T ) 
)
 
REM remove not working result:
del corba-ipc-test.exe-result.xml main-test.exe-result.xml
 
exit 0

I cherry-picked&pushed the patches I missed too.

>
> Philippe

Peter

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by phamelin on Wed, 2011-06-15 16:12.

2011/6/15 Philippe Hamelin <philippe [dot] hamelin [..] ...>

> 2011/6/15 Peter Soetens <peter [..] ...>
>
>> On Monday 13 June 2011 18:58:18 Philippe Hamelin wrote:
>> > 2011/6/9 Peter Soetens <peter [..] ...>
>> >
>> > > On Thu, Jun 9, 2011 at 4:26 PM, Philippe Hamelin
>> > >
>> > > <philippe [dot] hamelin [..] ...> wrote:
>> > > > 2011/6/9 S Roderick <kiwi [dot] net [..] ...>
>> > > >
>> > > >> On Jun 9, 2011, at 09:03 , Philippe Hamelin wrote:
>> > > >> > 2011/6/9 Peter Soetens <peter [..] ...>
>> > > >> >
>> > > >> > On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
>> > > >> > > 2011/6/7 Peter Soetens <peter [..] ...>
>> > > >> > >
>> > > >> > > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
>> > > >> > > >
>> > > >> > > > <philippe [dot] hamelin [..] ...> wrote:
>> > > >> > > > > Hello,
>> > > >> > > > > I'm having troubles integrating some orocos components in
>> my
>> > >
>> > > build
>> > >
>> > > >> > > > system. I
>> > > >> > > >
>> > > >> > > > > have a project with multiple targets where some are orocos
>> > > >> > > > > components.
>> > > >> > > >
>> > > >> > > > The
>> > > >> > > >
>> > > >> > > > > problem is that UseOrocos file forces the
>> CMAKE_INSTALL_PREFIX
>> > >
>> > > to
>> > >
>> > > >> > > > C:\Program
>> > > >> > > >
>> > > >> > > > > Files\orocos. Here is the problematic snippet of the
>> > > >> > > > > UseOROCOS-RTT.cmake file:
>> > > >> > > > >

>> > > >> > > > >
>> > > >> > > > >   # Detect user flag: install with orocos
>> > > >> > > > >   if (INSTALL_PATH STREQUAL "orocos")
>> > > >> > > > >
>> > > >> > > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs
>> at
>> > > >> > > > >
>> > > >> > > > > same
>> > > >> > > >
>> > > >> > > > location
>> > > >> > > >
>> > > >> > > > > as Orocos RTT." FORCE)
>> > > >> > > > >
>> > > >> > > > >     mark_as_advanced(INSTALL_PATH)
>> > > >> > > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> > > >> > > > >
>> > > >> > > > > "Package
>> > > >> > > >
>> > > >> > > > install
>> > > >> > > >
>> > > >> > > > > prefix forced by INSTALL_PATH" FORCE)
>> > > >> > > > >
>> > > >> > > > >   else (INSTALL_PATH STREQUAL "orocos")
>> > > >> > > > >
>> > > >> > > > >     if (WIN32)
>> > > >> > > > >
>> > > >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package
>> installs
>> > > >> > > > >       at
>> > > >> > > > >
>> > > >> > > > > same
>> > > >> > > > >
>> > > >> > > > > location as Orocos RTT." FORCE)
>> > > >> > > > >
>> > > >> > > > >       mark_as_advanced(INSTALL_PATH)
>> > > >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE
>> PATH
>> > > >> > > > >
>> > > >> > > > > "Package
>> > > >> > > > >
>> > > >> > > > > install prefix forced by INSTALL_PATH" FORCE)
>> > > >> > > > >
>> > > >> > > > >     endif (WIN32)
>> > > >> > > > >
>> > > >> > > > >   endif (INSTALL_PATH STREQUAL "orocos")
>> > > >> > > > >
>> > > >> > > > >

>> > > >> > > > > This leads to an important limitation: once you have an
>> > > >> > > >
>> > > >> > > > orocos component in
>> > > >> > > >
>> > > >> > > > > your project, your whole project will be installed in
>> > > >> > > > > C:\Program Files\orocos. Is there a particular reason why
>> > > >> > > > > this has been
>> > >
>> > > done
>> > >
>> > > >> > > > > so? I
>> > > >> > > > > would like to suggest to remove these lines:
>> > > >> > > > >

>> > > >> > > > >
>> > > >> > > > >     if (WIN32)
>> > > >> > > > >
>> > > >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package
>> installs
>> > > >> > > > >       at
>> > > >> > > > >
>> > > >> > > > > same
>> > > >> > > > >
>> > > >> > > > > location as Orocos RTT." FORCE)
>> > > >> > > > >
>> > > >> > > > >       mark_as_advanced(INSTALL_PATH)
>> > > >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE
>> PATH
>> > > >> > > > >
>> > > >> > > > > "Package
>> > > >> > > > >
>> > > >> > > > > install prefix forced by INSTALL_PATH" FORCE)
>> > > >> > > > >
>> > > >> > > > >     endif (WIN32)
>> > > >> > > > >
>> > > >> > > > >

>> > > >> > > > > Anyways, if someone want to install in the same folder as
>> > >
>> > > orocos,
>> > >
>> > > >> > > > > we
>> > > >> > > > > can always set the INSTALL_PATH to "orocos". If this is
>> > >
>> > > accepted,
>> > >
>> > > >> > > > > I
>> > > >> > > > > could
>> > > >> > > >
>> > > >> > > > bundle
>> > > >> > > >
>> > > >> > > > > this patch with the others I made for win32 some days ago.
>> > > >> > > > > Philippe
>> > > >> > > >
>> > > >> > > > The rationale was/is twofold:
>> > > >> > > > 1. on Windows, you prefer to install all build results of
>> Orocos
>> > > >> > > > MSVS
>> > > >> > > > projects in program files\orocos. This eases setting up the
>> > > >> > > > deployment
>> > > >> > > > component, plugin loader etc, since the RTT_COMPONENT_PATH is
>> > > >> > > > set
>> > >
>> > > to
>> > >
>> > > >> > > > that location by default
>> > > >> > > > 2. With orocreate-pkg and the UseOrocos.cmake macros, it's
>> > >
>> > > dead-easy
>> > >
>> > > >> > > > to create new packages and to depend on other packages (use
>> > > >> > > > their headers and link with their libs).So it's feasible to
>> > > >> > > > split
>> > >
>> > > software
>> > >
>> > > >> > > > in multiple, smaller packages. I don't know how well this
>> works
>> > > >> > > > on Windows though...
>> > > >> > > > 3. To have as much as possible out-of-the-box building, the
>> > >
>> > > standard
>> > >
>> > > >> > > > path for each of these package is set to the RTT installation
>> > >
>> > > path,
>> > >
>> > > >> > > > such that no extra cmake variable needs to be set, except
>> where
>> > > >> > > > to find RTT.
>> > > >> > > >
>> > > >> > > > That said, UseOrocos.cmake is not well tuned yet for win32
>> > > >> > > > usage...so
>> > > >> > > > any input/proposals is certainly welcome.
>> > > >> > > >
>> > > >> > > > But I would prefer the default 'install with rtt' still in
>> > > >> > > > action, but
>> > > >> > > > let it override at cmake-gui level or before you include the
>> > > >> > > > useorocos.cmake file.
>> > > >> > > >
>> > > >> > > > Peter
>> > > >> > >
>> > > >> > > I do not agree with all of the rationales since I prefer to
>> > >
>> > > separate
>> > >
>> > > >> > > orocos from the application-specific components. However, I can
>> > > >> > > live with
>> > > >> > > the default value of 'install with rtt'. Here is the logic we
>> > > >> > > could
>> > > >> >
>> > > >> > > have:
>> > > >> > I see your point...
>> > > >> >
>> > > >> > >

>> > > >> > >
>> > > >> > >   # On win32, packages install at same location as Orocos by
>> > > >> > >   default if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
>> > > >> > >
>> > > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
>> > > >> > >
>> > > >> > >     set (INSTALL_PATH "orocos")
>> > > >> > >
>> > > >> > >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
>> > > >> > >
>> > > >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
>> > > >> > >
>> > > >> > >   # Detect user flag: install with orocos
>> > > >> > >   if (INSTALL_PATH STREQUAL "orocos")
>> > > >> > >
>> > > >> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
>> > > >> > >     same
>> > > >> > >
>> > > >> > > location as Orocos RTT." FORCE)
>> > > >> > >
>> > > >> > >     mark_as_advanced(INSTALL_PATH)
>> > > >> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> > > >> > >     "Package
>> > > >> > >
>> > > >> > > install prefix forced by INSTALL_PATH" FORCE)
>> > > >> > >
>> > > >> > >   endif(INSTALL_PATH STREQUAL "orocos")
>> > > >> > >
>> > > >> > >

>> > > >> > >
>> > > >> > > Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains
>> > > >> > > unchanged. On
>> > > >> > > win32, it defaults to "C:\Program Files\orocos" and someone can
>> > > >> > > disable
>> > > >> > > that behavior by just defining
>> ORO_DISABLE_DEFAULT_INSTALL_PATH.
>> > >
>> > > Also,
>> > >
>> > > >> > > I
>> > > >> > > think that the variable name INSTALL_PATH is a bit too general
>> and
>> > >
>> > > may
>> > >
>> > > >> > > lead to conflicts when combining orocos with other cmake
>> projects.
>> > > >> > > Would
>> > > >> > > you care to rename it to something like ORO_INSTALL_PATH? If
>> you
>> > >
>> > > agree
>> > >
>> > > >> > > on
>> > > >> > > that I will then submit a patch.
>> > > >> >
>> > > >> > Maybe we can do even better/cleaner :-) I think part of this code
>> > >
>> > > exists
>> > >
>> > > >> > because at the time of writing, we were not aware of the
>> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT cmake variable.
>> > > >> >
>> > > >> > What we could do is make this uniform for all platforms and write
>> it
>> > > >> > like
>> > > >> > this:
>> > > >> >
>> > > >> >

>> > > >> >
>> > > >> >  # If cmake install prefix is default, use 'orocos' instead
>> > > >> >  if(NOT DEFINED INSTALL_PATH AND
>> > > >> >
>> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> > > >> >
>> > > >> >    set (INSTALL_PATH "orocos")
>> > > >> >
>> > > >> >  endif()
>> > > >> >
>> > > >> >  # Detect user flag: install with orocos
>> > > >> >  if (INSTALL_PATH STREQUAL "orocos")
>> > > >> >
>> > > >> >    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
>> same
>> > > >> >
>> > > >> > location
>> > > >> > as Orocos RTT." FORCE)
>> > > >> >
>> > > >> >    mark_as_advanced(INSTALL_PATH)
>> > > >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> "Package
>> > > >> >
>> > > >> > install
>> > > >> > prefix forced by INSTALL_PATH" FORCE)
>> > > >> >
>> > > >> >  endif(INSTALL_PATH STREQUAL "orocos")
>> > > >> >
>> > > >> >

>> > > >> >
>> > > >> > In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH,
>> got
>> > > >> > equal
>> > > >> > semantics for all targets and allow to set the INSTALL_PATH
>> > > >> > variable.
>> > >
>> > > A
>> > >
>> > > >> > next
>> > > >> > step would be to eliminate INSTALL_PATH all together and only
>> rely
>> > > >> > on CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We would
>> > > >> > then
>> > >
>> > > take
>> > >
>> > > >> > 'orocos'
>> > > >> > as a special value:
>> > > >> >
>> > > >> >

>> > > >> >
>> > > >> >  # If cmake install prefix is default, use 'orocos' instead
>> > > >> >  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR
>> > >
>> > > CMAKE_INSTALL_PREFIX
>> > >
>> > > >> > STREQUAL "orocos" )
>> > > >> >
>> > > >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> "Package
>> > > >> >
>> > > >> > install
>> > > >> > prefix forced to RTT install prefix path." FORCE)
>> > > >> >
>> > > >> >  endif()
>> > > >> >
>> > > >> >

>> > > >> >
>> > > >> > We can deprecate INSTALL_PATH with some extra code but I doubt it
>> is
>> > >
>> > > in
>> > >
>> > > >> > use
>> > > >> > actually, since it's undocumented.... what do you think ?
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> > I also prefer to remove the INSTALL_PATH variable. However, the
>> > >
>> > > problem
>> > >
>> > > >> > is that I want to use the CMake default, which is C:\Program
>> Files<
>> > > >> > x86>\${PROJET_NAME}. In that case, the
>> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable is set and
>> the
>> > >
>> > > proposed
>> > >
>> > > >> > logic won't work. There is two reasons why I want to use the
>> > > >> > default:
>> > > >> >
>> > > >> > 1. It installs in a subfolder with the ${PROJECT_NAME} suffix
>> > > >> > 2. It has the logic to select either C:\Program
>> > > >> > Files\${PROJECT_NAME}
>> > >
>> > > or
>> > >
>> > > >> > C:\Program Files (x86)\${PROJECT_NAME}
>> > > >> >
>> > > >> > One workaround would be to set the CMAKE_INSTALL_PREFIX in the
>> > > >> > CMakeLists.txt before calling the project() macro so the
>> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not set. However,
>> I
>> > >
>> > > must
>> > >
>> > > >> > admit I really don't like this one because I would have to recode
>> > > >> > the
>> > >
>> > > CMake
>> > >
>> > > >> > logic to detect if I have to install in C:\Program Files\[...] or
>> > >
>> > > C:\Program
>> > >
>> > > >> > Files (x86)\[...]. There is a macro for that in CMake 2.8.3 that
>> I
>> > >
>> > > could
>> > >
>> > > >> > use, but I would prefer to let CMake make the choice and then be
>> > >
>> > > compatible
>> > >
>> > > >> > with older versions of CMake.
>> > > >>
>> > > >> Are we just trying to support
>> > > >> - a default INSTALL location it none given
>> > > >
>> > > > Yes
>> > > >
>> > > >> - a method for the user to override the default INSTALL location if
>> > > >> none given (and optionally just use the CMake default)
>> > > >
>> > > > Yes
>> > > >
>> > > >> - (?) a method for the user to force the INSTALL location
>> > > >>
>> > > >> And this has to work on all supported platforms, or are you trying
>> to
>> > > >> do the above just for Windows?
>> > > >
>> > > > The current logic only forces the install path on Windows, but I
>> think
>> > >
>> > > it's
>> > >
>> > > > a good idea to have a common logic for all platforms. The install
>> > > > prefix
>> > >
>> > > on
>> > >
>> > > > Linux is /usr/local by default anyways, so it should not break
>> > > > anything.
>> > >
>> > > On
>> > >
>> > > > windows, the project name is appended so this is more complex.
>> > > >
>> > > >> > The other workaround, which is more portable, would be to unset
>> the
>> > > >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT just after the
>> project()
>> > >
>> > > macro.
>> > >
>> > > >> > Then, it will use the default CMAKE_INSTALL_PREFIX but the orocos
>> > >
>> > > macros
>> > >
>> > > >> > will think it's a custom value. What do you think about that?
>> > > >>
>> > > >> Which would break standard CMake behaviour, making it hard for
>> other
>> > > >> people to figure out what is going on. I would not want that as a
>> > > >> project-wide default.
>> > > >
>> > > > I agree that this is a hack and it may breaks other cmake logic
>> inside
>> > > > projects.
>> > > > I think we will need to keep an additionnal CMake variable to
>> configure
>> > >
>> > > the
>> > >
>> > > > install path. How about this logic:
>> > > >

>> > > > # The user should set the variable ORO_INSTALL_PREFIX to force the
>> > > > installation prefix of orocos components/plugins/...
>> > > > # If none is given, then the ORO_INSTALL_PREFIX is set to
>> > > > CMAKE_INSTALL_PREFIX if it's non-default
>> > > > # If both ORO_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX are not
>> > > > explicitly set, the installation prefix
>> > > > # is set to the Orocos-RTT directory.
>> > > > if(NOT ORO_INSTALL_PREFIX)
>> > > >
>> > > >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> > > >
>> > > >     set(ORO_INSTALL_PREFIX "orocos")
>> > > >
>> > > >   else(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> > > >
>> > > >     set(ORO_INSTALL_PREFIX CMAKE_PREFIX_PATH)
>> > > >
>> > > >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> > > >
>> > > > endif(NOT ORO_INSTALL_PREFIX)
>> > > > # Check for special case of ORO_INSTALL_PATH="orocos"
>> > > > if(ORO_INSTALL_PREFIX STREQUAL "orocos")
>> > > >
>> > > >    set (ORO_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
>> > >
>> > > installs
>> > >
>> > > > at same location as Orocos RTT." FORCE)
>> > > >
>> > > >    mark_as_advanced(ORO_INSTALL_PATH)
>> > >
>> > > typo here: ORO_INSTALL_PATH
>> > >
>> > > > endif(ORO_INSTALL_PREFIX STREQUAL "orocos")
>> > > >

>> > > > I think we should not override the CMAKE_INSTALL_PREFIX variable
>> since
>> > > > it can break many things in other cmake projects. That's why I
>> propose
>> > > > that
>> > >
>> > > the
>> > >
>> > > > UseOROCOS-RTT macros should now use ORO_INSTALL_PATH to configure
>> the
>> > >
>> > > full
>> > >
>> > > > install paths instead of using the CMAKE_INSTALL_PREFIX.
>> > >
>> > > I agree fully with your proposal. However, it will also require
>> > > updates to all the other orocos_
>> > > macros such that they use ORO_INSTALL_PREFIX instead of
>> > > CMAKE_INSTALL_PREFIX
>> >
>> > I made some tests regarding the proposed method and I'm getting the
>> > conclusion that the use of the
>> CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT
>> > isn't a good idea. The problem is that this variable is valid only for
>> the
>> > first cmake 'configure'. Indeed, during the first 'configure' of cmake,
>> the
>> > CMAKE_INSTALL_PREFIX is put into the cache and
>> > the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT if set to true if
>> > applicable. During the second 'configure', cmake detects that the
>> > CMAKE_INSTALL_PREFIX is already initialized by the user (reading it from
>> > cache) and thus unset CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT. This
>> > leads to two limitations of the proposed method:
>> >
>> > 1. You must make sure that the UseOROCOS-RTT.cmake file is included in
>> the
>> > first cmake 'configure', otherwise the default 'orocos' install path
>> will
>> > never be used.
>> >
>> > 2. If someone doesn't define it's own ORO_INSTALL_PREFIX, he can not
>> change
>> > the install path of orocos component after the first cmake 'configure',
>> > because the install path is put in the cache during the first
>> 'configure'.
>> > This mean that any modification of the CMAKE_INSTALL_PREFIX through the
>> > cmake-gui won't make any change to the orocos install path if this is
>> not
>> > done before executing cmake for the first time.
>> >
>> > The initial goal wasn't to support different installation paths for
>> targets
>> > non related to orocos and those related to orocos. Also, the orocos
>> macros
>> > should always honor any modifications to the CMAKE_INSTALL_PREFIX
>> variable.
>> > It is now clear to me that this is not a good idea and it's difficult to
>> > have both CMAKE_INSTALL_PREFIX and ORO_INSTALL_PREFIX coexists. Anyway,
>> the
>> > actual behavior is really what we want, with the exception of one
>> missing
>> > thing: be able to disable the overriding of the CMAKE_INSTALL_PREFIX by
>> the
>> > UseOROCOS-RTT.cmake file in order to use the default
>> CMAKE_INSTALL_PREFIX
>> > value. Until we see the need to have a per-package installation logic or
>> > something more complex, we could just end with something like this:
>> >
>> >

>> >   # On windows, the CMAKE_INSTALL_PREFIX is forced to the Orocos-RTT
>> path.
>> >   # There's two alternatives to disable this behavior:
>> >   #
>> >   # 1. Use the ORO_DEFAULT_INSTALL_PREFIX variable to modify the default
>> >   #    installation path:
>> >   #
>> >   #     set(ORO_DEFAULT_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
>> >   #     include(${OROCOS-RTT_USE_FILE_PATH}/UseOROCOS-RTT.cmake)
>> >   #
>> >   # 2. Force a non-default CMAKE_INSTALL_PREFIX prior to executing
>> cmake:
>> >   #
>> >   #     cmake -DCMAKE_INSTALL_PREFIX="<your install prefix>" [...]
>> >   #
>> >   # In all cases, the Orocos macros will always honor any change to the
>> > cached
>> >   # CMAKE_INSTALL_PREFIX variable.
>> >
>> >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
>> > ORO_DEFAULT_INSTALL_PREFIX)
>> >     if(WIN32)
>> >         set(ORO_DEFAULT_INSTALL_PREFIX "orocos")
>> >     endif(WIN32)
>> >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND NOT DEFINED
>> > ORO_DEFAULT_INSTALL_PREFIX)
>> >
>> >   if(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
>> >     if(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
>> >         set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Install
>> > prefix forced to orocos by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
>> >     else(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
>> >         set (CMAKE_INSTALL_PREFIX ${ORO_DEFAULT_INSTALL_PREFIX} CACHE
>> PATH
>> > "Install prefix forced by ORO_DEFAULT_INSTALL_PREFIX" FORCE)
>> >     endif(ORO_DEFAULT_INSTALL_PREFIX STREQUAL "orocos")
>> >   endif(DEFINED ORO_DEFAULT_INSTALL_PREFIX)
>> >

>> >
>> > We still have the limitation that the UseOROCOS-RTT.cmake file still
>> needs
>> > to be included in the first cmake 'configure' so that
>> > the CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable may be set to
>> > true.
>> >
>> > What do you think about that?
>>
>> My head is spinning from all this swinging :-)
>>
>> So you opt to not cache ORO_DEFAULT_INSTALL_PREFIX ... I'm happy with the
>> simpler solution and I can't think of a way that this will go wrong.
>>
>>
> Yes. You can find the patch here:
>
>
> https://github.com/phamelin/orocos-rtt/commit/36b74eb1704cd0c9ebba573f0b...
>
>

You may also apply the patch for the installation path on windows 64 bits:

https://github.com/phamelin/orocos-rtt/commit/ac2803910ef85b89c1ac0cca7d...

Philippe

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by phamelin on Thu, 2011-06-09 18:04.

2011/6/9 Peter Soetens <peter [..] ...>

> >> > > > >
> >> > > > >   # Detect user flag: install with orocos
> >> > > > >   if (INSTALL_PATH STREQUAL "orocos")
> >> > > > >
> >> > > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> >> > > > > same
> >> > > >
> >> > > > location
> >> > > >
> >> > > > > as Orocos RTT." FORCE)
> >> > > > >
> >> > > > >     mark_as_advanced(INSTALL_PATH)
> >> > > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> >> > > > > "Package
> >> > > >
> >> > > > install
> >> > > >
> >> > > > > prefix forced by INSTALL_PATH" FORCE)
> >> > > > >
> >> > > > >   else (INSTALL_PATH STREQUAL "orocos")
> >> > > > >
> >> > > > >     if (WIN32)
> >> > > > >
> >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> >> > > > > same
> >> > > > >
> >> > > > > location as Orocos RTT." FORCE)
> >> > > > >
> >> > > > >       mark_as_advanced(INSTALL_PATH)
> >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> >> > > > > "Package
> >> > > > >
> >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> >> > > > >
> >> > > > >     endif (WIN32)
> >> > > > >
> >> > > > >   endif (INSTALL_PATH STREQUAL "orocos")
> >> > > > >
> >> > > > >

> >> > > > >
> >> > > > >     if (WIN32)
> >> > > > >
> >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
> >> > > > > same
> >> > > > >
> >> > > > > location as Orocos RTT." FORCE)
> >> > > > >
> >> > > > >       mark_as_advanced(INSTALL_PATH)
> >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
> >> > > > > "Package
> >> > > > >
> >> > > > > install prefix forced by INSTALL_PATH" FORCE)
> >> > > > >
> >> > > > >     endif (WIN32)
> >> > > > >
> >> > > > >

> >> > >   # On win32, packages install at same location as Orocos by default
> >> > >   if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> >> > >     set (INSTALL_PATH "orocos")
> >> > >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
> >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
> >> > >
> >> > >   # Detect user flag: install with orocos
> >> > >   if (INSTALL_PATH STREQUAL "orocos")
> >> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> >> > > location as Orocos RTT." FORCE)
> >> > >     mark_as_advanced(INSTALL_PATH)
> >> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> >> > > install prefix forced by INSTALL_PATH" FORCE)
> >> > >   endif(INSTALL_PATH STREQUAL "orocos")
> >> > >

> >> >  # If cmake install prefix is default, use 'orocos' instead
> >> >  if(NOT DEFINED INSTALL_PATH AND
> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> >> >    set (INSTALL_PATH "orocos")
> >> >  endif()
> >> >
> >> >  # Detect user flag: install with orocos
> >> >  if (INSTALL_PATH STREQUAL "orocos")
> >> >    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
> >> > location
> >> > as Orocos RTT." FORCE)
> >> >    mark_as_advanced(INSTALL_PATH)
> >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> >> > install
> >> > prefix forced by INSTALL_PATH" FORCE)
> >> >  endif(INSTALL_PATH STREQUAL "orocos")
> >> >

> >> >  # If cmake install prefix is default, use 'orocos' instead
> >> >  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR
> CMAKE_INSTALL_PREFIX
> >> > STREQUAL "orocos" )
> >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> >> > install
> >> > prefix forced to RTT install prefix path." FORCE)
> >> >  endif()
> >> >

> > # The user should set the variable ORO_INSTALL_PREFIX to force the
> > installation prefix of orocos components/plugins/...
> > # If none is given, then the ORO_INSTALL_PREFIX is set to
> > CMAKE_INSTALL_PREFIX if it's non-default
> > # If both ORO_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX are not explicitly
> > set, the installation prefix
> > # is set to the Orocos-RTT directory.
> > if(NOT ORO_INSTALL_PREFIX)
> >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> >     set(ORO_INSTALL_PREFIX "orocos")
> >   else(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> >     set(ORO_INSTALL_PREFIX CMAKE_PREFIX_PATH)
> >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
> > endif(NOT ORO_INSTALL_PREFIX)
> > # Check for special case of ORO_INSTALL_PATH="orocos"
> > if(ORO_INSTALL_PREFIX STREQUAL "orocos")
> >    set (ORO_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
> installs
> > at same location as Orocos RTT." FORCE)
> >    mark_as_advanced(ORO_INSTALL_PATH)
>
> typo here: ORO_INSTALL_PATH
>
> > endif(ORO_INSTALL_PREFIX STREQUAL "orocos")
> >

Philippe

Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32

Submitted by phamelin on Fri, 2011-06-10 17:52.

2011/6/9 Philippe Hamelin <philippe [dot] hamelin [..] ...>

> 2011/6/9 Peter Soetens <peter [..] ...>
>
>> On Thu, Jun 9, 2011 at 4:26 PM, Philippe Hamelin
>> <philippe [dot] hamelin [..] ...> wrote:
>> > 2011/6/9 S Roderick <kiwi [dot] net [..] ...>
>> >>
>> >> On Jun 9, 2011, at 09:03 , Philippe Hamelin wrote:
>> >>
>> >> > 2011/6/9 Peter Soetens <peter [..] ...>
>> >> > On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
>> >> > > 2011/6/7 Peter Soetens <peter [..] ...>
>> >> > >
>> >> > > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
>> >> > > >
>> >> > > > <philippe [dot] hamelin [..] ...> wrote:
>> >> > > > > Hello,
>> >> > > > > I'm having troubles integrating some orocos components in my
>> build
>> >> > > >
>> >> > > > system. I
>> >> > > >
>> >> > > > > have a project with multiple targets where some are orocos
>> >> > > > > components.
>> >> > > >
>> >> > > > The
>> >> > > >
>> >> > > > > problem is that UseOrocos file forces the CMAKE_INSTALL_PREFIX
>> to
>> >> > > >
>> >> > > > C:\Program
>> >> > > >
>> >> > > > > Files\orocos. Here is the problematic snippet of the
>> >> > > > > UseOROCOS-RTT.cmake file:
>> >> > > > >

>> >> > > > >
>> >> > > > >   # Detect user flag: install with orocos
>> >> > > > >   if (INSTALL_PATH STREQUAL "orocos")
>> >> > > > >
>> >> > > > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at
>> >> > > > > same
>> >> > > >
>> >> > > > location
>> >> > > >
>> >> > > > > as Orocos RTT." FORCE)
>> >> > > > >
>> >> > > > >     mark_as_advanced(INSTALL_PATH)
>> >> > > > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> >> > > > > "Package
>> >> > > >
>> >> > > > install
>> >> > > >
>> >> > > > > prefix forced by INSTALL_PATH" FORCE)
>> >> > > > >
>> >> > > > >   else (INSTALL_PATH STREQUAL "orocos")
>> >> > > > >
>> >> > > > >     if (WIN32)
>> >> > > > >
>> >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs
>> at
>> >> > > > > same
>> >> > > > >
>> >> > > > > location as Orocos RTT." FORCE)
>> >> > > > >
>> >> > > > >       mark_as_advanced(INSTALL_PATH)
>> >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> >> > > > > "Package
>> >> > > > >
>> >> > > > > install prefix forced by INSTALL_PATH" FORCE)
>> >> > > > >
>> >> > > > >     endif (WIN32)
>> >> > > > >
>> >> > > > >   endif (INSTALL_PATH STREQUAL "orocos")
>> >> > > > >
>> >> > > > >

>> >> > > > > This leads to an important limitation: once you have an
>> >> > > >
>> >> > > > orocos component in
>> >> > > >
>> >> > > > > your project, your whole project will be installed in
>> C:\Program
>> >> > > > > Files\orocos. Is there a particular reason why this has been
>> done
>> >> > > > > so? I
>> >> > > > > would like to suggest to remove these lines:
>> >> > > > >

>> >> > > > >
>> >> > > > >     if (WIN32)
>> >> > > > >
>> >> > > > >       set (INSTALL_PATH "orocos" CACHE PATH "Package installs
>> at
>> >> > > > > same
>> >> > > > >
>> >> > > > > location as Orocos RTT." FORCE)
>> >> > > > >
>> >> > > > >       mark_as_advanced(INSTALL_PATH)
>> >> > > > >       set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> >> > > > > "Package
>> >> > > > >
>> >> > > > > install prefix forced by INSTALL_PATH" FORCE)
>> >> > > > >
>> >> > > > >     endif (WIN32)
>> >> > > > >
>> >> > > > >

>> >> > > > > Anyways, if someone want to install in the same folder as
>> orocos,
>> >> > > > > we
>> >> > > > > can always set the INSTALL_PATH to "orocos". If this is
>> accepted,
>> >> > > > > I
>> >> > > > > could
>> >> > > >
>> >> > > > bundle
>> >> > > >
>> >> > > > > this patch with the others I made for win32 some days ago.
>> >> > > > > Philippe
>> >> > > >
>> >> > > > The rationale was/is twofold:
>> >> > > > 1. on Windows, you prefer to install all build results of Orocos
>> >> > > > MSVS
>> >> > > > projects in program files\orocos. This eases setting up the
>> >> > > > deployment
>> >> > > > component, plugin loader etc, since the RTT_COMPONENT_PATH is set
>> to
>> >> > > > that location by default
>> >> > > > 2. With orocreate-pkg and the UseOrocos.cmake macros, it's
>> dead-easy
>> >> > > > to create new packages and to depend on other packages (use their
>> >> > > > headers and link with their libs).So it's feasible to split
>> software
>> >> > > > in multiple, smaller packages. I don't know how well this works
>> on
>> >> > > > Windows though...
>> >> > > > 3. To have as much as possible out-of-the-box building, the
>> standard
>> >> > > > path for each of these package is set to the RTT installation
>> path,
>> >> > > > such that no extra cmake variable needs to be set, except where
>> to
>> >> > > > find RTT.
>> >> > > >
>> >> > > > That said, UseOrocos.cmake is not well tuned yet for win32
>> >> > > > usage...so
>> >> > > > any input/proposals is certainly welcome.
>> >> > > >
>> >> > > > But I would prefer the default 'install with rtt' still in
>> action,
>> >> > > > but
>> >> > > > let it override at cmake-gui level or before you include the
>> >> > > > useorocos.cmake file.
>> >> > > >
>> >> > > > Peter
>> >> > >
>> >> > > I do not agree with all of the rationales since I prefer to
>> separate
>> >> > > orocos from the application-specific components. However, I can
>> live
>> >> > > with
>> >> > > the default value of 'install with rtt'. Here is the logic we could
>> >> > > have:
>> >> >
>> >> > I see your point...
>> >> >
>> >> > >
>> >> > >

>> >> > >   # On win32, packages install at same location as Orocos by
>> default
>> >> > >   if(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
>> >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
>> >> > >     set (INSTALL_PATH "orocos")
>> >> > >   endif(NOT DEFINED INSTALL_PATH AND WIN32 AND NOT
>> >> > > ORO_DISABLE_DEFAULT_INSTALL_PATH)
>> >> > >
>> >> > >   # Detect user flag: install with orocos
>> >> > >   if (INSTALL_PATH STREQUAL "orocos")
>> >> > >     set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
>> >> > > location as Orocos RTT." FORCE)
>> >> > >     mark_as_advanced(INSTALL_PATH)
>> >> > >     set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH
>> "Package
>> >> > > install prefix forced by INSTALL_PATH" FORCE)
>> >> > >   endif(INSTALL_PATH STREQUAL "orocos")
>> >> > >

>> >> > >
>> >> > > Then, on non-win32 platforms CMAKE_INSTALL_PREFIX remains
>> unchanged.
>> >> > > On
>> >> > > win32, it defaults to "C:\Program Files\orocos" and someone can
>> >> > > disable
>> >> > > that behavior by just defining ORO_DISABLE_DEFAULT_INSTALL_PATH.
>> Also,
>> >> > > I
>> >> > > think that the variable name INSTALL_PATH is a bit too general and
>> may
>> >> > > lead to conflicts when combining orocos with other cmake projects.
>> >> > > Would
>> >> > > you care to rename it to something like ORO_INSTALL_PATH? If you
>> agree
>> >> > > on
>> >> > > that I will then submit a patch.
>> >> >
>> >> > Maybe we can do even better/cleaner :-) I think part of this code
>> exists
>> >> > because at the time of writing, we were not aware of the
>> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT cmake variable.
>> >> >
>> >> > What we could do is make this uniform for all platforms and write it
>> >> > like
>> >> > this:
>> >> >
>> >> >

>> >> >  # If cmake install prefix is default, use 'orocos' instead
>> >> >  if(NOT DEFINED INSTALL_PATH AND
>> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> >> >    set (INSTALL_PATH "orocos")
>> >> >  endif()
>> >> >
>> >> >  # Detect user flag: install with orocos
>> >> >  if (INSTALL_PATH STREQUAL "orocos")
>> >> >    set (INSTALL_PATH "orocos" CACHE PATH "Package installs at same
>> >> > location
>> >> > as Orocos RTT." FORCE)
>> >> >    mark_as_advanced(INSTALL_PATH)
>> >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
>> >> > install
>> >> > prefix forced by INSTALL_PATH" FORCE)
>> >> >  endif(INSTALL_PATH STREQUAL "orocos")
>> >> >

>> >> >
>> >> > In this way we eliminated the ORO_DISABLE_DEFAULT_INSTALL_PATH, got
>> >> > equal
>> >> > semantics for all targets and allow to set the INSTALL_PATH variable.
>> A
>> >> > next
>> >> > step would be to eliminate INSTALL_PATH all together and only rely on
>> >> > CMAKE_INSTALL_PREFIX, the 'official' cmake variable. We would then
>> take
>> >> > 'orocos'
>> >> > as a special value:
>> >> >
>> >> >

>> >> >  # If cmake install prefix is default, use 'orocos' instead
>> >> >  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT OR
>> CMAKE_INSTALL_PREFIX
>> >> > STREQUAL "orocos" )
>> >> >    set (CMAKE_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
>> >> > install
>> >> > prefix forced to RTT install prefix path." FORCE)
>> >> >  endif()
>> >> >

>> >> >
>> >> > We can deprecate INSTALL_PATH with some extra code but I doubt it is
>> in
>> >> > use
>> >> > actually, since it's undocumented.... what do you think ?
>> >> >
>> >> >
>> >> >
>> >> > I also prefer to remove the INSTALL_PATH variable. However, the
>> problem
>> >> > is that I want to use the CMake default, which is C:\Program Files<
>> >> > x86>\${PROJET_NAME}. In that case, the
>> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable is set and the
>> proposed
>> >> > logic won't work. There is two reasons why I want to use the default:
>> >> >
>> >> > 1. It installs in a subfolder with the ${PROJECT_NAME} suffix
>> >> > 2. It has the logic to select either C:\Program Files\${PROJECT_NAME}
>> or
>> >> > C:\Program Files (x86)\${PROJECT_NAME}
>> >> >
>> >> > One workaround would be to set the CMAKE_INSTALL_PREFIX in the
>> >> > CMakeLists.txt before calling the project() macro so the
>> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not set. However, I
>> must
>> >> > admit I really don't like this one because I would have to recode the
>> CMake
>> >> > logic to detect if I have to install in C:\Program Files\[...] or
>> C:\Program
>> >> > Files (x86)\[...]. There is a macro for that in CMake 2.8.3 that I
>> could
>> >> > use, but I would prefer to let CMake make the choice and then be
>> compatible
>> >> > with older versions of CMake.
>> >>
>> >> Are we just trying to support
>> >> - a default INSTALL location it none given
>> >
>> > Yes
>> >
>> >>
>> >> - a method for the user to override the default INSTALL location if
>> none
>> >> given (and optionally just use the CMake default)
>> >
>> > Yes
>> >
>> >>
>> >> - (?) a method for the user to force the INSTALL location
>> >>
>> >> And this has to work on all supported platforms, or are you trying to
>> do
>> >> the above just for Windows?
>> >>
>> >
>> > The current logic only forces the install path on Windows, but I think
>> it's
>> > a good idea to have a common logic for all platforms. The install prefix
>> on
>> > Linux is /usr/local by default anyways, so it should not break anything.
>> On
>> > windows, the project name is appended so this is more complex.
>> >
>> >>
>> >> > The other workaround, which is more portable, would be to unset the
>> >> > CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT just after the project()
>> macro.
>> >> > Then, it will use the default CMAKE_INSTALL_PREFIX but the orocos
>> macros
>> >> > will think it's a custom value. What do you think about that?
>> >>
>> >> Which would break standard CMake behaviour, making it hard for other
>> >> people to figure out what is going on. I would not want that as a
>> >> project-wide default.
>> >>
>> >
>> > I agree that this is a hack and it may breaks other cmake logic inside
>> > projects.
>> > I think we will need to keep an additionnal CMake variable to configure
>> the
>> > install path. How about this logic:
>> >

>> > # The user should set the variable ORO_INSTALL_PREFIX to force the
>> > installation prefix of orocos components/plugins/...
>> > # If none is given, then the ORO_INSTALL_PREFIX is set to
>> > CMAKE_INSTALL_PREFIX if it's non-default
>> > # If both ORO_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX are not explicitly
>> > set, the installation prefix
>> > # is set to the Orocos-RTT directory.
>> > if(NOT ORO_INSTALL_PREFIX)
>> >   if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> >     set(ORO_INSTALL_PREFIX "orocos")
>> >   else(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> >     set(ORO_INSTALL_PREFIX CMAKE_PREFIX_PATH)
>> >   endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> > endif(NOT ORO_INSTALL_PREFIX)
>> > # Check for special case of ORO_INSTALL_PATH="orocos"
>> > if(ORO_INSTALL_PREFIX STREQUAL "orocos")
>> >    set (ORO_INSTALL_PREFIX ${OROCOS-RTT_PATH} CACHE PATH "Package
>> installs
>> > at same location as Orocos RTT." FORCE)
>> >    mark_as_advanced(ORO_INSTALL_PATH)
>>
>> typo here: ORO_INSTALL_PATH
>>
>> > endif(ORO_INSTALL_PREFIX STREQUAL "orocos")
>> >

>> > I think we should not override the CMAKE_INSTALL_PREFIX variable since
>> it
>> > can break many things in other cmake projects. That's why I propose that
>> the
>> > UseOROCOS-RTT macros should now use ORO_INSTALL_PATH to configure the
>> full
>> > install paths instead of using the CMAKE_INSTALL_PREFIX.
>>
>> I agree fully with your proposal. However, it will also require
>> updates to all the other orocos_
>> macros such that they use ORO_INSTALL_PREFIX instead of
>> CMAKE_INSTALL_PREFIX
>>
>>
> Ok then I will try to send a patch at the middle of the next week.
>
>
>
I'm currently preparing this patch and I'm facing a problem. When components
aren't install with orocos, what should be the INSTALL_RPATH? Also, what
should it be when the user provide the INSTALL extra parameter to the
orocos_component macro?

It was currently set to :

${CMAKE_INSTALL_PREFIX}/lib/orocos${OROCOS_SUFFIX};${CMAKE_INSTALL_PREFIX}/lib;${CMAKE_INSTALL_PREFIX}/${AC_INSTALL_DIR}

In my opinion, that only makes sense if CMAKE_INSTALL_PREFIX
= OROCOS-RTT_PATH. Also, please tell me if I'm wrong, but the only RPATH a
component may have is the path where the Orocos-RTT libraries are installed
(not the components). What do you think about changing all INSTALL_RPATH in
UseOROCOS-RTT.cmake with ${OROCOS-RTT_PATH}/lib ?

Philippe