[prev in list] [next in list] [prev in thread] [next in thread]
List: orocos-dev
Subject: [Orocos-Dev] Overriding CMAKE_INSTALL_PREFIX in UseOrocos on win32
From: peter () thesourceworks ! com (Peter Soetens)
Date: 2011-06-15 16:36:46
Message-ID: 201106151836.47136.peter () thesourceworks ! com
[Download RAW message or body]
On Wednesday 15 June 2011 17:56:28 Philippe Hamelin wrote:
> 2011/6/15 Peter Soetens <peter at thesourceworks.com>
>
> > On Monday 13 June 2011 18:58:18 Philippe Hamelin wrote:
> > > 2011/6/9 Peter Soetens <peter at thesourceworks.com>
> > >
> > > > On Thu, Jun 9, 2011 at 4:26 PM, Philippe Hamelin
> > > >
> > > > <philippe.hamelin at gmail.com> wrote:
> > > > > 2011/6/9 S Roderick <kiwi.net at mac.com>
> > > > >
> > > > >> On Jun 9, 2011, at 09:03 , Philippe Hamelin wrote:
> > > > >> > 2011/6/9 Peter Soetens <peter at thesourceworks.com>
> > > > >> >
> > > > >> > On Wednesday 08 June 2011 15:13:06 Philippe Hamelin wrote:
> > > > >> > > 2011/6/7 Peter Soetens <peter at thesourceworks.com>
> > > > >> > >
> > > > >> > > > On Tue, Jun 7, 2011 at 9:50 PM, Philippe Hamelin
> > > > >> > > >
> > > > >> > > > <philippe.hamelin at gmail.com> 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:
> > > > >> > > > > <code>
> > > > >> > > > >
> > > > >> > > > > # 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")
> > > > >> > > > >
> > > > >> > > > > </code>
> > > > >> > > > > 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:
> > > > >> > > > > <code>
> > > > >> > > > >
> > > > >> > > > > 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)
> > > > >> > > > >
> > > > >> > > > > </code>
> > > > >> > > > > 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...
> > > > >> >
> > > > >> > > <code>
> > > > >> > >
> > > > >> > > # 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")
> > > > >> > >
> > > > >> > > </code>
> > > > >> > >
> > > > >> > > 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:
> > > > >> >
> > > > >> > <code>
> > > > >> >
> > > > >> > # 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")
> > > > >> >
> > > > >> > </code>
> > > > >> >
> > > > >> > 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:
> > > > >> >
> > > > >> > <code>
> > > > >> >
> > > > >> > # 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()
> > > > >> >
> > > > >> > </code>
> > > > >> >
> > > > >> > 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:
> > > > > <code>
> > > > > # 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")
> > > > > </code>
> > > > > 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:
> > >
> > > <code>
> > >
> > > # 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)
> > >
> > > </code>
> > >
> > > 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):
<code>
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
</code>
I cherry-picked&pushed the patches I missed too.
>
> Philippe
Peter
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic