[CMake] BundleUtilities Error on Install
Running on Windows 7 x64 with CMake 2.8.3 and Visual Studio 2008. My project is
configured with the Win64 type. I am trying to consolidate my installation code
to use the BundleUtilities on all platforms where possible. I can not figure
out what is going wrong with the install project. Here is a transcript of the
build:
#
5>Performing Post-Build Event...
5>-- Install configuration: "Debug"
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/lib/MXADataModel_debug.lib
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/./MXADataModel_debug.dll
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/lib/AIMCommon_debug.lib
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/./AIMCommon_debug.dll
5>-- Up-to-date:
C:/Developer/x64/AIMRepresentation/./Microsoft.VC90.CRT.manifest
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/./msvcm90.dll
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/./msvcp90.dll
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/./msvcr90.dll
5>-- Up-to-date:
C:/Developer/x64/AIMRepresentation/./Microsoft.VC90.DebugCRT.manifest
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/./msvcm90d.dll
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/./msvcp90d.dll
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/./msvcr90d.dll
5>-- Up-to-date: C:/Developer/x64/AIMRepresentation/./Representation_debug.exe
5>-- fixup_bundle
5>-- app='C:/Developer/x64/AIMRepresentation/./Representation_debug.exe'
5>-- libs=''
5>--
dirs='C:/Developer/x64/Qt-4.7.1/bin;C:/Developer/x64/Qt-4.7.1/lib;C:/Developer/x64/hdf5-169/bin;C:/Developer/x64/hdf5-169/lib;C:/Users/mjackson/Workspace/AIMRepresentation/x64/Bin;C:/Users/mjackson/Workspace/AIMRepresentation/x64/Bin/Debug;C:/Users/mjackson/Workspace/AIMRepresentation/x64/Bin/Release'
5>-- fixup_bundle: preparing...
5>-- fixup_bundle: copying...
5>-- 1/12: *NOT* copying
'C:/Developer/x64/AIMRepresentation/./Representation_debug.exe'
5>-- 2/12: copying 'C:/Developer/x64/AIMRepresentation/AIMCommon_debug.dll'
5>-- warning: resolved_item == resolved_embedded_item - not copying...
5>-- 3/12: copying 'C:/Developer/x64/AIMRepresentation/MXADataModel_debug.dll'
5>-- warning: resolved_item == resolved_embedded_item - not copying...
5>-- 4/12: copying 'C:/Developer/x64/AIMRepresentation/QtCored4.dll'
5>-- warning: resolved_item == resolved_embedded_item - not copying...
5>-- 5/12: copying 'C:/Developer/x64/AIMRepresentation/QtGuid4.dll'
5>-- warning: resolved_item == resolved_embedded_item - not copying...
5>-- 6/12: copying 'C:/Developer/x64/AIMRepresentation/hdf5dll_D.dll'
5>-- warning: resolved_item == resolved_embedded_item - not copying...
5>-- fixup_bundle: fixing...
5>-- 7/12: fix-up not required on this platform
'C:/Developer/x64/AIMRepresentation/./Representation_debug.exe'
5>-- 8/12: fix-up not required on this platform
'C:/Developer/x64/AIMRepresentation/AIMCommon_debug.dll'
5>-- 9/12: fix-up not required on this platform
'C:/Developer/x64/AIMRepresentation/MXADataModel_debug.dll'
5>-- 10/12: fix-up not required on this platform
'C:/Developer/x64/AIMRepresentation/QtCored4.dll'
5>-- 11/12: fix-up not required on this platform
'C:/Developer/x64/AIMRepresentation/QtGuid4.dll'
5>-- 12/12: fix-up not required on this platform
'C:/Developer/x64/AIMRepresentation/hdf5dll_D.dll'
5>-- fixup_bundle: cleaning up...
5>-- fixup_bundle: verifying...
5>-- ===
5>-- Analyzing
app='C:/Developer/x64/AIMRepresentation/./Representation_debug.exe'
5>-- bundle='C:/Developer/x64/AIMRepresentation/.'
5>-- executable='C:/Developer/x64/AIMRepresentation/./Representation_debug.exe'
5>-- valid='1'
5>-- executable file 1:
C:/Developer/x64/AIMRepresentation/./Representation_debug.exe
5>-- verified='0'
5>-- info='external prerequisites found:
5>f='C:/Developer/x64/AIMRepresentation/./Representation_debug.exe'
5>external_prereqs='AIMCommon_debug.dll;MXADataModel_debug.dll;QtCored4.dll;QtGuid4.dll;hdf5dll_D.dll'
5>'
5>--
5>CMake Error at
C:/Applications/CMake-2.8.3/share/cmake-2.8/Modules/BundleUtilities.cmake:743
(message):
5> error: verify_app failed
5>Call Stack (most recent call first):
5>
C:/Applications/CMake-2.8.3/share/cmake-2.8/Modules/BundleUtilities.cmake:625
(verify_app)
5> AIM/GUI/cmake_install.cmake:61 (fixup_bundle)
5> cmake_install.cmake:34 (INCLUDE)
5>Project : error PRJ0019: A tool returned an error code from "Performing
Post-Build Event..."
5>Build log was saved at
"file://c:\Users\mjackson\Workspace\AIMRepresentation\x64\INSTALL.dir\Debug\BuildLog.htm"
5>INSTALL - 1 error(s), 0 warning(s)
== Build: 4 succeeded, 1 failed, 5 up-to-date, 0 skipped ==
And here is the CMake code that I use to generate the cmake files:
# -- Build the Viewer Application --
ADD_EXECUTABLE( ${PROJECT_NAME} ${GUI_TYPE} ${Representation_PROJECT_SRCS} )
TARGET_LINK_LIBRARIES( ${PROJECT_NAME}
[CMake] control order of custom target as a sub-part of a customized KDE build
I am building a KDE control panel plugin, and there is a requirement
to use a different translation mechanism rather than the default Qt
"tr" macros. So I want to post-process my ui_*.h files to replace
lines like this
ClearSiteDataDialog->setWindowTitle(tr2i18n("foo", 0));
with the replacement code like this
ClearSiteDataDialog->setWindowTitle(Translator::instance().lookupString(CSD_DIALOG_TITLE));
I wrote a python script to do that, and I'm calling it like this from
cmakelists.txt:
cmake_minimum_required (VERSION 2.6.0)
set (CMAKE_VERBOSE_MAKEFILE true)
find_package(KDE4 REQUIRED)
file(GLOB SRC_FILES *.cpp)
set(kcm_my_plugin_PART_SRCS ${SRC_FILES})
message(STATUS "build type ${CMAKE_BUILD_TYPE}")
file(GLOB UI_FILES *.ui)
message(STATUS "ui files ${UI_FILES}")
kde4_add_ui_files(kcm_my_plugin_PART_SRCS ${UI_FILES})
kde4_add_plugin(kcm_my_plugin ${kcm_my_plugin_PART_SRCS}
${LINUX_COMMON_SOURCE} ${COMMON_SOURCE} ${COMMON_SOURCE_IMPL})
target_link_libraries(kcm_my_plugin ${KDE4_KDEUI_LIBS}
${KDE4_KCMUTILS_LIBS} ${X11_LIBRARIES} kutils)
# post-process the ui_*.h header files AFTER they have been generated
but BEFORE compiling anything
add_custom_target(ui_translate
COMMAND ${CMAKE_SOURCE_DIR}/tools/convert-tr2-all.py
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
ADD_DEPENDENCIES(kcm_my_plugin ui_translate)
ADD_DEPENDENCIES(kcm_my_plugin_automoc ui_translate)
The only trouble is, it tries to call the script at the beginning of
the build process, so the first time I run "make" it fails, and the
second time after the ui_*.h files have been generated it succeeds.
So, I need to control the order somehow, and I haven't dug deep enough
into the KDE4 package to understand how the existing steps are done in
the right order. I need to append my extra step after the point where
it generates the ui header files from the UI files. I'm looking for
ideas on what the dependency should be - which target do I depend on
to get it done at the right time?
___
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] Chasing up: XCode 3.2.4 and CMake 2.8.2, setting GCC version to 4.0
On Tue, Jan 4, 2011 at 9:59 AM, John Clayton wrote: > I have a solution for the problem of creating XCode 3.2.x project on a 10.6 > machine that are to target the 10.4u SDK. > > Here's what I did (thanks to the OGRE and Open Scene Graph projects - which > exposed me to this solution). > > WARNING: my solution assumes a 32 bit build, so here goes: > > Here's how: put this right at the top of the CMakeLists.txt - in my case, > the very top level one. > > if (APPLE) > # Force gcc <= 4.0 on Mac OS X because 4.2 is not supported prior to Mac > OS X 10.5 > include(CMakeForceCompiler) > CMAKE_FORCE_C_COMPILER(gcc-4.0 GNU) > CMAKE_FORCE_CXX_COMPILER(g++-4.0 GNU) > SET(CMAKE_SIZEOF_VOID_P 4) > endif () > > set(CMAKE_XCODE_ATTRIBUTE_GCC_VERSION "4.0") > > > so, what's it do?? > > the FORCE_C_COMPILER stuff is going to ensure that the 4.0 series GCC > compiler is picked up, which is really useful when the compiler-test phases > of cmake get run. What isn't obvious though is that when this is done, some > tests the ptr size are NOT carried out any longer, which impacted our > project - so here's the caveat: I'm forcing the CMAKE_SIZEOF_VOID_P to 4, > which means the rest of our codebase goes with a 32 bit build. For me, not > a problem - for you - good luck :-) > > The CMAKE_XCODE_ATTRIBUTE_GCC_VERSION is *also* required. This forces the > GCC_VERSION attribute within the xcode configuration to be 4.0 instead of > 4.2 (assuming build platform of 10.6). > > Take note; if you leave the CMAKE_XCODE_ATTRIBUTE_GCC_VERSION out - then > the Xcode GCC version will *still be 4.2* - so you need both of these > settings in the CMakeLists.txt file. > > If anyone can improve on this - I'd appreciate it, thanks for all your help > and good luck with those 10.4u builds from a 10.6.x machine! > > > > > John Clayton > > --- > FileWave (Europe) GmbH > St. Gallerstrasse 1 > CH - 9500 Wil > > Phone: +41 71 914 30 80 > Fax: +41 71 914 30 81 > Web: www.filewave.com > Skype: johncclayton > > > > > On 03.01.2011, at 14:36, John Clayton wrote: > > Hi All, > > i'm still having problems getting the CMAKE_XCODE_ATTRIBUTE_GCC_VERSION > flag to properly force the compiler version I want to use for my project. > > I'm using XCode 3.2.5, on a Mac 10.6.3 machine - trying to target a Max OS > X Tiger 10.4u build. I get compiler errors because the gcc-4.2 compiler is > being used in the compiler-test stage of CMake. > > I thought CMAKE_XCODE_ATTRIBUTE_GCC_VERSION could be used to force the > compiler setting to 4.0? > > My top level CMakeLists.txt file has this as its first few lines - is this > the correct way to use this option? > > PROJECT( FileWave ) > cmake_minimum_required(VERSION 2.6) > set(CMAKE_XCODE_ATTRIBUTE_GCC_VERSION "4.0") > > The error I get after running an XCode based generator is: > -- The C compiler identification is GNU > -- The CXX compiler identification is GNU > -- Checking whether C compiler has -isysroot > -- Checking whether C compiler has -isysroot - yes > -- Checking whether C compiler supports OSX deployment target flag > -- Checking whether C compiler supports OSX deployment target flag - yes > -- Check for working C compiler using: Xcode > -- Check for working C compiler using: Xcode -- broken > CMake Error at /Users/john/CMake/Modules/CMakeTestCCompiler.cmake:52 > (MESSAGE): > The C compiler "/usr/bin/gcc-4.0" is not able to compile a simple test > program. > > It fails with the following output: > >Change Dir: /Users/john/src/TRUNK/BuildSystem/Xcode/CMakeFiles/CMakeTmp > > > > Run Build Command:/Users/john/CMake/bin/cmakexbuild -project > CMAKE_TRY_COMPILE.xcodeproj build -target cmTryCompileExec -configuration > Debug > > > > === BUILD NATIVE TARGET cmTryCompileExec OF PROJECT CMAKE_TRY_COMPILE > WITH > CONFIGURATION Debug === > > Check dependencies > > GCC 4.2 is not compatible with the Mac OS X 10.4 SDK (file > testCCompiler.c) > > GCC 4.2 is not compatible with the Mac OS X 10.4 SDK (file > testCCompiler.c) > > ** BUILD FAILED ** > > > > > > > > > John Clayton > > --- > FileWave (Europe) GmbH > St. Gallerstrasse 1 > CH - 9500 Wil > > Phone: +41 71 914 30 80 > Fax: +41 71 914 30 81 > Web: www.filewave.com > Skype: johncclayton > > > > > > > ___ > 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 > The underlying problem here is that my bug fix for http://public.kitware.com/Bug/view.php?id=9125 was insufficient. Woefully so for people who rely on try_compile results in their projects. The real fix would also involve propagating the CMAKE_XCODE_ATTRIBUTE_GCC_VERSION setting to generated projects for try_compile oper
Re: [CMake] how to submit customized test report
On Mon, Jan 03, 2011 at 05:48:13AM -0800, girish hilage wrote:
> So, now I have to edit Test.xml generated by 'ctest' under directory :
> /home/girish/project/trunk/Testing/20110103-1027/
>
> What I would like to know is, if there is any 'CTEST_' variable which
> would give me path of the Test.xml file that is generated by 'ctest'?
> Or is there any variable which will give me 'Experimental tag' which is
> shown in the output (Use Experimental tag: 20110103-1027) if we give -VV
> option to ctest, so that I can construct path to Test.xml?
> Or can we ask 'ctest' to generate Test.xml at some pre-specified path?
Not 100% certain of your problem, but I think you're looking for
something like this:
# Start a new submission.
ctest_start (${TP_DASHBOARD_MODEL})
# Calculate TP_CTEST_XML_DIR (which changes whenver ctest_start() is
# called).
file (READ "${CTEST_BINARY_DIRECTORY}/Testing/TAG" tag_file)
string (REGEX MATCH "[^\n]*" xml_dir ${tag_file})
set (TP_CTEST_XML_DIR "${CTEST_BINARY_DIRECTORY}/Testing/${xml_dir}")
The idea for this comes from Clinton Stimpson. See also:
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.user/27268
hth,
tyler
___
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] Chasing up: XCode 3.2.4 and CMake 2.8.2, setting GCC version to 4.0
Hi John
You shouldn't rely on CMAKE_SIZEOF_VOID_P anyway; it's deadly when you
try to build a universal binary. Much better to use the CheckTypeSize
module with which you can do the following:
include(CheckTypeSize)
check_type_size("void*" SIZEOF_VOID_P)
if(SIZEOF_VOID_P STREQUAL "")
message(SEND_ERROR "Failed to determine sizeof(void*)")
endif()
configure_file(config.h.in {CMAKE_BINARY_DIR}/config.h @ONLY)
where config.h.in might look like this:
#ifndef CONFIG_H
#define CONFIG_H
/* defines SIZEOF_VOID_P to sizeof(void*) depending
on the architecture */
@SIZEOF_VOID_P_CODE@
#endif
Then include config.h in all the sources where you need to know the size
of void*. Try NOT to include it in other headers, at least not in
headers that get installed as part of a development package. If you
must, give it a more unique name and make the names of the defines
unique such that they don't conflict with other config.h from other
packages.
This should work across all platforms supported by CMake and also work
if CMAKE_OSX_ARCHITECTURES is set to e.g. "i386;x86_64".
HTH
Michael
On 01/04/2011 03:59 PM, John Clayton wrote:
> I have a solution for the problem of creating XCode 3.2.x project on a 10.6
> machine that are to target the 10.4u SDK.
>
> Here's what I did (thanks to the OGRE and Open Scene Graph projects - which
> exposed me to this solution).
>
> WARNING: my solution assumes a 32 bit build, so here goes:
>
> Here's how: put this right at the top of the CMakeLists.txt - in my case, the
> very top level one.
>
> if (APPLE)
> # Force gcc <= 4.0 on Mac OS X because 4.2 is not supported prior to Mac OS X
> 10.5
> include(CMakeForceCompiler)
> CMAKE_FORCE_C_COMPILER(gcc-4.0 GNU)
> CMAKE_FORCE_CXX_COMPILER(g++-4.0 GNU)
> SET(CMAKE_SIZEOF_VOID_P 4)
> endif ()
>
> set(CMAKE_XCODE_ATTRIBUTE_GCC_VERSION "4.0")
>
>
> so, what's it do??
>
> the FORCE_C_COMPILER stuff is going to ensure that the 4.0 series GCC
> compiler
> is picked up, which is really useful when the compiler-test phases of cmake
> get
> run. What isn't obvious though is that when this is done, some tests the ptr
> size are NOT carried out any longer, which impacted our project - so here's
> the
> caveat: I'm forcing the CMAKE_SIZEOF_VOID_P to 4, which means the rest of our
> codebase goes with a 32 bit build. For me, not a problem - for you - good
> luck :-)
>
> The CMAKE_XCODE_ATTRIBUTE_GCC_VERSION is *also* required. This forces the
> GCC_VERSION attribute within the xcode configuration to be 4.0 instead of 4.2
> (assuming build platform of 10.6).
>
> Take note; if you leave the CMAKE_XCODE_ATTRIBUTE_GCC_VERSION out - then the
> Xcode GCC version will *still be 4.2* - so you need both of these settings in
> the CMakeLists.txt file.
>
> If anyone can improve on this - I'd appreciate it, thanks for all your help
> and
> good luck with those 10.4u builds from a 10.6.x machine!
>
>
>
>
> John Clayton
>
> On 03.01.2011, at 14:36, John Clayton wrote:
>
>> Hi All,
>>
>> i'm still having problems getting the CMAKE_XCODE_ATTRIBUTE_GCC_VERSION flag
>> to properly force the compiler version I want to use for my project.
>>
>> I'm using XCode 3.2.5, on a Mac 10.6.3 machine - trying to target a Max OS X
>> Tiger 10.4u build. I get compiler errors because the gcc-4.2 compiler is
>> being
>> used in the compiler-test stage of CMake.
>>
>> I thought CMAKE_XCODE_ATTRIBUTE_GCC_VERSION could be used to force the
>> compiler setting to 4.0?
>>
>> My top level CMakeLists.txt file has this as its first few lines - is this
>> the
>> correct way to use this option?
>>
>> PROJECT( FileWave )
>> cmake_minimum_required(VERSION 2.6)
>> set(CMAKE_XCODE_ATTRIBUTE_GCC_VERSION "4.0")
>>
>> The error I get after running an XCode based generator is:
>> -- The C compiler identification is GNU
>> -- The CXX compiler identification is GNU
>> -- Checking whether C compiler has -isysroot
>> -- Checking whether C compiler has -isysroot - yes
>> -- Checking whether C compiler supports OSX deployment target flag
>> -- Checking whether C compiler supports OSX deployment target flag - yes
>> -- Check for working C compiler using: Xcode
>> -- Check for working C compiler using: Xcode -- broken
>> CMake Error at /Users/john/CMake/Modules/CMakeTestCCompiler.cmake:52
>> (MESSAGE):
>> The C compiler "/usr/bin/gcc-4.0" is not able to compile a simple test
>> program.
>>
>> It fails with the following output:
>>
>> Change Dir: /Users/john/src/TRUNK/BuildSystem/Xcode/CMakeFiles/CMakeTmp
>>
>>
>> Run Build Command:/Users/john/CMake/bin/cmakexbuild -project
>> CMAKE_TRY_COMPILE.xcodeproj build -target cmTryCompileExec -configuration
>> Debug
>>
>>
>> === BUILD NATIVE TARGET cmTryCompileExec OF PROJECT CMAKE_TRY_COMPILE WITH
>> CONFIGURATION Debug ===
>>
>> Check dependencies
>>
>> GCC 4.2 is not compatible with the Mac OS X 10.4 SDK (file testCCompiler.c)
>>
>> GCC 4.2 is not compatible with the Mac OS X 10.4 SDK (file testCCompiler.c)
>>
>> ** BUILD
Re: [CMake] Chasing up: XCode 3.2.4 and CMake 2.8.2, setting GCC version to 4.0
I have a solution for the problem of creating XCode 3.2.x project on a 10.6 machine that are to target the 10.4u SDK.Here's what I did (thanks to the OGRE and Open Scene Graph projects - which exposed me to this solution). WARNING: my solution assumes a 32 bit build, so here goes:Here's how: put this right at the top of the CMakeLists.txt - in my case, the very top level one. if (APPLE) # Force gcc <= 4.0 on Mac OS X because 4.2 is not supported prior to Mac OS X 10.5 include(CMakeForceCompiler) CMAKE_FORCE_C_COMPILER(gcc-4.0 GNU) CMAKE_FORCE_CXX_COMPILER(g++-4.0 GNU) SET(CMAKE_SIZEOF_VOID_P 4)endif ()set(CMAKE_XCODE_ATTRIBUTE_GCC_VERSION "4.0")so, what's it do??the FORCE_C_COMPILER stuff is going to ensure that the 4.0 series GCC compiler is picked up, which is really useful when the compiler-test phases of cmake get run. What isn't obvious though is that when this is done, some tests the ptr size are NOT carried out any longer, which impacted our project - so here's the caveat: I'm forcing the CMAKE_SIZEOF_VOID_P to 4, which means the rest of our codebase goes with a 32 bit build. For me, not a problem - for you - good luck :-)The CMAKE_XCODE_ATTRIBUTE_GCC_VERSION is *also* required. This forces the GCC_VERSION attribute within the xcode configuration to be 4.0 instead of 4.2 (assuming build platform of 10.6). Take note; if you leave the CMAKE_XCODE_ATTRIBUTE_GCC_VERSION out - then the Xcode GCC version will *still be 4.2* - so you need both of these settings in the CMakeLists.txt file.If anyone can improve on this - I'd appreciate it, thanks for all your help and good luck with those 10.4u builds from a 10.6.x machine! John Clayton---FileWave (Europe) GmbHSt. Gallerstrasse 1CH - 9500 Wil Phone: +41 71 914 30 80Fax: +41 71 914 30 81Web: www.filewave.comSkype: johncclayton On 03.01.2011, at 14:36, John Clayton wrote:Hi All,i'm still having problems getting the CMAKE_XCODE_ATTRIBUTE_GCC_VERSION flag to properly force the compiler version I want to use for my project. I'm using XCode 3.2.5, on a Mac 10.6.3 machine - trying to target a Max OS X Tiger 10.4u build. I get compiler errors because the gcc-4.2 compiler is being used in the compiler-test stage of CMake. I thought CMAKE_XCODE_ATTRIBUTE_GCC_VERSION could be used to force the compiler setting to 4.0?My top level CMakeLists.txt file has this as its first few lines - is this the correct way to use this option? PROJECT( FileWave ) cmake_minimum_required(VERSION 2.6) set(CMAKE_XCODE_ATTRIBUTE_GCC_VERSION "4.0")The error I get after running an XCode based generator is: -- The C compiler identification is GNU-- The CXX compiler identification is GNU-- Checking whether C compiler has -isysroot-- Checking whether C compiler has -isysroot - yes-- Checking whether C compiler supports OSX deployment target flag-- Checking whether C compiler supports OSX deployment target flag - yes-- Check for working C compiler using: Xcode-- Check for working C compiler using: Xcode -- brokenCMake Error at /Users/john/CMake/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler "/usr/bin/gcc-4.0" is not able to compile a simple test program. It fails with the following output: Change Dir: /Users/john/src/TRUNK/BuildSystem/Xcode/CMakeFiles/CMakeTmpRun Build Command:/Users/john/CMake/bin/cmakexbuild -project CMAKE_TRY_COMPILE.xcodeproj build -target cmTryCompileExec -configuration Debug=== BUILD NATIVE TARGET cmTryCompileExec OF PROJECT CMAKE_TRY_COMPILE WITH CONFIGURATION Debug === Check dependencies GCC 4.2 is not compatible with the Mac OS X 10.4 SDK (file testCCompiler.c) GCC 4.2 is not compatible with the Mac OS X 10.4 SDK (file testCCompiler.c) ** BUILD FAILED ** John Clayton---FileWave (Europe) GmbHSt. Gallerstrasse 1CH - 9500 Wil Phone: +41 71 914 30 80Fax: +41 71 914 30 81Web: www.filewave.comSkype: johncclayton ___ 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] Filenames becomes too big on windows (VS10)
On 01/04/2011 07:44 AM, Martin Nielsen wrote: > Would it be possible to direct CMake to use absolute filenames in the > project files instead of the relative path? Put the build directory somewhere that is not inside the source directory. -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] Filenames becomes too big on windows (VS10)
Hi All I'm curently facing an issue with filenames becoming too big with the Visual Studio 10 generator. Doing the compilation of our source code I get the following errors: "C:\bs-vs2010\synergy-main-winnt-x86-vs10\build\install\no_log\output\no _log\Synergy.sln" (default target) (1) -> "C:\bs-vs2010\synergy-main-winnt-x86-vs10\build\install\no_log\output\no _log\.\ALL_BUILD.vcxproj.metaproj" (default target) (2) -> "C:\bs-vs2010\synergy-main-winnt-x86-vs10\build\install\no_log\output\no _log\bt\profile_managers\core_stack\common\bluestack\dmlib\csr_bt_corest ack_bluestack_dmlib.vcxproj.metaproj" (default target) (172) -> "C:\bs-vs2010\synergy-main-winnt-x86-vs10\build\install\no_log\output\no _log\bt\profile_managers\core_stack\common\bluestack\dmlib\csr_bt_corest ack_bluestack_dmlib.vcxproj" (default target) (173) -> (ClCompile target) -> c1 : fatal error C1083: Cannot open source file: '..\..\..\..\..\..\..\..\bt\profile_managers\core_stack\common\bluestack \dmlib\dmlib_hci_read_inquiry_response_tx_power_level_req.c': No such file or directory [C:\bs-vs2010\synergy-main-winnt-x86-vs10\build\install\no_log\output\no _log\bt\profile_managers\core_stack\common\bluestack\dmlib\csr_bt_corest ack_bluestack_dmlib.vcxproj] c1 : fatal error C1083: Cannot open source file: '..\..\..\..\..\..\..\..\bt\profile_managers\core_stack\common\bluestack \dmlib\dmlib_hci_ulp_read_advertising_channel_tx_power_req.c': No such file or directory [C:\bs-vs2010\synergy-main-winnt-x86-vs10\build\install\no_log\output\no _log\bt\profile_managers\core_stack\common\bluestack\dmlib\csr_bt_corest ack_bluestack_dmlib.vcxproj] c1 : fatal error C1083: Cannot open source file: '..\..\..\..\..\..\..\..\bt\profile_managers\core_stack\common\bluestack \dmlib\dmlib_sm_generate_nonresolvable_private_address_req.c': No such file or directory [C:\bs-vs2010\synergy-main-winnt-x86-vs10\build\install\no_log\output\no _log\bt\profile_managers\core_stack\common\bluestack\dmlib\csr_bt_corest ack_bluestack_dmlib.vcxproj] I figured that the tool combines the path of the project with the relative path of the filename located in the project file resulting in this filename: C:\bs-vs2010\synergy-main-winnt-x86-vs10\build\install\no_log\output\no_ log\bt\profile_managers\core_stack\common\bluestack\dmlib\..\..\..\..\.. \..\..\..\bt\profile_managers\core_stack\common\bluestack\dmlib\dmlib_hc i_ulp_read_advertising_channel_tx_power_req.c I assume the failure is due to the 260 bytes filename length limitation within Windows. Would it be possible to direct CMake to use absolute filenames in the project files instead of the relative path? Or could this be caused by something else? Med venlig hilsen / Best Regards Martin Nielsen Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom ___ 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] VS2010 solution/project reload
On Tue, Jan 4, 2011 at 7:51 AM, Rolf Eike Beer wrote:
>> On Tue, Jan 4, 2011 at 6:58 AM, Andrea Galeazzi wrote:
>>> I'm currently dealing with a project requiring a lot of dependencies
>>> (74),
>>> so the structure of the CMakeLists.txt is as following:
>>> project ( Main )
>>> add_subdirectory("W:/Lib1" "${CMAKE_CURRENT_BINARY_DIR}/Lib1")
>>> add_subdirectory("W:/Lib2" "${CMAKE_CURRENT_BINARY_DIR}/Lib2")
>>> add_subdirectory("W:/Lib3" "${CMAKE_CURRENT_BINARY_DIR}/Lib3")
>>>
>>> add_executable( Main ${SOURCES} )
>>> target_link_libraries(Main ${LIB_TO_LINK})
>>>
>>> When I choose a VS2010 CMake generates a solution of 77 projects (74
>>> +Main
>>> + ALL_BUILD + ZERO_CHECK).
>>> Now if I modify the CMakeLists.txt of one of the subproject and build
>>> the
>>> Main project VS2010 notify that many other project has been modified and
>>> also the solution. So, for instance, if I add a file to a subproject
>>> VS2010
>>> shows a lot of dialog asking to reload the projects again and that's
>>> very
>>> frustrating!
>>> My question is: is it a bug or a normal behavior? If the second, how can
>>> I
>>> avoid it?
>
>> It's listed as a bug in the CMake bug tracker:
>> http://public.kitware.com/Bug/view.php?id=11258
>
> [...]
>
>> For now the best workaround (that I personally use all the time), is
>> to exit Visual Studio entirely, run cmake or cmake-gui manually, and
>> then re-launch Visual Studio. It may sound painful, but really, it's
>> much more enjoyable than wading through all the reload dialogs...
>
> Isn't it enough to unload the solution? That would save at least the time
> starting Visual Studio.
>
> Eike
> ___
> 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
>
Yes, simply unloading the solution (rather than fully exiting Visual
Studio) also appears to be adequate.
I've found that 2nd and subsequent launches of VS are not nearly as
painful as the initial launch. Sometimes you get into an overkill
habit that's hard to unlearn later on... :-)
___
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] VS2010 solution/project reload
> On Tue, Jan 4, 2011 at 6:58 AM, Andrea Galeazzi wrote:
>> I'm currently dealing with a project requiring a lot of dependencies
>> (74),
>> so the structure of the CMakeLists.txt is as following:
>> project ( Main )
>> add_subdirectory("W:/Lib1" "${CMAKE_CURRENT_BINARY_DIR}/Lib1")
>> add_subdirectory("W:/Lib2" "${CMAKE_CURRENT_BINARY_DIR}/Lib2")
>> add_subdirectory("W:/Lib3" "${CMAKE_CURRENT_BINARY_DIR}/Lib3")
>>
>> add_executable( Main ${SOURCES} )
>> target_link_libraries(Main ${LIB_TO_LINK})
>>
>> When I choose a VS2010 CMake generates a solution of 77 projects (74
>> +Main
>> + ALL_BUILD + ZERO_CHECK).
>> Now if I modify the CMakeLists.txt of one of the subproject and build
>> the
>> Main project VS2010 notify that many other project has been modified and
>> also the solution. So, for instance, if I add a file to a subproject
>> VS2010
>> shows a lot of dialog asking to reload the projects again and that's
>> very
>> frustrating!
>> My question is: is it a bug or a normal behavior? If the second, how can
>> I
>> avoid it?
> It's listed as a bug in the CMake bug tracker:
> http://public.kitware.com/Bug/view.php?id=11258
[...]
> For now the best workaround (that I personally use all the time), is
> to exit Visual Studio entirely, run cmake or cmake-gui manually, and
> then re-launch Visual Studio. It may sound painful, but really, it's
> much more enjoyable than wading through all the reload dialogs...
Isn't it enough to unload the solution? That would save at least the time
starting Visual Studio.
Eike
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to find the path to the currently include() or find_package file()
On Tue, Jan 4, 2011 at 2:00 AM, Michael Hertling wrote:
> On 01/04/2011 07:41 AM, Michael Hertling wrote:
>> On 01/04/2011 05:47 AM, John McGehee wrote:
>>> I am using CMake 2.8 on Linux and Windows.
>>>
>>> When I include() or find_package() a .cmake file, is there a variable that
>>> I can use within the included .cmake file that will tell me its path?
>>>
>>> For example,
>>>
>>> # In CMakeLists.txt
>>> include(somePath/foo.cmake)
>>>
>>> Within somePath/foo.cmake, I want to include bar.cmake which is in the same
>>> directory as foo.cmake,
>>>
>>> # In somePath/foo.cmake
>>> include(${CMAKE_VARIABLE_THAT_IS_THE_ANSWER_TO_THIS_QUESTION}/bar.cmake)
>>>
>>> where ${CMAKE_VARIABLE_THAT_IS_THE_ANSWER_TO_THIS_QUESTION} = "somePath",
>>> the path to foo.cmake, which is currently being evaluated.
>>
>> Use CMAKE_CURRENT_LIST_FILE in conjunction with GET_FILENAME_COMPONENT():
>
> Oops...or just CMAKE_CURRENT_LIST_DIR. ;|
>
> 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
>
But make sure to use them at file scope, (and not within a function
definition), and if you use CMAKE_CURRENT_LIST_DIR, understand that it
is only defined in CMake 2.8.3 and later.
HTH,
David
___
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] VS2010 solution/project reload
On Tue, Jan 4, 2011 at 6:58 AM, Andrea Galeazzi wrote:
> I'm currently dealing with a project requiring a lot of dependencies (74),
> so the structure of the CMakeLists.txt is as following:
> project ( Main )
> add_subdirectory("W:/Lib1" "${CMAKE_CURRENT_BINARY_DIR}/Lib1")
> add_subdirectory("W:/Lib2" "${CMAKE_CURRENT_BINARY_DIR}/Lib2")
> add_subdirectory("W:/Lib3" "${CMAKE_CURRENT_BINARY_DIR}/Lib3")
>
> add_executable( Main ${SOURCES} )
> target_link_libraries(Main ${LIB_TO_LINK})
>
> When I choose a VS2010 CMake generates a solution of 77 projects (74 +Main
> + ALL_BUILD + ZERO_CHECK).
> Now if I modify the CMakeLists.txt of one of the subproject and build the
> Main project VS2010 notify that many other project has been modified and
> also the solution. So, for instance, if I add a file to a subproject VS2010
> shows a lot of dialog asking to reload the projects again and that's very
> frustrating!
> My question is: is it a bug or a normal behavior? If the second, how can I
> avoid it?
>
> ___
> 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
>
It's listed as a bug in the CMake bug tracker:
http://public.kitware.com/Bug/view.php?id=11258
Also, just yesterday I submitted a bug to Microsoft regarding the
difference in behavior w.r.t. VS2008 and VS2010. We are waiting to see
what they say in that bug report:
https://connect.microsoft.com/VisualStudio/feedback/details/634469/vs-2010-yields-blocking-error-dialog-when-a-macro-tries-to-stop-the-build-vs-2008-did-not
For now the best workaround (that I personally use all the time), is
to exit Visual Studio entirely, run cmake or cmake-gui manually, and
then re-launch Visual Studio. It may sound painful, but really, it's
much more enjoyable than wading through all the reload dialogs...
HTH,
David
___
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] VS2010 solution/project reload
I'm currently dealing with a project requiring a lot of dependencies
(74), so the structure of the CMakeLists.txt is as following:
project ( Main )
add_subdirectory("W:/Lib1" "${CMAKE_CURRENT_BINARY_DIR}/Lib1")
add_subdirectory("W:/Lib2" "${CMAKE_CURRENT_BINARY_DIR}/Lib2")
add_subdirectory("W:/Lib3" "${CMAKE_CURRENT_BINARY_DIR}/Lib3")
add_executable( Main ${SOURCES} )
target_link_libraries(Main ${LIB_TO_LINK})
When I choose a VS2010 CMake generates a solution of 77 projects (74
+Main + ALL_BUILD + ZERO_CHECK).
Now if I modify the CMakeLists.txt of one of the subproject and build
the Main project VS2010 notify that many other project has been modified
and also the solution. So, for instance, if I add a file to a subproject
VS2010 shows a lot of dialog asking to reload the projects again and
that's very frustrating!
My question is: is it a bug or a normal behavior? If the second, how can
I avoid it?
___
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
