Re: [CMake] Specifying an alternate location for cmake Modules directory
On Thu, 2013-11-14 at 12:41 +0100, Micha Hergarden wrote: > For the modules you can use cmake_module_path from within your > scripts. Unfortunately this doesn't work. I should have mentioned that I'd already tried this. CMake looks for its installation directory as the very first thing and errors out if it can't be found, long before it gets around to parsing CMAKE_MODULE_PATH. Aha. I've looked at the code and it appears I can do what I want by setting the environment variable CMAKE_ROOT (not the cmake variable) before I start cmake. However, this doesn't really work for me either: the wrappers that set this variable are not used when cmake is invoked from the makefile, or whatever, and Failure Ensues. Attempts to forcibly override CMAKE_COMMAND, CMAKE_CPACK_COMMAND, and CMAKE_CTEST_COMMAND worked, but had their own problems. I did find a way to do what I want though, by rearranging my directories somewhat: tools/linux/bin/cmake (a wrapper that invokes the real program) tools/macosx/bin/cmake (wrapper) tools/windows/bin/cmake.bat (wrapper) tools/common/cmake/linux/cmake (real program) tools/common/cmake/macosx/cmake (real program) tools/common/cmake/windows/cmake.exe (real program) tools/common/cmake/Modules/... Ditto for ctest, cpack, etc. The reason for the wrappers is that I have lots of tools and I want to add just one directory to $PATH (tools/linux/bin for example) and get access to all the tools: I don't want to add a different directory for each tool. But I need each tool to be installed completely contained in its own subdirectory. Done this way I don't need to use CMAKE_ROOT or do anything differently; it all just works. Yay! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] bug in boost library discovery?
Sorry to pester people - I was just hoping that someone could confirm that they see this issue and/or suggest a fix...? James On Thu, Nov 7, 2013 at 11:00 AM, James Sutherland wrote: > Hello fellow cmake enthusiasts. > > Beginning with a recent CMake update, find_package( Boost ... ) seems to > be broken. > > Specifically, if I run ccmake, the first configure (press "c") finds the > boost libraries, but sets "Boost_DIR" to "Boost_DIR-NOTFOUND". This has > been the case for many releases of cmake, so I typically ignore that. The > second configure (press "c" again), results in all of the boost libraries > disappearing, and an error being raised. > > This also occurs when running cmake (rather than ccmake). The first time > I run cmake, things work fine. If I run it again, boost suddenly is not > found and an error is raised. > > This occurs on the following cmake versions/platforms that I have tested: > >- 2.8.11.2 (on debian with boost in /usr) >- 2.8.12 (on mac with boost in /usr/local) > > It does NOT occur on a few other systems I have access to: > >- 2.8.10.1 (on ubuntu with boost in /usr) >- 2.8.11.2 (on mac with boost in /opt/local) -- note same cmake >version as the one that breaks on debian. > > If I set the environmental variable CMAKE_PREFIX_PATH to include the > location of boost, it also fixes the problem. But this isn't a great > solution in general. > > Has anyone else seen this problem? Is there a known fix/patch? > > Thanks, > > James > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] cross compiling - CMAKE_FIND_ROOT_PATH_MODE_LIBRARY and link.txt
Hello,
I'm confused by an issue that I am having with a project I have recently
joined.
We are cross compiling for ARM on linux.
I have the cross compiler toolchain installed at /CC_TOOLCHAIN
I set CMAKE_SYSROOT_PATH appropriately, then do this in my toolchain file:
set(CMAKE_FIND_ROOT_PATH "${CMAKE_SYSROOT_PATH}/usr/lib")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
upon launching cmake with this command:
cmake --debug-trycompile --debug-output
-DCMAKE_TOOLCHAIN_FILE=CC_TOOLCHAIN/toolchain.cmake ../src
I encounter this error
/CC_TOOLCHAIN/arm-gcc
-D_POSIX_C_SOURCE=199506 -D_POSIX_VERSION=199506 -DGPT_VERSION="" -o
CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c
/home/Me/build/CMakeTmp/testCCompiler.c
Linking C executable cmTryCompileExec
cmake -E cmake_link_script CMakeFiles/cmTryCompileExec.dir/link.txt
--verbose=1
/CC_TOOLCHAIN/arm-gcc
CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -o cmTryCompileExec
-rdynamic
/CC_TOOLCHAIN/ld:
cannot find crt1.o: No such file or directory
Curious as to the contents of the cmake_link_script at
CMakeFiles/cmTryCompileExec.dir/link.txt
$cat link.txt
/CC_TOOLCHAIN/arm-gcc CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -o
cmTryCompileExec -rdynamic
So, I guess my question is, where is the "-L" to specify link directories,
or how do I know / specify where the linker thinks it is allowed to look
for libraries ?
Thanks.
Jack
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Git Doesn't to Pull with ExternalProject_Add
Hello Constantine,
On 14/11/13 12:03, Constantine Zakkaroff wrote:
> Now, setting ${proj}_GIT_TAG to "origin/master" seems to improve things.
> I got this output:
If you plan to use the external project repository for development, then
being in detached state is not good. Also every time that the update
step is executed I believe that CMake will checkout the latest
origin/master that you fetched, not the current one, because the fetch
step is executed only if necessary (i.e. if the name origin/master was
not found). And I believe that your current commit(s) will be just
dropped in favour of the hash of origin/master (they will still be in
your repository and in your reflog, but as "dangling commits" and
therefore might be deleted.
And basically the pull is not executed.
Perhaps we need a "GIT_BRANCH" arguments to handle this in a different
way compared to "GIT_TAG", what do you think?
Also note that there is another important bug that makes developing in
git clones handled by ExternalProject complicate, see
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7840
I have a partial patch for that but I couldn't find the time to finish
it yet.
Cheers,
Daniele
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Qt4 QT_INSTALL_LIBS
Hi, On Thu, Nov 14, 2013 at 11:45 AM, Lars Lars wrote: > Using CMake 2.8.10 on Windows 7. > > We have a working project that finds QT liket this: > FIND_PACKAGE(Qt4 4.7.1 COMPONENTS QtCore QtGui) > > Now we would like to update Qt library, so changed it to: > FIND_PACKAGE(Qt4 4.8.4 COMPONENTS QtCore QtGui) > > This however fails because FindQt4.cmake execute "qmake -query > QT_INSTALL_LIBS" which returns the path where the Qt library was built. We > however store Qt in another location in our development setup. How can is > solved this issue without rebuilding the Qt library in the same path as the > development setup? > Your Qt won't work from that place as it is either. Qt is not relocatable, the path to the install location is hardcoded into the tools. If you build a Qt project with qmake it'll also generate compiler commands that point to the non-existing install location. You can make the Qt installation relocatable by adding a qt.conf file and qmake will pick this up as well, see the Qt docs for more information: http://qt-project.org/doc/qt-4.8/qt-conf.html. What is the rational behind querying qmake for the the location of the > libs? > Because qmake knows best where the libs are. There are various ways of customizing the structure and the structure can be different across platform. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Specifying an alternate location for cmake Modules directory
On 11/13/2013 11:50 PM, Paul Smith wrote: > I need to maintain my own copy of the latest cmake, and for multiple > different target systems (GNU/Linux, MacOS, Windows, Solaris...) > > I have a shared location where all tools like this go, so that > regardless of the system architecture you can access this one location. > Obviously inside that location are architecture-specific areas for > binaries, etc. > > There is also a common area for files that can be shared, to reduce disk > usage, copying time, etc. > > Since all of the cmake installation with the exception of the binaries > is identical between the different architectures, I want to share all of > the installation (for example the Modules directory, etc.) I can't use > symlinks. > > So what I'd like is a structure something like this: > > .../common/cmake/Modules/... > > .../linux/bin/cmake > .../darwin/bin/cmake > .../windows/bin/cmake.exe > .../sunos/bin/cmake > > I can use a wrapper around cmake to set environment variables or pass in > command line flags to the REAL cmake, if necessary. > > Is there any way to convince cmake to look in a different place for > Modules etc.? > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake Hello Paul, For the modules you can use cmake_module_path from within your scripts. |Regards, Micha | signature.asc Description: OpenPGP digital signature -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unicode path wrecks havoc with VS2013 generator
The link you copied says “no such project”, however I trust it’s there. So I guess if nothing extreme hits in, I’ll just have to wait for 2.8.13. Anyhow, thanks for your time. Waiting for the new release. Cheers, Máté Feladó: Clinton Stimpson Elküldve: szerda, 2013. november 13. 17:36 Címzett: cmake@cmake.org On Wednesday, November 13, 2013 03:12:13 PM Nagy-Egri Máté Ferenc wrote: > I have changed the encoding as you suggested and the project compiled fine: > > > 1>-- Build started: Project: cmTryCompileExec747919577, Configuration: > Debug Win32 -- 1> Microsoft (R) C/C++ Optimizing Compiler Version > 18.00.21005.1 for x86 1> Copyright (C) Microsoft Corporation. All rights > reserved. > 1> > 1> cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D > "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise > /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec747919577.dir\Debug\\" > /Fd"cmTryCompileExec747919577.dir\Debug\vc120.pdb" /Gd /TC /analyze- > /errorReport:prompt testCCompiler.c 1> > 1> testCCompiler.c > 1> cmTryCompileExec747919577.vcxproj -> > C:\Users\MátéFerenc\SkyDrive\Develop\Active\GridRipper\VS2013\CMakeFiles\CM > akeTmp\Debug\cmTryCompileExec747919577.exe == Build: 1 succeeded, 0 > failed, 0 up-to-date, 0 skipped == > > > If you could issue a patch (2.8.12.2 if I’m not mistaken) that would correct > this bug, that would simply rock. Here is the fix for a future release. http://cmake.org/gitweb?p=cmake.git;a=commit;h=efe3a5dd Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Git Doesn't to Pull with ExternalProject_Add
Hi Daniele,
Thanks for your response. Yes, the ${proj}_GIT_TAG? was simply set to
master.
You are right, there's nothing in the documentation about it. Say,
normally, if I'm working with a git repository, and if your branch is
set to master, all you need to do is 'git pull' when you want to update
your local master, so I'd hope the same behaviour during the external
project update. But I don't even see anything in the build log
indicating CMake attempted to update the project.
I can see in the C:\Program Files (x86)\CMake
2.8\share\cmake-2.8\Modules\ExternalProject.cmake file (which is where
the ExternalProject_Add function is defined) there this line (1519):
set(comment "Performing update step for '${name}'")
I think I've seen this line only once, immediately after the initial
repository cloning.
Now, setting ${proj}_GIT_TAG to "origin/master" seems to improve things.
I got this output:
1>-- Build started: Project: ITKv4, Configuration: Release x64 --
1>Performing update step for 'ITKv4'
1>-- ***RunningE:/Dev/ITKSoftwareGuide/SuperBuild/External_ITKv4.cmake***
1>From git://itk.org/ITK
1> bf180e2..8e7d867 master -> origin/master
1> 66743fc..07f48b6 dashboard -> origin/dashboard
1> bf180e2..d0638da nightly-master -> origin/nightly-master
1>Note: checking out 'origin/master'.
1>You are in 'detached HEAD' state. You can look around, make experimental
1>changes and commit them, and you can discard any commits you make in this
1>state without impacting any branches by performing another checkout.
1>If you want to create a new branch to retain commits you create, you may
1>do so (now or later) by using -b with the checkout command again. Example:
1> git checkout -b new_branch_name
1>HEAD is now at 8e7d867... COMP: Fix warnings from VTK dashboard,
contributed by Sean McBride
1>Performing configure step for 'ITKv4'
1> [... and so on ...]
Does this mean the local repository has been updated? This is beyond my
knowledge of git, because I'm not sure I understand the implications of
the "You are in 'detached HEAD' state", which sounds a bit scary in the
good old Headless Horseman way, but I'm not sure I need to be alarmed in
the given situation. ;)
I can see from command line that the branch has been set to this:
mnkz@CSPCX174 /e/Dev/ITKSoftwareGuide.Out/ITKv4 ((8e7d867...))
$ git branch
* (detached from origin/master)
master
I know from command line I can do this (if I'm on master branch):
git remote update
git show-branch *master
git status
That would tell me if my local repository behind the remote one, but I'm
not sure what to do if I'm in 'detached HEAD' state.
Basically, is there a way to verify the latest repository updates have
been pulled?
Many thanks,
Constantine
On 13/11/2013 11:35, Daniele E. Domenichelli wrote:
Hello Constantine,
I'm investigating the same issue right in this moment...
On 13/11/13 10:19, Constantine Zakkaroff wrote:
I have a SuperBuild project (using CMake 2.8.12 on Windows Vista x64)
depending on some other project cloned from a git repository. However
I've noticed the cloner repository doesn't get updated when I rebuild
the project.
Is it right to expect the repository to be updated automatically? Or
does it need to be done manually?
How do you set ${proj}_GIT_TAG? If it a tag or a commit hash it should
work, therefore if you change it in your superbuild, your repository
should be updated.
Unfortunately it doesn't work for branches. Therefore if you set it to
"master" it will work for the clone, but it won't work for the updates,
because the branch "master" is your local branch not the remote one
("origin/master")
Perhaps this should be fixed somehow, either the documentation of the
module to explicitly state this, or the module itself to pull from the
remote branch if GIT_TAG is a branch.
Cheers,
Daniele
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/ope
[CMake] Qt4 QT_INSTALL_LIBS
Hello, Using CMake 2.8.10 on Windows 7. We have a working project that finds QT liket this: FIND_PACKAGE(Qt4 4.7.1 COMPONENTS QtCore QtGui) Now we would like to update Qt library, so changed it to: FIND_PACKAGE(Qt4 4.8.4 COMPONENTS QtCore QtGui) This however fails because FindQt4.cmake execute "qmake -query QT_INSTALL_LIBS" which returns the path where the Qt library was built. We however store Qt in another location in our development setup. How can is solved this issue without rebuilding the Qt library in the same path as the development setup? What is the rational behind querying qmake for the the location of the libs? Regards, Lars -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
