Re: [CMake] FindMPI: finding openmpi libs and includes
You have this snippet in there:
set(_MPI_PREFIX_PATH)
if(WIN32)
list(APPEND _MPI_PREFIX_PATH
[HKEY_LOCAL_MACHINE\\SOFTWARE\\MPICH\\SMPD;binary]/..)
list(APPEND _MPI_PREFIX_PATH
[HKEY_LOCAL_MACHINE\\SOFTWARE\\MPICH2;Path])
endif()
foreach(SystemPrefixDir ${CMAKE_SYSTEM_PREFIX_PATH})
foreach(MpiPackageDir ${_MPI_PREFIX_PATH})
MESSAGE(STATUS ${SystemPrefixDir}/${MpiPackageDir})
if(EXISTS ${SystemPrefixDir}/${MpiPackageDir})
list(APPEND _MPI_PREFIX_PATH ${SystemPrefixDir}/${MpiPackageDir})
endif()
endforeach(MpiPackageDir)
endforeach(SystemPrefixDir)
For openmpi for e.g, a possible install path is c:\program
files\openmpi\bin, lib, include, share
Should _MPI_PREFIX_PATH include openmpi then?
_MPI_PREFIX_PATH is appended to inside the foreach loops, but is used at
the same time as the index of the iteration?
From: Dave Partyka [mailto:dave.part...@kitware.com]
Sent: 30 November 2010 22:42
To: Hicham Mouline
Cc: CMake mailing list
Subject: Re: [CMake] FindMPI: finding openmpi libs and includes
It will search standard locations (/usr/include /usr/lib) for the headers
and libs. Set MPI_LIBRARY and MPI_INCLUDE_PATH if it doesn't locate them for
you automatically. The FindMPI module does interrogate the mpicc compiler
for some of this information but I am not sure if that is the case on
Windows.
On Tue, Nov 30, 2010 at 5:26 PM, Hicham Mouline hic...@mouline.org wrote:
Hi,
I have built debug and release win32 and x64 openmpi libs for windows, and I
have them installed on linux x64.
How does FindMPI work for auto detecting If I don't set any MPI_ variable at
all?
Does it search for mpic++ in the %PATH% or $PATH?
What MPI_ variables is the user required to define?
regards,
___
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] FindMPI: finding openmpi libs and includes
Isn't the red bold line with arrows after it intended to be:
foreach(MpiPackageDir ${(_MPI_PACKAGE_DIR })
instead?
_
You have this snippet in there:
set(_MPI_PACKAGE_DIR
mpi
mpich
openmpi
lib/mpi
lib/mpich
lib/openmpi
MPICH/SDK
Microsoft Compute Cluster Pack
)
set(_MPI_PREFIX_PATH)
if(WIN32)
list(APPEND _MPI_PREFIX_PATH
[HKEY_LOCAL_MACHINE\\SOFTWARE\\MPICH\\SMPD;binary]/..)
list(APPEND _MPI_PREFIX_PATH
[HKEY_LOCAL_MACHINE\\SOFTWARE\\MPICH2;Path])
endif()
foreach(SystemPrefixDir ${CMAKE_SYSTEM_PREFIX_PATH})
foreach(MpiPackageDir ${_MPI_PREFIX_PATH})
MESSAGE(STATUS ${SystemPrefixDir}/${MpiPackageDir})
if(EXISTS ${SystemPrefixDir}/${MpiPackageDir})
list(APPEND _MPI_PREFIX_PATH ${SystemPrefixDir}/${MpiPackageDir})
endif()
endforeach(MpiPackageDir)
endforeach(SystemPrefixDir)
From: Dave Partyka [mailto:dave.part...@kitware.com]
Sent: 30 November 2010 22:42
To: Hicham Mouline
Cc: CMake mailing list
Subject: Re: [CMake] FindMPI: finding openmpi libs and includes
It will search standard locations (/usr/include /usr/lib) for the headers
and libs. Set MPI_LIBRARY and MPI_INCLUDE_PATH if it doesn't locate them for
you automatically. The FindMPI module does interrogate the mpicc compiler
for some of this information but I am not sure if that is the case on
Windows.
On Tue, Nov 30, 2010 at 5:26 PM, Hicham Mouline hic...@mouline.org wrote:
Hi,
I have built debug and release win32 and x64 openmpi libs for windows, and I
have them installed on linux x64.
How does FindMPI work for auto detecting If I don't set any MPI_ variable at
all?
Does it search for mpic++ in the %PATH% or $PATH?
What MPI_ variables is the user required to define?
regards,
___
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
[CMake] CMake Xcodeproject
Hi, i send this message to the mailing list bevor but nobody answer!! i create an Xcodeproject with CMake and when i build it, it get's this error's: In file included from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIApplication.h:13, from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:13, from ../Desktop/iPad/Classes/iPadAppDelegate.h:9, from ../Desktop/iPad/Classes/iPadAppDelegate.m:9: /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIDevice.h:33: error: expected identifier before '}' token /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIDevice.h:74: error: expected specifier-qualifier-list before 'UIUserInterfaceIdiom' In file included from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:71, from ../Desktop/iPad/Classes/iPadAppDelegate.h:9, from ../Desktop/iPad/Classes/iPadAppDelegate.m:9: /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UITextView.h:88: error: expected specifier-qualifier-list before 'UIDataDetectorTypes' ... If necessary I will send the CMakeLists.txt Anyone know what I missed or am doing wrong please? i hope somebody answer me. Thanks -- View this message in context: http://cmake.3232098.n2.nabble.com/CMake-Xcodeproject-tp5791404p5791404.html Sent from the CMake mailing list archive at Nabble.com. ___ 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 subject)
I have a Visual Studio 2010 solution and I am trying to set the
Configuration Properties - General - Platform Toolset of one
particular project to use V90 to allow this project to build with the VS
2008 tool set. I followed an older thread and tried this:
set_target_properties(WindowsApplication${version} PROPERTIES
PlatformToolset V90)
That results in an error: set_target_properties Can not find target to
add properties to. ${version} is set to a version string and the term
WindowsApplication${version} is used later in the file by an
add_library and a target_link_library with no error. How can I set the
platform toolset to V90 from CMAKE?
Gary G. Little
___
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] providing library information, what's the cmake way
On 11/30/2010 01:32 PM, Johannes Zarl wrote:
- Do multiple consecutive FIND_PACKAGE(XXX ...) invocations act in an
accumulative manner on the invocation-specific variables?
Generally speaking, I would say: yes. At least this is the way of the
least surprise for the user, as in sufficiently complex projects a
package may be included at different places with different arguments.
For the same reason, I'd tend to the opposite; look at the following:
FIND_PACKAGE(XXX COMPONENTS YYY)
...
ADD_SUBDIRECTORY(subdir)
In subdir/CMakeLists.txt:
FIND_PACKAGE(XXX COMPONENTS ZZZ)
...
TARGET_LINK_LIBRARIES(... ${XXX_LIBRARIES})
Here, the target is also linked against XXX_YYY_LIBRARY as the latter is
inherited via XXX_LIBRARIES from the parent directory, but if the target
only needs XXX_ZZZ_LIBRARY it will possibly be overlinked. Although this
can be avoided by resetting XXX_LIBRARIES before each FIND_PACKAGE()
invocation, I don't think that's the way one would like to go.
IMO, the invocation-specific results of any FIND_PACKAGE() call should
depend solely on the parameters passed in and the well-known variables
like CMAKE_PREFIX_PATH. The downside is that one must possibly process
or save the results before they could be overwritten, e.g.:
FIND_PACKAGE(XXX REQUIRED YYY)
SET(LIBRARIES ${XXX_LIBRARIES})
FIND_PACKAGE(XXX COMPONENTS ZZZ)
LIST(APPEND LIBRARIES ${XXX_LIBRARIES})
...
TARGET_LINK_LIBRARIES(... ${LIBRARIES})
Since such related calls to FIND_PACKAGE(XXX ...) usually occur nearby
each other within the same CMakeLists.txt, this little penalty should
be acceptable whereas accumulated XXX_LIBRARIES and the like may have
far reaching and surprising effects, especially in complex projects.
Funny enough, my example is almost the same:
FIND_PACKAGE(XXX COMPONENTS YYY)
...
ADD_SUBDIRECTORY(subdir)
...
TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
TARGET_LINK_LIBRARIES(BBB ${XXX_LIBRARIES} ${XXX_YYY_LIBRARIES})
In subdir/CMakeLists.txt:
FIND_PACKAGE(XXX COMPONENTS ZZZ)
...
TARGET_LINK_LIBRARIES(subBBB ${XXX_LIBRARIES} ${XXX_ZZZ_LIBRARIES})
As I mentioned above, I would expect XXX_LIBRARIES to contain only the
base library, and find_package calls to act accumulatively.
If I understand correctly, you'd like to have a set of variables like
XXX_*_{LIBRARIES,INCLUDE_DIRS,...} for each component instead of one
comprehensive set XXX_{LIBRARIES,INCLUDE_DIRS,...} for the entire
package including the components; this hasn't been obvious to me.
Nevertheless, what do you understand by accumulative in this regard,
i.e. what accumulates in which variables if FIND_PACKAGE() is invoked
multiple times and each component has an independent set of variables
separate from the package's base stuff?
If it was otherwise, then target AAA would be overlinked, and BBB would
probably fail to link. Even without the ADD_SUBDIRECTORY the situation
would be far from ideal: in order to avoid overlinking of BBB I have to
make an additional find_package invocation. In a worst-case scenario one
would need multiple find_package invocations for the same packages before
each target!
At first, BBB could not fail to link due to the FIND_PACKAGE() in the
subdir/CMakeLists.txt because the XXX_LIBRARIES variable in the parent
directory is not modified unless the find module uses the PARENT_SCOPE
option of SET(), but there's no reason to do so as it is pretty unwise.
In contrast, the potential overlinking of AAA is a point, indeed, as it
is generally with multiple targets, each depending on an individual set
of components, within the same CMakeLists.txt. Here, I'd actually need
to call FIND_PACKAGE() multiple times and immediately process/save the
variables like XXX_LIBRARIES if they're really invocation-specifically
populated, but I'm in doubt whether this can be reckoned as far from
ideal. Note that because of CMake's caching, repeated invocations of
FIND_PACKAGE() don't tend to be expensive, so
FIND_PACKAGE(XXX COMPONENTS base)
TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
FIND_PACKAGE(XXX COMPONENTS base YYY)
TARGET_LINK_LIBRARIES(BBB ${XXX_LIBRARIES})
is nothing I'd be afraid of. Moreover, in subdir/CMakeLists.txt, you
have to call FIND_PACKAGE() anew anyway, as you've also when mixing
optional and required components with a usage of the REQUIRED flag.
The accumulative scenario of find_package without side-effects of the
components on the XXX_LIBRARIES is far more transparent:
If you link against XXX_LIBRARIES, you know exactly what you are linking
against, regardless of who called find_package(XXX) with whatever
components since you did your find_package call. You don't even have to
backup your XXX_LIBRARIES and other variables, because they are not
altered.
The downside of your approach is that you have to mention component-
specific variables at various locations: For each component denoted
in the FIND_PACKAGE() invocation, you would usually have to mention
- XXX_*_INCLUDE_DIRS in
Re: [CMake] (no subject)
On 12/01/2010 03:45 PM, Gary%20G.%20Little%20%40%20comcast wrote:
I have a Visual Studio 2010 solution and I am trying to set the
Configuration Properties - General - Platform Toolset of one
particular project to use V90 to allow this project to build with the VS
2008 tool set. I followed an older thread and tried this:
set_target_properties(WindowsApplication${version} PROPERTIES
PlatformToolset V90)
That results in an error: set_target_properties Can not find target to
add properties to. ${version} is set to a version string and the term
WindowsApplication${version} is used later in the file by an
add_library and a target_link_library with no error. How can I set the
platform toolset to V90 from CMAKE?
SET_TARGET_PROPERTIES() must not appear before the targets it
operates on, so move this command behind the ADD_LIBRARY().
Regards,
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] Makefile to CMakeLists.txt (GTEST)
Philip,
Thx for the reply. Neither of these solutions change a thing.
I try to play with ADD_CUSTOM_TARGET but same error...
ADD_CUSTOM_TARGET(RRThread.o ALL COMMAND ${CMAKE_C_COMPILER} -I
${MICRONTRACKER_COMMON_PATH} -I${GTEST_HEADER_PATH} -lpthread -c
${MICRONTRACKER_COMMON_PATH}RRThread.c
${UNIT_TEST_PATH}common/UT_RRThread.cc)
ADD_CUSTOM_TARGET(UT_RRThread ALL COMMAND ${CMAKE_CXX_COMPILER} -I
${MICRONTRACKER_COMMON_PATH} -I${GTEST_HEADER_PATH} -lpthread RRThread.o
UT_RRThread.o ${GTEST_LIB_PATH}gtest.a ${GTEST_LIB_PATH}gtest_main.a -o
UT_RRThread)
Result:
UT_RRThread.o: In function `thread_proc(void*)':
UT_RRThread.cc:(.text+0x28): undefined reference to `exitThread()'
...
I pretty sure that I'm missing little detail. How can I implicitly add
dependency to the object during the linking?
Regards
--
Kevyn-Alexandre Paré
On Mon, 2010-11-29 at 18:17 -0500, Philip Lowman wrote:
Try adding the gtest.a library as well. Also, order does matter
when you are linking static libraries so you might need to play with
the ordering.
Also, when you get some time, have a look at FindGTest.cmake. It may
help you simplify adding your tests.
On Mon, Nov 29, 2010 at 5:55 PM, Kevyn-Alexandre Paré
kap...@rogue-research.com wrote:
Hi,
/// - What I trying to do is to compile my unit test with
google test
with cmake from a working Makefile.
/// - Here the Makefile
RRThread.o : $(USER_DIR)/RRThread.c $(USER_DIR)/RRThread.h
$(GTEST_HEADERS)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $(USER_DIR)/RRThread.c
UT_RRThread.o : $(UNITTEST_DIR)/UT_RRThread.cc \
$(USER_DIR)/RRThread.h $(GTEST_HEADERS)#
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -I$(USER_DIR) -c
$(UNITTEST_DIR)/UT_RRThread.cc
UT_RRThread : RRThread.o UT_RRThread.o gtest_main.a
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -lpthread $^ -o $@
/// - Here how I thought of doing it with CMakeLists.txt:::
INCLUDE_DIRECTORIES(${GTEST_HEADER} ${USER_DIR})
ADD_EXECUTABLE(UT ${USER_DIR}RRThread.c
${UNIT_TEST_PATH}UT_RRThread.cc)
TARGET_LINK_LIBRARIES(UT pthread
${GTEST_LIB_PATH}gtest_main.a)
/// - My result:
Linking CXX executable UT
/usr/bin/cmake -E cmake_link_script CMakeFiles/UT.dir/link.txt
--verbose=1
/usr/bin/c++ CMakeFiles/UT.dir/common/RRThread.c.o
CMakeFiles/UT.dir/UnitTests/common/UT_RRThread.cc.o -o UT
-rdynamic
-lpthread
/home/andromeda/rogue-research/3rdParty/gtest/trunk/Release/lib/gtest_main.a
CMakeFiles/UT.dir/UnitTests/common/UT_RRThread.cc.o: In
function
`thread_proc(void*)':
UT_RRThread.cc:(.text+0x28): undefined reference to
`exitThread()'
/// - My question and my problem is:
Since I'm including the USER_DIR with INCLUDE_DIRECTORIES why
is it
complaining about not finding reference that is in that header
file?
Best Regards,
--
Kevyn-Alexandre Paré
___
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
--
Philip Lowman
___
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] Linking archives in a sibling directory
On 12/01/2010 08:18 AM, Raymond Wan wrote:
Hi all,
I'm having a problem understanding how I can link to an archive in
another directory which is not a subdirectory. For example:
myproj
+-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
+-- CMakeLists.txt
+-- source files for sub-program A
+-- dir-B
+-- CmakeLists.txt
+-- source files for sub-program B
Basically, I would like to make a larger project (main) and I'm
building and testing each of its components separately.
Right now, the main's CMakeLists.txt looks something like this:
INCLUDE_DIRECTORIES (../dir-A)
SUBDIRS (../dir-A)
ADD_EXECUTABLE (main ${MAIN_SRCS})
TARGET_LINK_LIBRARIES (main subprogA_ar)
which works fine so far (the CMakeLists.txt in dir-A generates the
archive subprogA_ar).
However, I just found out that SUBDIRS is deprecated and so, replaced
it with ADD_SUBDIRECTORY. That's when I got an error about dir-A
not being a subdirectory. Obviously, I was not using SUBDIRS before
as it was intended... :-)
This error is caused by the fact that the directory dir-A is outside
the main directory tree, so dir-A's binary directory would likewise
be outside main's binary tree, and this is reasonably forbidden when
configuring main. You might specify dir-A's binary directory in
main/CMakeLists.txt explicitly, e.g.:
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
Hence, subprogA_ar will be built within the binary tree's dir-A.
I've also tried adding dir-A as a LINK_DIRECTORIES with no success.
It is unable to find subprogA_ar.
I'm not sure if it is possible, but ideally, when I run make in
main/, I would like it to rebuild the targets in dir-A (including
the archive) and link that in.
I'm also open to the possibility that I got the above organization all
wrong and should have only one large CMakeLists.txt in a directory
structure like this:
myproj
+-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
+-- source files for sub-program A
+-- dir-B
+-- source files for sub-program B
Is this what I should have done??
As an alternative, consider to add a CMakeLists.txt in myproj
CMAKE_MINIMUM_REQUIRED(...)
PROJECT(myproj)
ADD_SUBDIRECTORY(dir-A)
ADD_SUBDIRECTORY(dir-B)
ADD_SUBDIRECTORY(main)
and subsequently, configure this directory instead of main.
Regards,
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] VS 2010 PlatformToolset vc9
On 12/1/2010 9:45 AM, Gary%20G.%20Little%20%40%20comcast wrote:
I have a Visual Studio 2010 solution and I am trying to set the
Configuration Properties - General - Platform Toolset of one
particular project to use V90 to allow this project to build with the VS
2008 tool set. I followed an older thread and tried this:
set_target_properties(WindowsApplication${version} PROPERTIES
PlatformToolset V90)
That results in an error: set_target_properties Can not find target to
add properties to. ${version} is set to a version string and the term
WindowsApplication${version} is used later in the file by an
add_library and a target_link_library with no error. How can I set the
platform toolset to V90 from CMAKE?
Currently this is not supported. There is a feature request for it:
http://www.cmake.org/Bug/view.php?id=10722
See comments there for why it is not trivial to support VC9 tools
in the VS10 generator.
-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
Re: [CMake] CMake Xcodeproject
This looks like an issue with your code, rather than the build. Ryan On Wed, Dec 1, 2010 at 5:03 AM, salwa alqun...@hotmail.com wrote: Hi, i send this message to the mailing list bevor but nobody answer!! i create an Xcodeproject with CMake and when i build it, it get's this error's: In file included from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIApplication.h:13, from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:13, from ../Desktop/iPad/Classes/iPadAppDelegate.h:9, from ../Desktop/iPad/Classes/iPadAppDelegate.m:9: /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIDevice.h:33: error: expected identifier before '}' token /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIDevice.h:74: error: expected specifier-qualifier-list before 'UIUserInterfaceIdiom' In file included from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:71, from ../Desktop/iPad/Classes/iPadAppDelegate.h:9, from ../Desktop/iPad/Classes/iPadAppDelegate.m:9: /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.2.sdk/System/Library/Frameworks/UIKit.framework/Headers/UITextView.h:88: error: expected specifier-qualifier-list before 'UIDataDetectorTypes' ... If necessary I will send the CMakeLists.txt Anyone know what I missed or am doing wrong please? i hope somebody answer me. Thanks -- View this message in context: http://cmake.3232098.n2.nabble.com/CMake-Xcodeproject-tp5791404p5791404.html Sent from the CMake mailing list archive at Nabble.com. ___ 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 -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com Internal VRAC/HCI Site: http://tinyurl.com/rpavlik ___ 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] providing library information, what's the cmake way
On 12/01/2010 at 16:06, Michael Hertling mhertl...@online.de wrote:
FIND_PACKAGE(XXX COMPONENTS YYY)
...
ADD_SUBDIRECTORY(subdir)
...
TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
TARGET_LINK_LIBRARIES(BBB ${XXX_LIBRARIES} ${XXX_YYY_LIBRARIES})
In subdir/CMakeLists.txt:
FIND_PACKAGE(XXX COMPONENTS ZZZ)
...
TARGET_LINK_LIBRARIES(subBBB ${XXX_LIBRARIES} ${XXX_ZZZ_LIBRARIES})
As I mentioned above, I would expect XXX_LIBRARIES to contain only the
base library, and find_package calls to act accumulatively.
If I understand correctly, you'd like to have a set of variables like
XXX_*_{LIBRARIES,INCLUDE_DIRS,...} for each component instead of one
comprehensive set XXX_{LIBRARIES,INCLUDE_DIRS,...} for the entire
package including the components; this hasn't been obvious to me.
Correct.
Nevertheless, what do you understand by accumulative in this regard,
i.e. what accumulates in which variables if FIND_PACKAGE() is invoked
multiple times and each component has an independent set of variables
separate from the package's base stuff?
Ok, accumulative maybe wasn't the best choice of words. What I mean it
that subsequent find_package calls don't overwrite previous values.
I.e. the components accumulate, not the contents of some variable.
In other words, I would expect these two statements:
find_package(XXX REQUIRED YYY)
find_package(XXX COMPONENTS ZZZ)
to give me a working environment in which I can safely use XXX, YYY and,
if XXX_ZZZ_FOUND is true, ZZZ.
If it was otherwise, then target AAA would be overlinked, and BBB would
probably fail to link. Even without the ADD_SUBDIRECTORY the situation
would be far from ideal: in order to avoid overlinking of BBB I have to
make an additional find_package invocation. In a worst-case scenario one
would need multiple find_package invocations for the same packages before
each target!
At first, BBB could not fail to link due to the FIND_PACKAGE() in the
subdir/CMakeLists.txt because the XXX_LIBRARIES variable in the parent
directory is not modified unless the find module uses the PARENT_SCOPE
option of SET(), but there's no reason to do so as it is pretty unwise.
You are right. I didn't think about the scope.
In contrast, the potential overlinking of AAA is a point, indeed, as it
is generally with multiple targets, each depending on an individual set
of components, within the same CMakeLists.txt. Here, I'd actually need
to call FIND_PACKAGE() multiple times and immediately process/save the
variables like XXX_LIBRARIES if they're really invocation-specifically
populated, but I'm in doubt whether this can be reckoned as far from
ideal. Note that because of CMake's caching, repeated invocations of
FIND_PACKAGE() don't tend to be expensive, so
FIND_PACKAGE(XXX COMPONENTS base)
TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
FIND_PACKAGE(XXX COMPONENTS base YYY)
TARGET_LINK_LIBRARIES(BBB ${XXX_LIBRARIES})
is nothing I'd be afraid of. Moreover, in subdir/CMakeLists.txt, you
have to call FIND_PACKAGE() anew anyway, as you've also when mixing
optional and required components with a usage of the REQUIRED flag.
The accumulative scenario of find_package without side-effects of the
components on the XXX_LIBRARIES is far more transparent:
If you link against XXX_LIBRARIES, you know exactly what you are linking
against, regardless of who called find_package(XXX) with whatever
components since you did your find_package call. You don't even have to
backup your XXX_LIBRARIES and other variables, because they are not
altered.
The downside of your approach is that you have to mention component-
specific variables at various locations: For each component denoted
in the FIND_PACKAGE() invocation, you would usually have to mention
- XXX_*_INCLUDE_DIRS in INCLUDE_DIRECTORIES()
- XXX_*_LIBRARIES in TARGET_LINK_LIBRARIES()
- XXX_*_DEFINITIONS in ADD_DEFINITIONS()
Which is less work than saving all three values for each target that
I create.
in addition to the package's base stuff, i.e. roughly speaking, with n
components you need to reference 3+3n variables.
These 3+3n variables have to be defined, anyways (the find module needs
them internally, if it wants to compose XXX_INCLUDE_DIRS etc.).
Still, referencing the 3+3n variables are less work than having to
define _and_ reference 3N variables (with N being the number of targets
in your project).
IMO, this thwarts the
idea of a multi-component package: Specifying components to adjust the
well-known and officially recommended package-related variables like
XXX_LIBRARIES.
These variables are well-known and officially recommended for component-
less packages only. Nobody bothered to write recommendations for
component-packages yet.
BTW, what's the essential difference between a multi-
component package as you outline it and multiple single-component
packages, one for each component and another one for the base?
One find_package call instead of n calls. Easier
Re: [CMake] Linking archives in a sibling directory
Hi Michael,
On Thu, Dec 2, 2010 at 01:03, Michael Hertling mhertl...@online.de wrote:
On 12/01/2010 08:18 AM, Raymond Wan wrote:
Hi all,
I'm having a problem understanding how I can link to an archive in
another directory which is not a subdirectory. For example:
myproj
+-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
+-- CMakeLists.txt
+-- source files for sub-program A
+-- dir-B
+-- CmakeLists.txt
+-- source files for sub-program B
This error is caused by the fact that the directory dir-A is outside
the main directory tree, so dir-A's binary directory would likewise
be outside main's binary tree, and this is reasonably forbidden when
configuring main. You might specify dir-A's binary directory in
main/CMakeLists.txt explicitly, e.g.:
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
Hence, subprogA_ar will be built within the binary tree's dir-A.
Ah! I see now. I didn't realize I could prepend a path like that. I
was trying to find some kind of ADD_DIRECTORY command which had this
restriction removed. But then I realized if I'm looking for something
like that, there might be a bigger problem in terms of how I'm
organizing things...
myproj
+-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
+-- source files for sub-program A
+-- dir-B
+-- source files for sub-program B
Is this what I should have done??
As an alternative, consider to add a CMakeLists.txt in myproj
CMAKE_MINIMUM_REQUIRED(...)
PROJECT(myproj)
ADD_SUBDIRECTORY(dir-A)
ADD_SUBDIRECTORY(dir-B)
ADD_SUBDIRECTORY(main)
and subsequently, configure this directory instead of main.
Ah! I see. Then is it recommended that this top-level CMakeLists.txt
have just these lines, or should I move the ADD_EXECUTABLE, etc. lines
here as well? Or is this really up to me and there isn't a
suggested paradigm?
I guess I chose my first directory layout because the source in a
directory (i.e., dir-A) can be several dependencies down and it can
even be used by two targets in two different directories. So, I
figured that keeping them all at the same directory level would be
best. But it seems what you're suggesting here seems better -- never
thought of it; the myproj directory has no files in it...just
directories right now...
Thank you for your advice!
Ray
___
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] Makefile to CMakeLists.txt (GTEST)
Note that recent versions of gtest come with a CMakeLists.txt, so you
can just use add_subdirectory on the gtest source tree.
- Ben
On Wed, Dec 1, 2010 at 7:59 AM, Kevyn-Alexandre Paré
kap...@rogue-research.com wrote:
Philip,
Thx for the reply. Neither of these solutions change a thing.
I try to play with ADD_CUSTOM_TARGET but same error...
ADD_CUSTOM_TARGET(RRThread.o ALL COMMAND ${CMAKE_C_COMPILER} -I
${MICRONTRACKER_COMMON_PATH} -I${GTEST_HEADER_PATH} -lpthread -c
${MICRONTRACKER_COMMON_PATH}RRThread.c
${UNIT_TEST_PATH}common/UT_RRThread.cc)
ADD_CUSTOM_TARGET(UT_RRThread ALL COMMAND ${CMAKE_CXX_COMPILER} -I
${MICRONTRACKER_COMMON_PATH} -I${GTEST_HEADER_PATH} -lpthread RRThread.o
UT_RRThread.o ${GTEST_LIB_PATH}gtest.a ${GTEST_LIB_PATH}gtest_main.a -o
UT_RRThread)
Result:
UT_RRThread.o: In function `thread_proc(void*)':
UT_RRThread.cc:(.text+0x28): undefined reference to `exitThread()'
...
I pretty sure that I'm missing little detail. How can I implicitly add
dependency to the object during the linking?
Regards
--
Kevyn-Alexandre Paré
On Mon, 2010-11-29 at 18:17 -0500, Philip Lowman wrote:
Try adding the gtest.a library as well. Also, order does matter
when you are linking static libraries so you might need to play with
the ordering.
Also, when you get some time, have a look at FindGTest.cmake. It may
help you simplify adding your tests.
On Mon, Nov 29, 2010 at 5:55 PM, Kevyn-Alexandre Paré
kap...@rogue-research.com wrote:
Hi,
/// - What I trying to do is to compile my unit test with
google test
with cmake from a working Makefile.
/// - Here the Makefile
RRThread.o : $(USER_DIR)/RRThread.c $(USER_DIR)/RRThread.h
$(GTEST_HEADERS)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $(USER_DIR)/RRThread.c
UT_RRThread.o : $(UNITTEST_DIR)/UT_RRThread.cc \
$(USER_DIR)/RRThread.h $(GTEST_HEADERS)#
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -I$(USER_DIR) -c
$(UNITTEST_DIR)/UT_RRThread.cc
UT_RRThread : RRThread.o UT_RRThread.o gtest_main.a
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -lpthread $^ -o $@
/// - Here how I thought of doing it with CMakeLists.txt:::
INCLUDE_DIRECTORIES(${GTEST_HEADER} ${USER_DIR})
ADD_EXECUTABLE(UT ${USER_DIR}RRThread.c
${UNIT_TEST_PATH}UT_RRThread.cc)
TARGET_LINK_LIBRARIES(UT pthread
${GTEST_LIB_PATH}gtest_main.a)
/// - My result:
Linking CXX executable UT
/usr/bin/cmake -E cmake_link_script CMakeFiles/UT.dir/link.txt
--verbose=1
/usr/bin/c++ CMakeFiles/UT.dir/common/RRThread.c.o
CMakeFiles/UT.dir/UnitTests/common/UT_RRThread.cc.o -o UT
-rdynamic
-lpthread
/home/andromeda/rogue-research/3rdParty/gtest/trunk/Release/lib/gtest_main.a
CMakeFiles/UT.dir/UnitTests/common/UT_RRThread.cc.o: In
function
`thread_proc(void*)':
UT_RRThread.cc:(.text+0x28): undefined reference to
`exitThread()'
/// - My question and my problem is:
Since I'm including the USER_DIR with INCLUDE_DIRECTORIES why
is it
complaining about not finding reference that is in that header
file?
Best Regards,
--
Kevyn-Alexandre Paré
___
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
--
Philip Lowman
___
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
[CMake] Unified FindSDL module
Hi all, I needed to tweak the find sdl modules to use them to cross-compile for the Wii, so I decided to rewrite them in a unified module (used like: find_package (SDL REQUIRED ttf gfx image net)). I'm posting it here in case anyone finds it useful. It's not very polished, but I tried to keep all the cases of the original modules. It works for me at least under Linux and Windows. It uses some helper macros of a module from the cmake wiki which can be found here: http://zi.fi/cmake/Modules/LibFindMacros.cmake Hope it's useful FindSDL.cmake Description: Binary data ___ 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 PyQT/SIP
On 12/02/2010 12:37 AM, luxInteg wrote: On Tuesday 30 November 2010 22:43:34 luxInteg wrote: Greetings I an learnig cmake. My test project is as follows:- linux machine with pyQt4, sip-4.10.2,qt-4.6.2 and cmake-2.8.2 ---stepA: I have a file -fileA.sip. ---stepB: Upon execution of fileA.sip two files files -fileC.cpp and fileD.cppresult, ---stepC: fileC.cpp and fileD,cpp are compiled into a shared library. I am ok with stepC. I do not know how to carry out step B execution within cmake. advice would be appreciated. sincerely luxInteg Use ADD_CUSTOM_COMMAND. 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-commits] Using set_target_properties
Hi Gary,
Please bring questions to the main CMake list:
http://www.cmake.org/mailman/listinfo/cmake
with address cm...@cmake.org. This list is for automated commit
notifications only.
On 11/30/2010 01:00 PM, Gary%20G.%20Little%20%40%20comcast wrote:
I have a Visual Studio 2010 solution and I am trying to set the
Configuration Properties - General - Platform Toolset of one
particular project to use V90 to allow this project to build with the VS
2008 tool set. I followed an older thread and tried this:
set_target_properties(WindowsApplication${version} PROPERTIES
PlatformToolset V90)
That results in an error: set_target_properties Can not find target to
add properties to. ${version} is set to a version string and the term
WindowsApplication${version} is used later in the file by an
add_library and a target_link_library with no error.
http://www.cmake.org/Bug/view.php?id=10722
-Brad
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-719-gac19b42
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via ac19b42662ba8030e508bbcdd0d76dc23bcdc96d (commit)
via 13f24540ad540c5aedb599acb3deb09be9e6808d (commit)
via 8b555d1d208b8bbc2f4c3ddbcd33fb8e716de058 (commit)
from 1c5f9938acb4876fd182dc0fcece860f9793f907 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ac19b42662ba8030e508bbcdd0d76dc23bcdc96d
commit ac19b42662ba8030e508bbcdd0d76dc23bcdc96d
Merge: 1c5f993 13f2454
Author: Zach Mullen zach.mul...@kitware.com
AuthorDate: Wed Dec 1 11:29:34 2010 -0500
Commit: Zach Mullen zach.mul...@kitware.com
CommitDate: Wed Dec 1 11:29:34 2010 -0500
Merge branch 'ctest-remove-waiting-message' into next
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=13f24540ad540c5aedb599acb3deb09be9e6808d
commit 13f24540ad540c5aedb599acb3deb09be9e6808d
Author: Zach Mullen zach.mul...@kitware.com
AuthorDate: Wed Dec 1 11:28:23 2010 -0500
Commit: Zach Mullen zach.mul...@kitware.com
CommitDate: Wed Dec 1 11:28:23 2010 -0500
Remove debugging message from parallel ctest
diff --git a/Source/CTest/cmCTestMultiProcessHandler.cxx
b/Source/CTest/cmCTestMultiProcessHandler.cxx
index 0d14c2d..93c2963 100644
--- a/Source/CTest/cmCTestMultiProcessHandler.cxx
+++ b/Source/CTest/cmCTestMultiProcessHandler.cxx
@@ -275,12 +275,6 @@ void cmCTestMultiProcessHandler::StartNextTests()
}
numToStart -= processors;
}
-else
- {
- cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT, std::endl
- Test did not start waiting on depends to finish:
- *test \n);
- }
if(numToStart == 0)
{
return;
---
Summary of changes:
Source/CTest/cmCTestMultiProcessHandler.cxx |6 --
Source/kwsys/kwsysDateStamp.cmake |4 ++--
2 files changed, 2 insertions(+), 8 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-721-ga066d45
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via a066d4551019801f93ab1f078a440f57db3730c1 (commit)
via 08a31885c1eff9ed630d831ed38e231287c2c719 (commit)
from ac19b42662ba8030e508bbcdd0d76dc23bcdc96d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a066d4551019801f93ab1f078a440f57db3730c1
commit a066d4551019801f93ab1f078a440f57db3730c1
Merge: ac19b42 08a3188
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Dec 1 12:06:12 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 1 12:06:12 2010 -0500
Merge topic 'vs-target-dependencies' into next
08a3188 Skip VS = 7.1 dependency analysis for VS = 8
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08a31885c1eff9ed630d831ed38e231287c2c719
commit 08a31885c1eff9ed630d831ed38e231287c2c719
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Dec 1 11:43:30 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Dec 1 11:43:30 2010 -0500
Skip VS = 7.1 dependency analysis for VS = 8
Commit 1a0c166 (Store direct dependencies in solutions for VS = 8,
2010-08-20) disabled use of VS-specific global dependency analysis.
Avoid perfoming the analysis at all when it is not needed. This also
prevents creation of bogus and unused '_UTILITY' targets since they are
not needed for dependencies.
diff --git a/Source/cmGlobalVisualStudio8Generator.cxx
b/Source/cmGlobalVisualStudio8Generator.cxx
index 76d01e7..2d080df 100644
--- a/Source/cmGlobalVisualStudio8Generator.cxx
+++ b/Source/cmGlobalVisualStudio8Generator.cxx
@@ -289,6 +289,14 @@ cmGlobalVisualStudio8Generator
}
//
+bool cmGlobalVisualStudio8Generator::ComputeTargetDepends()
+{
+ // Skip over the cmGlobalVisualStudioGenerator implementation!
+ // We do not need the support that VS = 7.1 needs.
+ return this-cmGlobalGenerator::ComputeTargetDepends();
+}
+
+//
void cmGlobalVisualStudio8Generator::WriteProjectDepends(
std::ostream fout, const char*, const char*, cmTarget t)
{
diff --git a/Source/cmGlobalVisualStudio8Generator.h
b/Source/cmGlobalVisualStudio8Generator.h
index 95b6a17..e0913ed 100644
--- a/Source/cmGlobalVisualStudio8Generator.h
+++ b/Source/cmGlobalVisualStudio8Generator.h
@@ -78,6 +78,7 @@ protected:
virtual void WriteProjectConfigurations(std::ostream fout,
const char* name,
bool partOfDefaultBuild);
+ virtual bool ComputeTargetDepends();
virtual void WriteProjectDepends(std::ostream fout, const char* name,
const char* path, cmTarget t);
---
Summary of changes:
Source/cmGlobalVisualStudio8Generator.cxx |8
Source/cmGlobalVisualStudio8Generator.h |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-723-g0be0d8e
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 0be0d8e285fca08a9491195529931f2002133c8c (commit)
via fb97ba629348cdc93ac26ce7c8ed8804a7a9fae3 (commit)
from a066d4551019801f93ab1f078a440f57db3730c1 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0be0d8e285fca08a9491195529931f2002133c8c
commit 0be0d8e285fca08a9491195529931f2002133c8c
Merge: a066d45 fb97ba6
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Dec 1 13:44:37 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 1 13:44:37 2010 -0500
Merge topic 'vs10-express-64bit' into next
fb97ba6 Enable 64-bit tools with VS 2010 Express (#9981, #10722)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fb97ba629348cdc93ac26ce7c8ed8804a7a9fae3
commit fb97ba629348cdc93ac26ce7c8ed8804a7a9fae3
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Dec 1 12:48:32 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Dec 1 12:48:32 2010 -0500
Enable 64-bit tools with VS 2010 Express (#9981, #10722)
The Express Edition does not come with 64-bit tools, but one can install
the Microsoft Windows SDK v7.1 to get them. Detect this case and
check for the SDK. If found, set PlatformToolset to use the SDK tools.
Otherwise, fail with a concise and informative error.
diff --git a/Source/cmGlobalVisualStudio10Generator.cxx
b/Source/cmGlobalVisualStudio10Generator.cxx
index 403507f..0b939af 100644
--- a/Source/cmGlobalVisualStudio10Generator.cxx
+++ b/Source/cmGlobalVisualStudio10Generator.cxx
@@ -19,6 +19,10 @@
cmGlobalVisualStudio10Generator::cmGlobalVisualStudio10Generator()
{
this-FindMakeProgramFile = CMakeVS10FindMake.cmake;
+ std::string vc10Express;
+ this-ExpressEdition = cmSystemTools::ReadRegistryValue(
+HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VCExpress\\10.0\\Setup\\VC;
+ProductDir, vc10Express, cmSystemTools::KeyWOW64_32);
}
//
@@ -63,6 +67,16 @@ void cmGlobalVisualStudio10Generator
}
//
+const char* cmGlobalVisualStudio10Generator::GetPlatformToolset()
+{
+ if(!this-PlatformToolset.empty())
+{
+return this-PlatformToolset.c_str();
+}
+ return 0;
+}
+
+//
std::string cmGlobalVisualStudio10Generator::GetUserMacrosDirectory()
{
std::string base;
diff --git a/Source/cmGlobalVisualStudio10Generator.h
b/Source/cmGlobalVisualStudio10Generator.h
index 219c36e..bef5642 100644
--- a/Source/cmGlobalVisualStudio10Generator.h
+++ b/Source/cmGlobalVisualStudio10Generator.h
@@ -54,6 +54,12 @@ public:
cmMakefile *, bool optional);
virtual void WriteSLNHeader(std::ostream fout);
+ /** Is the installed VS an Express edition? */
+ bool IsExpressEdition() const { return this-ExpressEdition; }
+
+ /** The toolset name for the target platform. */
+ const char* GetPlatformToolset();
+
/**
* Where does this version of Visual Studio look for macros for the
* current user? Returns the empty string if this version of Visual
@@ -70,5 +76,9 @@ public:
{ return $(Configuration);}
protected:
virtual const char* GetIDEVersion() { return 10.0; }
+
+ std::string PlatformToolset;
+private:
+ bool ExpressEdition;
};
#endif
diff --git a/Source/cmGlobalVisualStudio10Win64Generator.cxx
b/Source/cmGlobalVisualStudio10Win64Generator.cxx
index 109b60d..8600777 100644
--- a/Source/cmGlobalVisualStudio10Win64Generator.cxx
+++ b/Source/cmGlobalVisualStudio10Win64Generator.cxx
@@ -36,3 +36,52 @@ void cmGlobalVisualStudio10Win64Generator
mf-AddDefinition(MSVC_C_ARCHITECTURE_ID, x64);
mf-AddDefinition(MSVC_CXX_ARCHITECTURE_ID, x64);
}
+
+//
+bool cmGlobalVisualStudio10Win64Generator::Find64BitTools(cmMakefile* mf)
+{
+ if(!this-PlatformToolset.empty())
+{
+return true;
+}
+ // This edition does not come with 64-bit tools. Look for them.
+ //
+ // TODO: Detect available tools? x64\v100 exists but does not work?
+ // KHLM\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\4.0;VCTargetsPath
+ // c:/Program Files (x86)/MSBuild/Microsoft.Cpp/v4.0/Platforms/
+ // {Itanium,Win32,x64}/PlatformToolsets/{v100,v90,Windows7.1SDK}
+ std::string winSDK_7_1;
+ if(cmSystemTools::ReadRegistryValue(
+ HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\
+
[Cmake-commits] CMake branch, next, updated. v2.8.3-725-g4f3ede9
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 4f3ede998ddb93d8e14ffcc2ff4547d984f84cf9 (commit)
via 12a7125b323fe2d996fd536f2808a94f6e02e438 (commit)
from 0be0d8e285fca08a9491195529931f2002133c8c (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f3ede998ddb93d8e14ffcc2ff4547d984f84cf9
commit 4f3ede998ddb93d8e14ffcc2ff4547d984f84cf9
Merge: 0be0d8e 12a7125
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Wed Dec 1 15:03:50 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 1 15:03:50 2010 -0500
Merge topic 'CPack-Bug11452-ComponentBreakage-v2' into next
12a7125 CPack Fix KWStyle error
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=12a7125b323fe2d996fd536f2808a94f6e02e438
commit 12a7125b323fe2d996fd536f2808a94f6e02e438
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Wed Dec 1 21:00:38 2010 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Wed Dec 1 21:00:38 2010 +0100
CPack Fix KWStyle error
diff --git a/Source/CPack/cmCPackArchiveGenerator.cxx
b/Source/CPack/cmCPackArchiveGenerator.cxx
index 8bbf699..ded329d 100644
--- a/Source/CPack/cmCPackArchiveGenerator.cxx
+++ b/Source/CPack/cmCPackArchiveGenerator.cxx
@@ -232,7 +232,9 @@ int cmCPackArchiveGenerator::PackageFiles()
// CASE 1 : COMPONENT ALL-IN-ONE package
// If ALL GROUPS or ALL COMPONENTS in ONE package has been requested
// then the package file is unique and should be open here.
-if (allComponentInOne || (allGroupInOne
(!this-ComponentGroups.empty(
+if (allComponentInOne ||
+(allGroupInOne (!this-ComponentGroups.empty()))
+ )
{
return PackageComponentsAllInOne(allComponentInOne);
}
---
Summary of changes:
Source/CPack/cmCPackArchiveGenerator.cxx |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-727-g689c57e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 689c57e1999f8dbd880cb307e2659f20cc0c6433 (commit) via f9abda2db4acb1cc00844dbf4f63392d8c208a0a (commit) from 4f3ede998ddb93d8e14ffcc2ff4547d984f84cf9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=689c57e1999f8dbd880cb307e2659f20cc0c6433 commit 689c57e1999f8dbd880cb307e2659f20cc0c6433 Merge: 4f3ede9 f9abda2 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Dec 1 16:42:32 2010 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Dec 1 16:42:32 2010 -0500 Merge branch 'master' into next --- Summary of changes: Source/kwsys/CMakeLists.txt |5 + 1 files changed, 5 insertions(+), 0 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.3-140-g746d54a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 746d54a8430075a634d1086f484bfe72d13293be (commit) from f9abda2db4acb1cc00844dbf4f63392d8c208a0a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=746d54a8430075a634d1086f484bfe72d13293be commit 746d54a8430075a634d1086f484bfe72d13293be Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Dec 2 00:01:05 2010 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Dec 2 00:10:03 2010 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 92e85f2..fe40799 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2010) SET(KWSYS_DATE_STAMP_MONTH 12) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 01) +SET(KWSYS_DATE_STAMP_DAY 02) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
