Re: [CMake] Forcing CMake to never search install path
> I've been struggling to find a way to prevent CMake from using > CMAKE_INSTALL_PREFIX in any of its FIND_* routines. Generally > speaking, stripping it out of CMAKE_SYSTEM_PREFIX_PATH seems to work, > but we're still getting situations on Windows where it is finding old > libraries from previous program installs. I've tried ensuring all of > the CMAKE_SYSTEM_*_PATH variables are stripped, but that doesn't seem > to make a difference. > > Is there a mechanism I can use to specify to CMake to NEVER search in > a given path, excluding it from all FIND_* routine searches? It is > very typical in our development process to have older builds installed > and be building newer versions at the same time, so we really need a > good solid way to make sure previously built libraries aren't picked > up by FIND routines. > Not that I have a solution however I too am looking to solve this problem. For me its not so much about INSTALL paths since I almost never run the INSTALL targets (at least not on projects that do not have different names for release and debug) on windows but it's more that a 32 bit build for Visual Studio 2005 will find the 64 bit Qt I built for Visual Studio 2010. I am thinking of looking into batch files and environment variables however I am not sure how many packages will use environment variables like ( ITK_DIR, VTK_DIR ...) John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Forcing CMake to never search install path
I've been struggling to find a way to prevent CMake from using CMAKE_INSTALL_PREFIX in any of its FIND_* routines. Generally speaking, stripping it out of CMAKE_SYSTEM_PREFIX_PATH seems to work, but we're still getting situations on Windows where it is finding old libraries from previous program installs. I've tried ensuring all of the CMAKE_SYSTEM_*_PATH variables are stripped, but that doesn't seem to make a difference. Is there a mechanism I can use to specify to CMake to NEVER search in a given path, excluding it from all FIND_* routine searches? It is very typical in our development process to have older builds installed and be building newer versions at the same time, so we really need a good solid way to make sure previously built libraries aren't picked up by FIND routines. Thanks for any assistance, CY ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Trying to set up a "superbuild" with external project and install it...
On Sunday 15 May 2011, Michael Hertling wrote:
> On 05/14/2011 07:57 PM, Alexander Neundorf wrote:
...
> Indeed, RPATH-related dependencies among the intermediately installed
> subprojects are malicious. In order to solve the problem you outlined
> without doing the whole stuff as root, you would need to install foo
> to its final destination and reconfigure/rebuild foo-{bar,blub} with
> CMAKE_PREFIX_PATH set to CMAKE_INSTALL_PREFIX before they're finally
> installed, too - another example for the worst case. This could be
> achieved by an own installation target, say, "superinstall", e.g.:
>
> ADD_CUSTOM_TARGET(superinstall
> COMMAND ${CMAKE_COMMAND} -P cmake_install.cmake
> COMMAND
> COMMAND
> COMMAND ${CMAKE_COMMAND} -P cmake_install.cmake)
Well, this basically means rebuilding the whole thing, since e.g. the include
directories will have changed, which will cause everything to be recompiled.
> The first command installs the superproject including the subprojects
> with the wrong RPATHs to their final location, the following commands
> reconfigure/rebuild the affected subprojects as far as necessary, and
> the final command reinstalls the superproject with correct RPATHs in
> the subprojects. If there are chained or cascaded dependencies among
> the subprojects, e.g. foo-blub incorporating ${FOO-BAR_LIBRARY_PATH}
> in its RPATHs, one would need to intersperse the cmake_install.cmake
> script more often. In order to prevent that the reconfigure/rebuild
> steps are run with root privileges, one could add, e.g.,
>
> SET(BUILD_USER $ENV{USER} CACHE STRING "...")
>
> to the superproject's CMakeLists.txt and write the reconfigure/rebuild
> commands as "COMMAND su -c '' ${BUILD_USER}",
> provided the superproject is primarily targeted at *nix systems.
>
> At the end of the day, this entire issue seems to boil down to the
> question if one is willing either to rebuild possibly considerable
> parts of the project during the installation or to acquire root's
> privileges early to build the project - or to fragment and intermix
> the build/installation process: make foo; su -c 'make install_foo';
> make foo-bar foo-blub; su -c 'make install_foo-bar install_foo-blub'
> etc. Apparently, that's the price of non-trivial superbuild set-ups.
> Sometimes, I think they lead to more problems than they solve... ;-)
>
> An interesting option is the manipulation of the binaries' RPATH just
> before or after their final installation, similar to CMake's own post-
> treatment of freshly installed libraries/executables. To do this, one
> might use utilities like the obviously ceased chrpath or the actively
> developed PatchELF in association with INSTALL(CODE|SCRIPT ...) or a
> custom "preinstall" target.
Didn't know about patchelf.
Looks interesting: "PatchELF takes care of “growing” the executable with
sufficient space at the beginning to contain the new interpreter field."
Otherwise, if there is enough room in the executable, one could also use the
cmake FILE() command for changing the RPATH.
But also a problem is that I don't really know how the RPATH is computed for
all the subprojects, so they have to do it themselves.
> However, this would take care of RPATHs
> but not other paths incorporated in the binaries and derived from
> results of FIND_PACKAGE() for the intermediate installations.
>
> If you actually decide to install the subprojects immediately to their
> final destinations, I would suggest to think about the above-mentioned
> BUILD_USER variable or the like and, as the case may be, encompass the
> configure/build commands in the ExternalProject invocations by "su -c
> '...' ${BUILD_USER}" to ensure that only the pure installation steps
> are performed with root's privileges.
I think this will be for developers only, as a convenience, and I think it
will have the limitation that the developer will need write permission to the
install location. Could be e.g. in his home, then it's no problem.
Everything else seems more like a hack.
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake fails to use a toolchain to cross-compile
I get the following error when I use a toolchain file to cross-compile with mingw32: $ cmake -DCMAKE_TOOLCHAIN_FILE=~/Documentos/mingw32.cmake -DCMAKE_INSTALL_PREFIX=/usr/i486-mingw32 . -- The C compiler identification is GNU -- The CXX compiler identification is GNU CMake Error: your RC compiler: "CMAKE_RC_COMPILER-NOTFOUND" was not found. Please set CMAKE_RC_COMPILER to a valid compiler path or name. -- Check for working C compiler: /usr/bin/i486-mingw32-gcc CMake Error at /usr/share/cmake-2.8/Modules/CMakeRCInformation.cmake:22 (GET_FILENAME_COMPONENT): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/Platform/Windows-GNU.cmake:59 (enable_language) /usr/share/cmake-2.8/Modules/Platform/Windows-GNU-C.cmake:1 (include) /usr/share/cmake-2.8/Modules/CMakeCInformation.cmake:56 (INCLUDE) CMakeLists.txt:2 (PROJECT) CMake Error: CMAKE_RC_COMPILER not set, after EnableLanguage CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: /usr/bin/i486-mingw32-gcc -- broken CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler "/usr/bin/i486-mingw32-gcc" is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (PROJECT) -- Configuring incomplete, errors occurred! My toolchain file is: set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_C_COMPILER i486-mingw32-gcc) set(CMAKE_CXX_COMPILER i486-mingw32-g++) set(CMAKE_FIND_ROOT_PATH /usr/i486-mingw32) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How do you go about building the cmake-gui from source in 2.8.4?
One other thing is that the SDK for QT4 specifically installs a version supposedly built with and for VS 2005. Best, Dick Munroe On 5/14/11 9:49 AM, cmake-requ...@cmake.org wrote: Date: Fri, 13 May 2011 16:42:45 -0400 From: John Drescher Subject: Re: [CMake] How do you go about building the cmake-gui from source in 2.8.4? To: Dick Munroe Cc:cmake@cmake.org Message-ID: Content-Type: text/plain; charset=windows-1252 > Yeah, I figured that part out indirectly. > > I had to install the QT4 SDK to get the necessary bits, but rcc.exe (Windows > XP, desktop component of QT) fails for no obvious reason. > Did you build that from scratch using Visual Studio 2005 and not any other compiler or version? > > Here is what I posted on the QT installation/deployment forum about the > problem: > > I?m trying to rebuild CMake-gui. Are you trying to modify it for some reason? I also do not see the need to rebuild it. > I?ve gotten to the point where I downloaded > and installed the QT4 SDK, configured CMake for VS 2005 and fired up the > build, which failed when trying to run rcc.exe. When I try to run RCC.EXE > directly from the command prompt, I get: > > The system cannot execute the specified program. > > When I try it from cygwin?s command prompt, I get: > You should not mix cygwin building and visual studio building. What are you doing here? > Permission Denied > > Firing up Dependency Walker, I get an error when opening rcc.exe: > > The side-by-side configuration information for > ??desktop\qt\4.7.3\msvc2005\bin\RCC.EXE? contains errors. This application > has failed to start because the application configuration is incorrect. > Reinstalling the application may fix this problem (14001). > This usually means you do not have the correct run times installed. Did you download the Visual Studio 2008 binary release. That will not work with Visual Studio 2005. You need to build Qt for your compiler. > Which I tried with no joy. > > There are a couple of delay loaded dlls that aren?t present, IESHIMS and > WER, but these appear to be more or less specific to Vista and don?t apply > to XP (which is what I?m running on). > > So how do I get around this? Is this an SDK problem? or something really > obscure in Windoze? I?m not primarily a Windows person so I?m not 100% on > all the ins and outs here, but I would think that the RCC.EXE as installed > by the QT4 SDK installer should at least start on XP. > > Any and all hints will be appreciated. > > Best, > > Dick Munroe > > Any clues? > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How do you go about building the cmake-gui from source in 2.8.4?
On 05/15/2011 12:31 PM, Dick Munroe wrote: > > > On 5/14/11 9:49 AM, cmake-requ...@cmake.org wrote: >> Date: Fri, 13 May 2011 16:42:45 -0400 >> From: John Drescher >> Subject: Re: [CMake] How do you go about building the cmake-gui from >> sourcein 2.8.4? >> To: Dick Munroe >> Cc:cmake@cmake.org >> Message-ID: >> Content-Type: text/plain; charset=windows-1252 >> >>> > Yeah, I figured that part out indirectly. >>> > >>> > I had to install the QT4 SDK to get the necessary bits, but >>> rcc.exe (Windows >>> > XP, desktop component of QT) fails for no obvious reason. >>> > >> Did you build that from scratch using Visual Studio 2005 and not any >> other compiler or version? > No. On most systems, SDKs are either provided with a list of the system > requirements or multiple SDKs are provided. There doesn't appear to be > any obvious documentation on the QT4 download page that states the SDK > needs to be rebuilt to match each specific configuration or provides a > list of the system requirement for the specific SDK. Clearly Windoze > has different expectations. The Qt-SDK download on the http://qt.nokia.com/downloads website is a MinGW build. AFAIK the reasoning is, that since the SDK comes with the QtCreator IDE, you get a complete toolchain without requiring developers to buy a very expensive VS license. But that also means, that you HAVE to use MinGW. BTW, QtCreator directly supports CMake projects provided you have another CMake version installed already. But you clearly must have, since bootstrapping CMake does not work with VS, only with MinGW or Cygwin. >>> > >>> > Here is what I posted on the QT installation/deployment forum >>> about the >>> > problem: >>> > >>> > I?m trying to rebuild CMake-gui. >> Are you trying to modify it for some reason? I also do not see the >> need to rebuild it. >> > Yes, but the reason isn't the point here, the point is that the tools > provided by the QT4 SDK fail. Asking about why the rebuild is necessary > or desirable isn't particularly helpful. I could think of a dozen > different reasons, including simple interest, for wanting to rebuild > cmake-gui. But then again, you are harassing the wrong people with your problem. If Qt doesn't work for you, you really should ask your questions here: http://lists.qt.nokia.com/mailman/listinfo/qt-interest >>> > I?ve gotten to the point where I downloaded >>> > and installed the QT4 SDK, configured CMake for VS 2005 and fired >>> up the >>> > build, which failed when trying to run rcc.exe. When I try to run >>> RCC.EXE >>> > directly from the command prompt, I get: >>> > >>> > The system cannot execute the specified program. >>> > >>> > When I try it from cygwin?s command prompt, I get: >>> > >> You should not mix cygwin building and visual studio building. What >> are you doing here? >> > Hmmm, could be that I'm trying to see what's blowing up without VS 2005 > getting in the way so that I can provide more information to the people > who might be helpful? Each command shell has specific pluses and > minuses that may or may not provide additional information to smart > folks with more experience in this area that I have. I'm simply stating > facts: when I fire up RCC I get this error under command shell x, that > error under command shell y, when I use this tool, I get information z. > Since I DON'T know what the problem is, I DON'T know, a priori, what > information will be helpful. Again, the wrong place to complain... >>> > Permission Denied >>> > >>> > Firing up Dependency Walker, I get an error when opening rcc.exe: >>> > >>> > The side-by-side configuration information for >>> > ??desktop\qt\4.7.3\msvc2005\bin\RCC.EXE? contains errors. This >>> application >>> > has failed to start because the application configuration is >>> incorrect. >>> > Reinstalling the application may fix this problem (14001). >>> > >> This usually means you do not have the correct run times installed. >> Did you download the Visual Studio 2008 binary release. That will not >> work with Visual Studio 2005. You need to build Qt for your compiler. >> > Which would be cool if that was documented anywhere. I'll give that a > try and see if I can get that to work. > > Best, > > Dick Munroe Quick question: did you install SP 1 for VS 2005? See: http://doc.trolltech.com/latest/requirements-win.html Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Digest, Vol 85, Issue 43
On 5/14/11 9:49 AM, cmake-requ...@cmake.org wrote: Date: Fri, 13 May 2011 16:42:45 -0400 From: John Drescher Subject: Re: [CMake] How do you go about building the cmake-gui from source in 2.8.4? To: Dick Munroe Cc:cmake@cmake.org Message-ID: Content-Type: text/plain; charset=windows-1252 > Yeah, I figured that part out indirectly. > > I had to install the QT4 SDK to get the necessary bits, but rcc.exe (Windows > XP, desktop component of QT) fails for no obvious reason. > Did you build that from scratch using Visual Studio 2005 and not any other compiler or version? No. On most systems, SDKs are either provided with a list of the system requirements or multiple SDKs are provided. There doesn't appear to be any obvious documentation on the QT4 download page that states the SDK needs to be rebuilt to match each specific configuration or provides a list of the system requirement for the specific SDK. Clearly Windoze has different expectations. > > Here is what I posted on the QT installation/deployment forum about the > problem: > > I?m trying to rebuild CMake-gui. Are you trying to modify it for some reason? I also do not see the need to rebuild it. Yes, but the reason isn't the point here, the point is that the tools provided by the QT4 SDK fail. Asking about why the rebuild is necessary or desirable isn't particularly helpful. I could think of a dozen different reasons, including simple interest, for wanting to rebuild cmake-gui. > I?ve gotten to the point where I downloaded > and installed the QT4 SDK, configured CMake for VS 2005 and fired up the > build, which failed when trying to run rcc.exe. When I try to run RCC.EXE > directly from the command prompt, I get: > > The system cannot execute the specified program. > > When I try it from cygwin?s command prompt, I get: > You should not mix cygwin building and visual studio building. What are you doing here? Hmmm, could be that I'm trying to see what's blowing up without VS 2005 getting in the way so that I can provide more information to the people who might be helpful? Each command shell has specific pluses and minuses that may or may not provide additional information to smart folks with more experience in this area that I have. I'm simply stating facts: when I fire up RCC I get this error under command shell x, that error under command shell y, when I use this tool, I get information z. Since I DON'T know what the problem is, I DON'T know, a priori, what information will be helpful. > Permission Denied > > Firing up Dependency Walker, I get an error when opening rcc.exe: > > The side-by-side configuration information for > ??desktop\qt\4.7.3\msvc2005\bin\RCC.EXE? contains errors. This application > has failed to start because the application configuration is incorrect. > Reinstalling the application may fix this problem (14001). > This usually means you do not have the correct run times installed. Did you download the Visual Studio 2008 binary release. That will not work with Visual Studio 2005. You need to build Qt for your compiler. Which would be cool if that was documented anywhere. I'll give that a try and see if I can get that to work. Best, Dick Munroe > Which I tried with no joy. > > There are a couple of delay loaded dlls that aren?t present, IESHIMS and > WER, but these appear to be more or less specific to Vista and don?t apply > to XP (which is what I?m running on). > > So how do I get around this? Is this an SDK problem? or something really > obscure in Windoze? I?m not primarily a Windows person so I?m not 100% on > all the ins and outs here, but I would think that the RCC.EXE as installed > by the QT4 SDK installer should at least start on XP. > > Any and all hints will be appreciated. > > Best, > > Dick Munroe > > Any clues? > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Trying to set up a "superbuild" with external project and install it...
On 05/14/2011 07:57 PM, Alexander Neundorf wrote:
> On Thursday 12 May 2011, Michael Hertling wrote:
>> On 05/11/2011 09:07 PM, Alexander Neundorf wrote:
>>> Hi,
>>>
>>> I'd like to set up a kind of meta super project, which builds a bunch of
>>> subprojects, which contains executable and shared libraries.
>>> These subprojects come from different repositories, mostly git
>>> repositories.
>>>
>>> AFAIK I can basically do this using the ExternalProject_add() feature of
>>> cmake, it will get the sources, configure and build them.
>>>
>>> So far so good.
>>>
>>>
>>> Now, what do I do with installing ?
>>> Usually the external projects are installed at the end of their build
>>> step at make-time, and usually somewhere in the build tree.
>>>
>>> But finally I'd like to have these projects installed into a proper
>>> system- wide directory.
>>>
>>> If I simply do install(DIRECTORY ... ) in the "superproject", stuff which
>>> depends on CMAKE_INSTALL_PREFIX, like e.g. RPATH will be wrong after the
>>> final install step (since the RPATHs will still point to the install
>>> locations in the build tree).
>>>
>>> If I put the final install location as install location in the
>>> ExternalProject_Add() call, I will have to build with permissions to
>>> install into the final install directory, which is generally not the
>>> case. E.g. to install in /opt/ I would basically have to build as root
>>> (or change the permissions of /opt/, but that's not possible on a
>>> standard system).
>>>
>>> I could maybe also setuid cmake root (ugly too).
>>>
>>> Always set a relative RPATH always using $ORIGIN ?
>>> (but this will be kind of hard to enforce)
>>>
>>> Any other ideas ?
>>> Am I missing something ?
>>> Any ideas how support for this could be added in a clean way ?
>>>
>>> Alex
>>
>> A quite similar topic has been touched on recently in [1]. My personal
>> opinion on this particular issue with regard to subprojects is roughly:
>>
>> 1. In the end, each project - subproject or not - must be installed at
>> the location it has been configured for; this is the only bullet-proof
>> way to ensure that things like RPATH or incorporated paths derived from
>> the installation prefix, e.g. /etc or /etc if is /usr,
>> will work as expected, or in other words: Relocation after installation
>> is critical, unless it's taken into account by any appropriate measures.
>>
>> 2. For the, say, intermediate installation of a subproject in the build
>> tree of the superproject, I'd suggest to use the DESTDIR feature, i.e.:
>>
>> - Configure and build the subproject with its final installation prefix.
>> - Install with "make DESTDIR=${CMAKE_BINARY_DIR}/externals" or the like
>> with the superproject's CMAKE_BINARY_DIR. Thereafter, you could call
>> FIND_PACKAGE() on the subproject with CMAKE_PREFIX_PATH and friends
>> set to ${CMAKE_BINARY_DIR}/externals/${CMAKE_INSTALL_PREFIX}[/...]
>> which may be important for the actual main project. Nevertheless,
>> the subproject's binaries might not run if they strictly require
>> to reside at the location they've been configured for.
>> - At the superproject's installation, use
>>
>> INSTALL(DIRECTORY ${CMAKE_BINARY_DIR}/externals/${CMAKE_INSTALL_PREFIX}/
>> DESTINATION ${CMAKE_INSTALL_PREFIX})
>>
>> to relocate the subprojects to their configured installation prefix.
>
>
> Yes, this work pretty good.
> But it still has a problem.
> Assume subproject foo installs a shared library libfoo, amd subprojects foo-
> bar and foo-blub are plugins for this shared library.
>
> foo-bar and foo-blub will find libfoo.so in CMAKE_BINARY_DIR/Install/, and
> link against it happily.
>
> But they will have a problem with their RPATH.
> If they use e.g. ${FOO_LIBRARY_DIR} as RPATH, this would point to the
> temporary install location of libfoo, not the final one.
> If they use INSTALL_RPATH_USE_LINK_PATH they will have the same problem.
>
> I guess I have to install the subprojects to their final destination already
> in the install-step of the external project.
>
> Alex
Indeed, RPATH-related dependencies among the intermediately installed
subprojects are malicious. In order to solve the problem you outlined
without doing the whole stuff as root, you would need to install foo
to its final destination and reconfigure/rebuild foo-{bar,blub} with
CMAKE_PREFIX_PATH set to CMAKE_INSTALL_PREFIX before they're finally
installed, too - another example for the worst case. This could be
achieved by an own installation target, say, "superinstall", e.g.:
ADD_CUSTOM_TARGET(superinstall
COMMAND ${CMAKE_COMMAND} -P cmake_install.cmake
COMMAND
COMMAND
COMMAND ${CMAKE_COMMAND} -P cmake_install.cmake)
The first command installs the superproject including the subprojects
with the wrong RPATHs to their final location, the following commands
reconfigure/rebuild the affected subprojects as far as necessary, and
the final command reinstalls the superproject with correct RPATHs in
the
