[CMake] Problem with FindQt.cmake or Qt 4.6.1 on Windows platform. CMake 2.8.0
Hi I'm not certain if this should be here or in some Qt messageboard, but here's the thing. I had Qt 4.4.X version installed, and i wanted to upgrade to 4.6.1 for nicer licensing. I used the uninstaller to remove the 4.4.X version, and did everything according to the install instructions for version 4.6.1 Everything seemed to be installed correctly, but FindQt4.cmake didn't work anymore. I checked the files and found that on my windows platform it was looking for Qt from the wrong location, still the 4.4.X place. Modifying the value of the registry entry: [HKEY_CURRENT_USER\Software\Trolltech\Versions;DefaultQtVersion] to value: 4.6.1 fixed this problem since the FindQt4.cmake was using this value to locate another registry path to find the directory where Qt is installed. I thought i'd share this with you, it seems to work perfectly now. Maybe it's because Qt installer didn't modify this value, or maybe it's because i don't have the correct version of FindQt.cmake. -Mika ___ 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] Multiple libraries, same name...
See this property: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LIBRARY_OUTPUT_DIRECTORY Oh, wow, I totally missed that. Thanks, Bill, it worked like a charm. :) --ryan. ___ 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] Relative (source files) vs Absolute (include files) path
On Tue, Feb 2, 2010 at 6:23 PM, Brian Davis wrote: > > I noticed that if I have a buried CMakeLists.txt file which contains the > following > > file(GLOB_RECURSE DICOM_TEST_SERVER_SRC src *.cpp ) > > and > > INCLUDE_DIRECTORIES( > include > ) > > Where src contains cpp files and include contains include files CMake uses > absolute paths for include path, but relative directories for the source. > > examples produced by cmake: > > src: > > Creating temporary file > "c:\projects\NIH2009\source\branches\trunk\build\dvip4-Win64\cpp_source\app\dicomserver\dvipdicomsvr.dir\Debug\RSP6D57442788.rsp" > with contents [ /Od /I > "C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\NVIDIA_GPU_Computing_SDK_2.2\common\inc" > /I > "C:\projects\NIH2009\source\branches\trunk\build\Windows-6.1\install\include" > /I > "C:\projects\NIH2009\source\branches\trunk\source\cpp\app\testing\dicomserver\include" > /I > "C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\CUDA_Toolkit_2.2\include" > /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "CMAKE_INTDIR=\"Debug\"" /D "_MBCS" > /Gm /EHsc /RTC1 /MTd /Fo"dvipdicomsvr.dir\Debug\\" > /Fd"C:/projects/NIH2009/source/branches/trunk/build/Windows-6.1/ouput/bin/Debug/dvipdicomsvr.pdb" > /W3 /c /Zi /TP /Zm1000 > "..\..\..\..\..\source\cpp\app\testing\dicomserver\src\main.cpp" > "..\..\..\..\..\source\cpp\app\testing\dicomserver\src\dcmtksvr.cpp" ] > > include: > > > C:\projects\NIH2009\source\branches\trunk\source\cpp\app\testing\dicomserver\include > > Why? > > Unfortunately, just "CMake 101" here... The answer is fairly close to the top of the FAQ: http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_use_full_paths.2C_or_can_I_copy_my_build_tree.3F ___ 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] Fwd: Relative (source files) vs Absolute (include files) path
> Why I care: > > Lets say that I someone wants to check the Visual Studio project goop > produced by CMake in trunk and check out in a diffrent directory in their > branch on another machine. With absolute paths sprinkled all over > effectively makes this impossible. > Never put any generated parts (including cmake cache and the visual studio project files) in the vcs. They are of no value outside of the machine they are generated on. 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
Re: [CMake] Relative (source files) vs Absolute (include files) path
On 02.02.10 17:23:37, Brian Davis wrote: > Why I care: > > Lets say that I someone wants to check the Visual Studio project goop > produced by CMake in trunk and check out in a diffrent directory in their > branch on another machine. With absolute paths sprinkled all over > effectively makes this impossible. The files generated in the cmake build directory are not meant for moving around, never have been. I didn't use the VS-generator yet, but if the generated VS-files are in the builddir, then "someone" will need cmake and generate a fresh builddir himself. Andreas -- Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson ___ 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] Relative (source files) vs Absolute (include files) path
Performing grep -R "[Cc][:][\]" * > AbsolutePathProb.txt on my build dir created by CMake and looking at the output saddens me :-( Brian ___ 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] Relative (source files) vs Absolute (include files) path
I noticed that if I have a buried CMakeLists.txt file which contains the following file(GLOB_RECURSE DICOM_TEST_SERVER_SRC src *.cpp ) and INCLUDE_DIRECTORIES( include ) Where src contains cpp files and include contains include files CMake uses absolute paths for include path, but relative directories for the source. examples produced by cmake: src: Creating temporary file "c:\projects\NIH2009\source\branches\trunk\build\dvip4-Win64\cpp_source\app\dicomserver\dvipdicomsvr.dir\Debug\RSP6D57442788.rsp" with contents [ /Od /I "C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\NVIDIA_GPU_Computing_SDK_2.2\common\inc" /I "C:\projects\NIH2009\source\branches\trunk\build\Windows-6.1\install\include" /I "C:\projects\NIH2009\source\branches\trunk\source\cpp\app\testing\dicomserver\include" /I "C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\CUDA_Toolkit_2.2\include" /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /Gm /EHsc /RTC1 /MTd /Fo"dvipdicomsvr.dir\Debug\\" /Fd"C:/projects/NIH2009/source/branches/trunk/build/Windows-6.1/ouput/bin/Debug/dvipdicomsvr.pdb" /W3 /c /Zi /TP /Zm1000 "..\..\..\..\..\source\cpp\app\testing\dicomserver\src\main.cpp" "..\..\..\..\..\source\cpp\app\testing\dicomserver\src\dcmtksvr.cpp" ] include: C:\projects\NIH2009\source\branches\trunk\source\cpp\app\testing\dicomserver\include Why? Why I care: Lets say that I someone wants to check the Visual Studio project goop produced by CMake in trunk and check out in a diffrent directory in their branch on another machine. With absolute paths sprinkled all over effectively makes this impossible. -- Brian J. Davis ___ 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] What is a good way to exclude default library locations from install-tree rpaths?
Thanks, Alex, for responding to my questions. On 2010-02-02 21:23+0100 Alexander Neundorf wrote: On Friday 29 January 2010, Alan W. Irwin wrote: If target_link_libraries is given the full path to an external library, then by default CMake uses rpath on Linux so that library is found at run time for the build tree. For PLplot I have adjusted the RPATH options so that the install-tree rpath is similarly well determined for all our external libraries. However, there is one difference between the build-tree rpaths handled automatically by CMake and our install-tree rpaths that I would like to address. CMake is smart enough so that standard locations (e.g., /usr/lib) which are automatically searched in any case by the run-time loader are filtered out of the build-tree rpaths. Currently, I don't have any functionality for removing standard locations from the install-tree rpaths. Therefore, I am getting the following results from the install: -- Set runtime path of "/home/software/plplot_svn/installcmake/lib/libplplotd.so .9.7.0" to "/home/software/plplot_svn/installcmake/lib:/usr/lib:/home/software/qhull/i nstall/lib" So /usr/lib doesn't appear in the build tree RPATH, but it does in the install RPATH ? Yes. I think cmake uses the CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES variable, which is set in UnixPaths.cmake Which of the following two modes are you using ? - explicitely specify the RPATH you want to have (wouldn't that work if it just for the libs you installed yourself, so you know the install locations ?) - let cmake automatically compute the full RPATH by enabling the target property INSTALL_RPATH_USE_LINK_PATH The PLplot CMake-based build system does not use INSTALL_RPATH_USE_LINK_PATH. Instead, it explicitly sets the INSTALL_RPATH target property. The problem is that we have many different library dependencies so contributions to that INSTALL_RPATH come from all over our build system depending on options that the user sets controlling which components of PLplot are built. Also, for some of those dependent libraries, the user has the option to use the system versions or ones that are installed in a special location. Also, we have a number of plugins and libraries where rpath has to be set up. So it is all pretty complicated and preferably the filtering of default locations should be done automatically for wherever the install_RPATH target property is used, but since it currently is not done automatically, I have to implement filtering myself. It looks like your suggestion above to use the CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES variable for this purpse is a good one. To (slightly) correct one thing you said though, UnixPaths.cmake appends to it as do other Unix-platform-dependent files in Modules/Platform. As a double-check, I have just printed out that variable on my (Debian Lenny) platform using cmake-2.8.0. The result is -- CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES = /lib;/usr/lib;/usr/lib32;/usr/lib64 which agrees with what is in UnixPaths.cmake and seems to be exactly what I need to do automatic filtering of the list that is used for the INSTALL_RPATH target property. However, for cmake-2.6.4 there is a bug, and the result is a duplicated list of what appears in UnixPaths.cmake: -- CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES = /lib;/usr/lib;/usr/lib32;/usr/lib64;/lib;/usr/lib;/usr/lib32;/usr/lib64 I notice on the cmake-2.8.0 version you have some extra logic to deal with when UnixPaths.cmake is called twice so the absence of that logic for the cmake-2.6.4 version is probably why the list is getting duplicated. However, it is easy to work around that duplicate list issue using if(CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES) list(REMOVE_DUPLICATES CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES) endif(CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES) So to summarize this, I plan to filter all the many INSTALL_RPATH target properties I set in various parts of our build system for our applications and libraries using the CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES variable, but a much cleaner way to do this would be if CMake itself automatically filtered INSTALL_RPATH. Therefore, I hope that CMake fix is implemented. (I assume here you always want to filter out the standard locations from rpath for the installed applications and libraries. This is the assumption CMake appears to make for the build-tree versions of those applications and libraries.) Is that a trivial fix or do you want me to make a wish-list bug so the idea doesn't get lost? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linu
[CMake] File permissions on CONFIGURE_FILE output
I run CONFIGURE_FILE on a file that is read only. The output file is also read only, which is a problem because I need to append to it. Is there a way to change this behavior? Or a work around? - Aaron Wright ___ 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] List of components being build.
My current project has many components that need to be built. Some portions of
our code depend on others and using add_subdirectory, I am having an issue
where I get multiple of my targets loaded causing a faliure.
I placed the add_subdirectory in a macro that uses a simple hash style of access
set ( BUILD_MAP_${_name} 1 ) where ${_name} is the target name.
I have an if statement in the macro that tests if BUILD_MAP_${_name} is
defined. The issue is say I have a custom mysqlclient that is used by 3 of my
projects that are all built as part of "all".
Project A: Depends on Mysqlclient
Project B: Depends on Mysqlclient
Project C: Depends on Mysqlclient
Dir structure
all/
/lib/Mysqlclient
/bin/Project A
/bin/Project B
/bin/Project C
each of these folders have a CMakeLists.txt. The all/CMakeLists.txt has the
following
project(all)
add_subdirectory(lib/Mysqlclient)
add_subdirectory(bin/Project A)
add_subdirectory(bin/Project B)
add_subdirectory(bin/Project C)
When building from the top level and having a definition of "-lmysqlclient"
everything works as expected. The issue comes up when I do not want to build
all of the source.
Say I would like to build only Project B.
from my build directory, I would run cmake ~/all/Project B.
The cmake process ends without issue, but the make fails on link due to the
missing Mysqlclient library not being built. I want to be able to declare
dependencies for each project that way I can build each seperately from the top
level. So far using a macro to do the add_subdirectory fails because even
though I check to see if BUILD_MAP_${_name} is defined, the add_subdirectory
command is still run as if the BUILD_MAP_${_name} is not defined (if defined,
only an add_dependencies should be run)
Any help would be greatly appreciated.
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If you
are not the intended recipient, you should delete this message. Any disclosure,
copying, or distribution of this message, or the taking of any action based on
it, is strictly prohibited.
___
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] Inherited project settings
So I have various CMakeLists.txt files in my directory structure. Some with the PROJECT( name ) specified at the top and some without. I am using add_sub directory to add each directory. /CMakeLists.txt /source/cpp/app/CMakeLists.txt /source/cpp/app/someapp/CMakeLists.txt /source/cpp/lib/CmakeLists.txt source/cpp/lib/somelib For the subdirectory structure above build settings for someapp will inherit from app/CMakeLists.txt and the top level CMakeLists.txt file. However if the build directories and include paths are set for libraries in /source/cpp/lib/CmakeLists.txt how would apps see these. Is there a way for one project to inherit project settings from another project which is not in the path from the originating subproject CMakeLists.txt (app/CMakeLists.txt) up to the root CMakeLists.txt? For example is there a way for apps to inherit project settings in libs (such as include paths) without having to use CACHE STRING "" FORCE and having to move these vars up the path to the root CMakeLists.txt file. Is there also a way to disable recursive sub directory project inheritance in CMake? Is there another name I can give to my CMakeLists.txt files that CMake will parse in add_subdirectory? I have multiple CMakeLists.txt files open in eclipse and can never keep which one is which straight (they all have the same name). I also noticed that if I have a CMakeLists.txt in between the top/root level CMakeLists.txt without the PROJECT( name ) in the file that include paths added at the intermediary CMakeLists.txt using INCLUDE_DIRECTORIES( wherever) are still inherited. -- Brian J. Davis ___ 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] What is a good way to exclude default library locations from install-tree rpaths?
On Friday 29 January 2010, Alan W. Irwin wrote: > If target_link_libraries is given the full path to an external library, > then by default CMake uses rpath on Linux so that library is found at run > time for the build tree. For PLplot I have adjusted the RPATH options so > that the install-tree rpath is similarly well determined for all our > external libraries. > > However, there is one difference between the build-tree rpaths handled > automatically by CMake and our install-tree rpaths that I would like to > address. CMake is smart enough so that standard > locations (e.g., /usr/lib) which are automatically searched in any case by > the run-time loader are filtered out of the build-tree rpaths. > Currently, I don't have any functionality for removing standard locations > from the install-tree rpaths. Therefore, I am getting the following > results from the install: > > -- Set runtime path of > "/home/software/plplot_svn/installcmake/lib/libplplotd.so .9.7.0" to > "/home/software/plplot_svn/installcmake/lib:/usr/lib:/home/software/qhull/i >nstall/lib" So /usr/lib doesn't appear in the build tree RPATH, but it does in the install RPATH ? I think cmake uses the CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES variable, which is set in UnixPaths.cmake Which of the following two modes are you using ? - explicitely specify the RPATH you want to have (wouldn't that work if it just for the libs you installed yourself, so you know the install locations ?) - let cmake automatically compute the full RPATH by enabling the target property INSTALL_RPATH_USE_LINK_PATH 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
Re: [CMake] Java Support
On Friday 22 January 2010 1:37:50 pm David Cole wrote:
> If you are a Java guru, I would appreciate your review and comments on this
> issue, which has been in our issue tracker for a while now. If you have a
> good suggestion for the best way to fix it, I would love to hear it.
>
> http://public.kitware.com/Bug/view.php?id=7832
>
> And here's a link to all of the "java related" issues in the tracker (even
> the closed ones, just a simple search on the word "java" in the CMake
> project portion of the issue tracker):
>
http://public.kitware.com/Bug/search.php?project_id=2&search=java&sticky_is
>
sues=off&sortby=severity%2Cpriority&dir=DESC%2CDESC&hide_status_id=-2
>
>
> Thanks,
> David Cole
> Kitware, Inc.
>
I've been looking into Java (getting a feel for it's build process and I've
determined that the CMAKE_Java_LINK_EXECUTABLE should possibly look
something like this:
IF(NOT ${CMAKE_Java_LINK_EXECUTABLE})
STRING(REGEX REPLACE "\/"
CMAKE_Java_ENTRY_POINT "")
SET(CMAKE_Java_LINK_EXECUTABLE
" -cf -e -C
")
ENDIF(NOT ${CMAKE_Java_LINK_EXECUTABLE})
I know I'm using the STRING() macro incorrectly and was wondering if there
was a good example of its usage. This should allow us to get the main
method into the jar's manifest for a pseudo static linked executable. I'm
sure there are other problems with this idea but I'm open to suggestions at
this point.
Regards,
Alex Brandt
--
B.S. Physics & Computer Science
Minnesota State University Moorhead
www.alunduil.com
signature.asc
Description: This is a digitally signed message part.
___
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] No output from GLOBAL_DEPENDS_DEBUG_MODE property and LINK_DIRECTORIES property
Hello,
Before I describe my problem, I will supply some background information: I am
running CMake 2.8 and Visual C++ 2005 SP1 on Windows XP SP Pro SP3. I am
investigating why some of the DLLs I am building have started to have
unexpected dependencies, making them larger than necessary. This problem is
only occurring when I use CMake to build my application with command-line tools
as part of a nightly build. It does not occur when I use CMake to generate
Visual C++ solution and project files and build using the Visual Studio IDE.
This is so despite the fact that there is no apparent significant difference
between the CMakeCache.txt files generated for each of these builds.
For my nightly builds, I run CMake via a script passed to CTest as shown below:
ctest -S "nightly_script.cmake"
At the end of that script I've added:
SET_PROPERTY(GLOBAL PROPERTY GLOBAL_DEPENDS_DEBUG_MODE 1)
CTest is invoked from a batch file, and when I run that batch file I redirect
both stdout and stderr into a log file, as shown below:
NIGHTLY.BAT >> C:\BuildLogs\NightlyLog 2>&1
Since the documentation for GLOBAL_DEPENDS_DEBUG_MODE says...
"This property causes it to display details of its analysis to stderr."
I expected to see additional data in my log file, but I don't see anything new.
Can anyone suggest why?
I also tried to use the LINK_DIRECTORIES property (not the command) to collect
information that might prove relevant. I understand that this property must be
invoked after the specified directory has been processed by CMake, so I placed
it at the bottom of the CMakeLists.txt file for the directory in question, as
shown below:
GET_PROPERTY(linkdirs DIRECTORY C:/MyProject/MyDir PROPERTY LINK_DIRECTORIES)
MESSAGE("MyDir LINK_DIRECTORIES=${linkdirs}")
I am finding no output from these commands either. Not in my log file and not
in the "LastBuild" log produced by CTest (which contains data such as compiler
output such as warnings and errors). If I put the commands in the
CMakeLists.txt file of another directory, or at the bottom of my
nightly_script.cmake file, my log file displays an error saying the directory
was not found because it was invalid or not processed yet. Can anyone suggest
how I can get to see the value of the LINK_DIRECTORIES property in one of my
log files?
Thanks, in advance, for any help that may be forthcoming.
_
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/___
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] Build only what you need in third party libs
Here is the latest which includes wroking build of dcmtk NOTE the additon of
-DINSTALL_PREFIX=${INSTALL_PREFIX} as dcmtk required this move its install
eventhought CMAKE_INSTALL_PREFIX was specified. Boost is still not building
as boost wave and serialization do not build, but hey I guess 82 out of 84
packages isn't bad odds. Also not the removal of "in" in the foreach
block. An error on my part above.
The addition of BINARY_DIR ${BUILD_DIR}/ouput/bin/${PACKAGE} as suggested by
David works. Thanks David.
SET( THIRD_PARTY_PACKAGES
vtk-5.4.2
dcmtk-3.5.4
boost-cmake-1_41_0
)
foreach( PACKAGE ${THIRD_PARTY_PACKAGES} )
ExternalProject_Add(
${PACKAGE}
DOWNLOAD_COMMAND ""
SOURCE_DIR ${TOP}/source/cpp/lib/3rdParty/Win/${PACKAGE}
BINARY_DIR ${BUILD_DIR}/ouput/bin/${PACKAGE}
INSTALL_DIR ${INSTALL_PREFIX}
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX}
-DINSTALL_PREFIX=${INSTALL_PREFIX}
)
endforeach( PACKAGE )
I just wanted to post and update with some corrections for those who may
find this useful.
--
Brian J. Davis
___
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] Multiple libraries, same name...
Ryan C. Gordon wrote:
I'm trying to add bindings for various scripting languages to my library
PhysicsFS ( http://icculus.org/physfs/ ), and I'm having some trouble.
Eventually I end up with something like this abbreviated example for the
Perl bindings...
# This is the actual main library, not the binding.
ADD_LIBRARY(physfs SHARED whatever)
# This is the binding.
ADD_LIBRARY(physfs-perl SHARED "physfs-perl.c")
TARGET_LINK_LIBRARIES(physfs-perl physfs)
SET_TARGET_PROPERTIES(physfs-perl PROPERTIES OUTPUT_NAME "physfs")
INSTALL(TARGETS physfs-perl LIBRARY DESTINATION "${_INSTALLPATH}")
See this property:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LIBRARY_OUTPUT_DIRECTORY
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
___
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] CoreGraphics framework
Thanks a lot now I get it. -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Wild Sent: Tuesday, February 02, 2010 1:48 PM To: Martin Guillon Cc: cmake@cmake.org Subject: Re: [CMake] CoreGraphics framework On 2. Feb, 2010, at 12:05 , Martin Guillon wrote: > Hi, > > I am trying to include CGEvent.h in my cmake project. So I need to include > CoreGraphics framework. > > So I added > FIND_LIBRARY(APP_SERVICES ApplicationServices "/") > FIND_LIBRARY(COREGRAPHICS CoreGraphics "/") in my cmakelists But the > CoreGraphics Framework is in the Application Services Framework so I > don't see how to include it :s > > I tried #include or > #include > > But nothing works... > > Any help ? > > THanks According to http://developer.apple.com/Mac/library/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/IncludingFrameworks.html it is not possible to include header files from sub-frameworks. The only way is to include ApplicationServices/ApplicationServices.h And your find_library call should not need to specify a path: find_library(APP_SERVICES ApplicationServices) The way you call find_library is actually invalid. HTH 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 ___ 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] CoreGraphics framework
On 2. Feb, 2010, at 12:05 , Martin Guillon wrote: > Hi, > > I am trying to include CGEvent.h in my cmake project. So I need to include > CoreGraphics framework. > > So I added > FIND_LIBRARY(APP_SERVICES ApplicationServices "/") > FIND_LIBRARY(COREGRAPHICS CoreGraphics "/") in my cmakelists > But the CoreGraphics Framework is in the Application Services Framework so I > don't see how to include it :s > > I tried #include or #include > > > But nothing works... > > Any help ? > > THanks According to http://developer.apple.com/Mac/library/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/IncludingFrameworks.html it is not possible to include header files from sub-frameworks. The only way is to include ApplicationServices/ApplicationServices.h And your find_library call should not need to specify a path: find_library(APP_SERVICES ApplicationServices) The way you call find_library is actually invalid. HTH 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] Compaq Visual Fortran
Hi Brad, On 2010-02-02 13:38, Brad King wrote: Arjen Markus wrote: Hi Brad, I just tested the patch - Compaq Visual Fortran is recognised, but not accepted - and added the Windows-f90.cmake file from the PLplot project to CMake's Modules\Platform directory. Now the compiler is accepted as well. The "Windows-f90.cmake" name is the old naming convention that depended on the compiler executable name. The new convention is --.cmake where =Windows, =Compaq, =Fortran in this case. I've committed the rest of the changes needed to recognize Compaq: Recognize the Compaq Fortran compiler /cvsroot/CMake/CMake/Modules/CMakeDetermineFortranCompiler.cmake,v <-- Modules/CMakeDetermineFortranCompiler.cmake new revision: 1.29; previous revision: 1.28 Rename Windows-f90.cmake to Windows-Compaq-Fortran.cmake and put it in your project under CMAKE_MODULE_PATH (under a Platform/ directory). This should enable support in your project without needing any patches to the current CMake in CVS HEAD. I will test that. Windows-f90.cmake in its current form is not ready for inclusion in upstream CMake as Windows-Compaq-Fortran.cmake. It sets several variable that are not related specifically to Fortran. We need to refactor it a bit. Please submit a feature request in the issue tracker and include the module for further discussion. Will do that. Note: I just saw there is already a Windows-df.cmake file in the repository, but I guess "df.exe" is not used as the name for a possible compiler. That's a patch from you in 2006: http://www.cmake.org/Bug/view.php?id=3950 :) I thought it was (actually based on work by somebody else). Regards, Arjen ___ 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] Compaq Visual Fortran
Arjen Markus wrote: > Hi Brad, > > I just tested the patch - Compaq Visual Fortran is recognised, > but not accepted - and added the Windows-f90.cmake file from the > PLplot project to CMake's Modules\Platform directory. Now the > compiler is accepted as well. The "Windows-f90.cmake" name is the old naming convention that depended on the compiler executable name. The new convention is --.cmake where =Windows, =Compaq, =Fortran in this case. I've committed the rest of the changes needed to recognize Compaq: Recognize the Compaq Fortran compiler /cvsroot/CMake/CMake/Modules/CMakeDetermineFortranCompiler.cmake,v <-- Modules/CMakeDetermineFortranCompiler.cmake new revision: 1.29; previous revision: 1.28 Rename Windows-f90.cmake to Windows-Compaq-Fortran.cmake and put it in your project under CMAKE_MODULE_PATH (under a Platform/ directory). This should enable support in your project without needing any patches to the current CMake in CVS HEAD. Windows-f90.cmake in its current form is not ready for inclusion in upstream CMake as Windows-Compaq-Fortran.cmake. It sets several variable that are not related specifically to Fortran. We need to refactor it a bit. Please submit a feature request in the issue tracker and include the module for further discussion. > Note: I just saw there is already a Windows-df.cmake file in the > repository, but I guess "df.exe" is not used as the name for a > possible compiler. That's a patch from you in 2006: http://www.cmake.org/Bug/view.php?id=3950 -Brad ___ 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] Error while moc generating in multiple projects
Hello, I have a project in QT4 and now I'm including another project within this (add_subdirectory). I'll post here a summary of the directory structure of the projects: Project1 + src + engine + updater (this directory is Project 2) When compiling, it returned me the following error: ... [ 99%] Generating qrc_TraderUpdater.cxx [ 99%] Generating updater/TrdUpdater.moc moc: Cannot create /home/marcelo/Trader/build/src/updater/updater/TrdUpdater.moc make[2]: ** [src/updater/updater/TrdUpdater.moc] Erro 1 make[1]: ** [src/updater/CMakeFiles/TraderUpdater.dir/all] Erro 2 make: ** [all] Erro 2 The message is clear, it is not possible to create a subdirectory with the same name, but how do I fix this? Thanks for the help. -- Marcelo E. Geyer ___ 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] Compaq Visual Fortran
Hi Brad,
I just tested the patch - Compaq Visual Fortran is recognised,
but not accepted - and added the Windows-f90.cmake file from the
PLplot project to CMake's Modules\Platform directory. Now the
compiler is accepted as well.
Note: I just saw there is already a Windows-df.cmake file in the
repository, but I guess "df.exe" is not used as the name for a
possible compiler.
Regards,
Arjen
On 2010-02-01 15:26, Brad King wrote:
Arjen Markus wrote:
On 2010-01-28 17:18, Brad King wrote:
Thanks. Undo the previous patch and try the one below instead.
I applied the patch and it all worked fine. That is, CMake now
recognises the compiler but does not test it with the correct
compile flags (-o being reported as ambiguous). I can send the
error report if you want.
At least we have a succesful first step.
Great. I've committed the underlying compiler id method to
CMake upstream, plus a test:
Add alternate per-vendor compiler id detection
/cvsroot/CMake/CMake/Modules/CMakeDetermineCompilerId.cmake,v <--
Modules/CMakeDetermineCompilerId.cmake
new revision: 1.22; previous revision: 1.21
/cvsroot/CMake/CMake/Tests/CMakeTests/CMakeLists.txt,v <--
Tests/CMakeTests/CMakeLists.txt
new revision: 1.26; previous revision: 1.25
/cvsroot/CMake/CMake/Tests/CMakeTests/CompilerIdVendorTest.cmake.in,v <--
Tests/CMakeTests/CompilerIdVendorTest.cmake.in
new revision: 1.2; previous revision: 1.1
I did not yet commit the actual Compaq compiler entry. That
will be just the patch below. Please try CMake HEAD from CVS
plus the patch below. Then add Compaq compiler support by
creating a "Platform/Windows-Compaq-Fortran.cmake" file that
sets the build rules and flags for that compiler. Content will
be similar to the Windows-f90.cmake file that Alan sent.
-Brad
diff --git a/Modules/CMakeDetermineFortranCompiler.cmake
b/Modules/CMakeDetermineFortranCompiler.cmake
index 44e45d8..0637d20 100644
--- a/Modules/CMakeDetermineFortranCompiler.cmake
+++ b/Modules/CMakeDetermineFortranCompiler.cmake
@@ -162,6 +162,11 @@ IF(NOT CMAKE_Fortran_COMPILER_ID_RUN)
"-fpp"
)
+ # Table of per-vendor compiler id flags with expected output.
+ LIST(APPEND CMAKE_Fortran_COMPILER_ID_VENDORS Compaq)
+ SET(CMAKE_Fortran_COMPILER_ID_VENDOR_FLAGS_Compaq "-what")
+ SET(CMAKE_Fortran_COMPILER_ID_VENDOR_REGEX_Compaq "Compaq Visual Fortran")
+
# Try to identify the compiler.
SET(CMAKE_Fortran_COMPILER_ID)
INCLUDE(${CMAKE_ROOT}/Modules/CMakeDetermineCompilerId.cmake)
___
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] CoreGraphics framework
Hi, I am trying to include CGEvent.h in my cmake project. So I need to include CoreGraphics framework. So I added FIND_LIBRARY(APP_SERVICES ApplicationServices "/") FIND_LIBRARY(COREGRAPHICS CoreGraphics "/") in my cmakelists But the CoreGraphics Framework is in the Application Services Framework so I don't see how to include it :s I tried #include or #include But nothing works... Any help ? THanks ___ 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
