[CMake] INSTALL EXPORT for Debug and Release
With two build directories -- one for release and one for debug -- using the Makefile generator, it seems like calling one 'make install' replaces out the export files for the other with the message: > Old export file ".cmake" will be replaced. Removing files [-debug.cmake] The INSTALL snippet just looks like: > install(EXPORT DESTINATION lib/) The question is, is it possible to use a single config generator like Makefiles to install both a working release and debug version of a library? -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] adding file extensions for languages
Hello, I was trying to add some file extensions for the Fortran language (.ftn), but I was not able to get past some errors even after trying a few different options including appending to CMAKE_Fortran_SOURCE_FILE_EXTENSIONS in a toolchain file. Ideas on how to get around the following error(s)? It looks like set_target_property might work, but I'd rather just add the extension to work as any other accepted extension. -- Configuring done CMake Error: CMake can not determine linker language for target: ftn_mpi_hello CMake Error: Cannot determine link language for target "ftn_mpi_hello". -- Generating done Thanks, Justin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] alternative method for setting CMAKE_TOOLCHAIN_FILE?
Hello, Is there an alternative method for setting the CMAKE_TOOLCHAIN_FILE variable other than, for example: cmake -D CMAKE_TOOLCHAIN_FILE=... Perhaps an environment variable or something similar? Thanks, Justin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] cmake option system-information interaction with other definition options
Hello, I'm finding the cmake --system-information command option to be valuable in testing different things. However it appears that it does not appear to work with -D. For example: cmake -DCMAKE_C_COMPILER=/usr/bin/gcc --system-information system.txt The information in 'system.txt' will not contain the defined compiler from the -D option. I wonder if this is intended? Will it work with a toolchain file instead? Or do I need to do a real build in order to make use of toolchain files and the -D option? Thanks, Justin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Clang + MinGW Linking Issue
Were you passing custom command-line arguments in the project? Clang only
accepts a very limited set of CL-style arguments (AFAIK):
>c:\projects\llvm-dev\build-3.1\bin\clang clang-test.c -out:clang-test.exe
>c:\projects\llvm-dev\build-3.1\bin\clang clang-test.c -out:clang-test.exe
-Zm
clang: error: unsupported use of internal gcc -Z option '-Zm'
>c:\projects\llvm-dev\build-3.1\bin\clang clang-test.c -out:clang-test.exe
-MT
clang: error: argument to '-MT' is missing (expected 1 value)
This is with a Clang built with the compilers from the Windows SDK 7.1.
On Thu, May 24, 2012 at 2:12 PM, Keith Gardner wrote:
> I have built clang (llvm) on windows with Visual Studio 2010 and used the
> built binaries as the compiler inside of a Visual Studio project. This was
> with clang 3.0 and llvm 2.9.1.
>
> ** **
>
> *From:* cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] *On
> Behalf Of *Justin Holewinski
> *Sent:* Thursday, May 24, 2012 1:49 PM
> *To:* Brad King
> *Cc:* cmake@cmake.org
> *Subject:* Re: [CMake] Clang + MinGW Linking Issue
>
> ** **
>
> On Thu, May 24, 2012 at 10:08 AM, Brad King wrote:
>
>
> On 05/24/2012 12:22 PM, Justin Holewinski wrote:
> > I narrowed the problem down to Clang not having
> Platform/Windows-Clang-{C,CXX}.cmake files.
>
> There is an issue tracker entry for this:
>
> http://www.cmake.org/Bug/view.php?id=13035
>
> but it is in the backlog waiting for more feedback and a volunteer.
> The main problem is distinguishing the GNU-compatible and MS-compatible
> builds of Clang.
>
> ** **
>
> Oops, missed that issue. Sorry about that!
>
>
>
>
> > If I add the following two files then everything starts to work as
> expected:
> >
> > Platform/Windows-Clang-C.cmake:
> >
> > if(MINGW)
> > include(Platform/Windows-GNU)
> > __windows_compiler_gnu(C)
> > else()
> > # Chain to generic Windows configuration
> > include(Platform/Windows)
> > endif()
> >
> > Platform/Windows-Clang-CXX.cmake:
> >
> > if(MINGW)
> > include(Platform/Windows-GNU)
> > __windows_compiler_gnu(C)
> > else()
> > # Chain to generic Windows configuration
> > include(Platform/Windows)
> > endif()
> >
> > This way, using Clang with MinGW will force GNU-style platform
> > options instead of VS-style Windows options.
> > Is this more or less the "right way" to fix this in CMake?
>
> Interesting approach. That may be better than separating the
> compiler id as mentioned in the above-linked issue. The "MINGW"
> value is set based on CMAKE_C_PLATFORM_ID which is computed in
> the same way and at the same time as CMAKE_C_COMPILER_ID. Try:
>
> $ cat Platform/Windows-Clang-C.cmake
> if("${CMAKE_C_PLATFORM_ID}" MATCHES "MinGW")
> include(Platform/Windows-GNU-C)
> else()
> include(Platform/Windows-cl)
> endif()
>
> $ cat Platform/Windows-Clang-CXX.cmake
> if("${CMAKE_CXX_PLATFORM_ID}" MATCHES "MinGW")
> include(Platform/Windows-GNU-CXX)
> else()
> include(Platform/Windows-cl)
> endif()
>
> Do you have both the MS-style and GNU-style Clang available
> to test?
>
> ** **
>
> This works for the MinGW build. I really can't say if this fixes the
> library naming issue for the MS-style Clang. Clang does not have a
> VC-compatible driver (that I know of) so does not accept VC-style arguments
> like "/O2", which causes CMake to fail early on in the configure process
> when using the NMake generator. Clang with MinGW is the only really
> supported configuration at this point.
>
>
>
>
> Thanks,
> -Brad
>
>
>
>
>
> ** **
>
> --
>
> Thanks,
>
> ** **
>
> Justin Holewinski
>
> ** **
>
--
Thanks,
Justin Holewinski
--
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] Clang + MinGW Linking Issue
On Thu, May 24, 2012 at 10:08 AM, Brad King wrote:
> On 05/24/2012 12:22 PM, Justin Holewinski wrote:
> > I narrowed the problem down to Clang not having
> Platform/Windows-Clang-{C,CXX}.cmake files.
>
> There is an issue tracker entry for this:
>
> http://www.cmake.org/Bug/view.php?id=13035
>
> but it is in the backlog waiting for more feedback and a volunteer.
> The main problem is distinguishing the GNU-compatible and MS-compatible
> builds of Clang.
>
Oops, missed that issue. Sorry about that!
>
> > If I add the following two files then everything starts to work as
> expected:
> >
> > Platform/Windows-Clang-C.cmake:
> >
> > if(MINGW)
> > include(Platform/Windows-GNU)
> > __windows_compiler_gnu(C)
> > else()
> > # Chain to generic Windows configuration
> > include(Platform/Windows)
> > endif()
> >
> > Platform/Windows-Clang-CXX.cmake:
> >
> > if(MINGW)
> > include(Platform/Windows-GNU)
> > __windows_compiler_gnu(C)
> > else()
> > # Chain to generic Windows configuration
> > include(Platform/Windows)
> > endif()
> >
> > This way, using Clang with MinGW will force GNU-style platform
> > options instead of VS-style Windows options.
> > Is this more or less the "right way" to fix this in CMake?
>
> Interesting approach. That may be better than separating the
> compiler id as mentioned in the above-linked issue. The "MINGW"
> value is set based on CMAKE_C_PLATFORM_ID which is computed in
> the same way and at the same time as CMAKE_C_COMPILER_ID. Try:
>
> $ cat Platform/Windows-Clang-C.cmake
> if("${CMAKE_C_PLATFORM_ID}" MATCHES "MinGW")
> include(Platform/Windows-GNU-C)
> else()
> include(Platform/Windows-cl)
> endif()
>
> $ cat Platform/Windows-Clang-CXX.cmake
> if("${CMAKE_CXX_PLATFORM_ID}" MATCHES "MinGW")
> include(Platform/Windows-GNU-CXX)
> else()
> include(Platform/Windows-cl)
> endif()
>
> Do you have both the MS-style and GNU-style Clang available
> to test?
>
This works for the MinGW build. I really can't say if this fixes the
library naming issue for the MS-style Clang. Clang does not have a
VC-compatible driver (that I know of) so does not accept VC-style arguments
like "/O2", which causes CMake to fail early on in the configure process
when using the NMake generator. Clang with MinGW is the only really
supported configuration at this point.
>
> Thanks,
> -Brad
>
--
Thanks,
Justin Holewinski
--
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] Clang + MinGW Linking Issue
Hi Again,
I narrowed the problem down to Clang not having
Platform/Windows-Clang-{C,CXX}.cmake files. If I add the following two
files then everything starts to work as expected:
Platform/Windows-Clang-C.cmake:
if(MINGW)
include(Platform/Windows-GNU)
__windows_compiler_gnu(C)
else()
# Chain to generic Windows configuration
include(Platform/Windows)
endif()
Platform/Windows-Clang-CXX.cmake:
if(MINGW)
include(Platform/Windows-GNU)
__windows_compiler_gnu(C)
else()
# Chain to generic Windows configuration
include(Platform/Windows)
endif()
This way, using Clang with MinGW will force GNU-style platform options
instead of VS-style Windows options. Is this more or less the "right way"
to fix this in CMake?
On Wed, May 23, 2012 at 3:22 PM, Justin Holewinski <
justin.holewin...@gmail.com> wrote:
> Hi All,
>
> I've been trying out CMake for building C++ applications on Windows with
> Clang, using the MinGW headers/libraries. This works fine, except if I
> need to pull in non-default system libraries that are included with MinGW,
> such as libpsapi.a (psapi.lib for VS). For example, if I have the
> following CMakeLists.txt file:
>
> project(pstest1)
> add_executable(pstest1 pstest1.cpp)
> target_link_libraries(pstest1 psapi)
>
>
> This fails with a linker error:
>
> Linking CXX executable pstest1.exe
> c:\projects\cmake-2.8.8-win32-x86\bin\cmake.exe -E cmake_link_script
> CMakeFiles\pstest1.dir\link.txt --verbose=1
> C:\projects\clang+llvm-3.1-i386-mingw32-EXPERIMENTAL\bin\clang++.exe
> CMakeFiles/pstest1.dir/pstest1.obj -o pst
> est1.exe *-lpsapi.lib*
> *c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe:
> cannot find -lpsapi.lib*
> collect2: ld returned 1 exit status
> clang++: error: linker (via gcc) command failed with exit code 1 (use -v
> to see invocation)
> mingw32-make[2]: *** [pstest1.exe] Error 1
> mingw32-make[2]: Leaving directory `C:/projects/mingw-tests/pstest1/build'
> mingw32-make[1]: *** [CMakeFiles/pstest1.dir/all] Error 2
> mingw32-make[1]: Leaving directory `C:/projects/mingw-tests/pstest1/build'
> mingw32-make: *** [all] Error 2
>
>
> CMake seems to be using MSVC library naming conventions for Clang in MinGW
> mode, but also using the GCC-style -l flags for specifying libraries. If I
> replace
>
> target_link_libraries(pstest1 psapi)
>
> with
>
> target_link_libraries(pstest1 "c:/MinGW/lib/libpsapi.a")
>
> then everything works as expected (I got -lpsapi on the link line).
> Interestingly, everything also works correctly if I use the default
> mingw32-gcc.exe compiler instead of clang.exe. So this seems to be a CMake
> issue where it detects Clang but does not know how to properly pass
> GCC-style linker flags to Clang.
>
> Any ideas?
>
>
> --
>
> Thanks,
>
> Justin Holewinski
>
>
--
Thanks,
Justin Holewinski
--
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] Clang + MinGW Linking Issue
Hi All, I've been trying out CMake for building C++ applications on Windows with Clang, using the MinGW headers/libraries. This works fine, except if I need to pull in non-default system libraries that are included with MinGW, such as libpsapi.a (psapi.lib for VS). For example, if I have the following CMakeLists.txt file: project(pstest1) add_executable(pstest1 pstest1.cpp) target_link_libraries(pstest1 psapi) This fails with a linker error: Linking CXX executable pstest1.exe c:\projects\cmake-2.8.8-win32-x86\bin\cmake.exe -E cmake_link_script CMakeFiles\pstest1.dir\link.txt --verbose=1 C:\projects\clang+llvm-3.1-i386-mingw32-EXPERIMENTAL\bin\clang++.exe CMakeFiles/pstest1.dir/pstest1.obj -o pst est1.exe *-lpsapi.lib* *c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe: cannot find -lpsapi.lib* collect2: ld returned 1 exit status clang++: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation) mingw32-make[2]: *** [pstest1.exe] Error 1 mingw32-make[2]: Leaving directory `C:/projects/mingw-tests/pstest1/build' mingw32-make[1]: *** [CMakeFiles/pstest1.dir/all] Error 2 mingw32-make[1]: Leaving directory `C:/projects/mingw-tests/pstest1/build' mingw32-make: *** [all] Error 2 CMake seems to be using MSVC library naming conventions for Clang in MinGW mode, but also using the GCC-style -l flags for specifying libraries. If I replace target_link_libraries(pstest1 psapi) with target_link_libraries(pstest1 "c:/MinGW/lib/libpsapi.a") then everything works as expected (I got -lpsapi on the link line). Interestingly, everything also works correctly if I use the default mingw32-gcc.exe compiler instead of clang.exe. So this seems to be a CMake issue where it detects Clang but does not know how to properly pass GCC-style linker flags to Clang. Any ideas? -- Thanks, Justin Holewinski -- 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] Again multiple subdirs
Hi,
and just in the beginning, I am sorry if this was asked thousands of
times before, but I wasn't able to find it.
The situation is following
src -- common -- common.c
|
a -- a.c
|
b -- b.c
add_library (a
${project_SOURCE_DIR}/common/common
${project_SOURCE_DIR}/a/a}
add_library (b
${project_SOURCE_DIR}/common/common
${project_SOURCE_DIR}/b/b}
This results in a double compilation of common.c. One time for liba and
the other one for libb.
What is the best way to force common.c to be compiled just ones?
Thanks justin
signature.asc
Description: OpenPGP digital signature
--
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] Cross-compiling, CMAKE_C_FLAGS, and configure-time compiler tests
On Tue, Dec 14, 2010 at 4:45 AM, Johan Björk wrote:
> Hi Justin,
>
> I'm very unsure if this is the correct solution, but it worked for me. I
> haven't been able to find any good documentation stating how the CMakeCache
> interacts with other parts of CMake.
>
> My assumption is that since CMAKE_C{XX}_FLAGS is supposed to allow the user
> to set optional compilation flags, it prefers the value in the cache versus
> the one from the toolchain file.
>
> From one of my toolchain files, reproduce as necessary for CMAKE_C_FLAGS:
> SET(CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -fno-rtti" CACHE STRING "" FORCE)
>
I'll have to give that a try. For now, I'm getting around the problem by
setting the flags within the parent CMakeLists.txt script after loading the
toolchain file.
I'm really not sure what the "best practice" is for this situation. The
compiler will work and can be tested without the "-arch" flags, but the
flags are necessary to build for the *right* architecture. Most
cross-compilers will only produce binaries for the target system, so the
point is moot. The iOS compilers, however, will generate code for Intel and
ARM so I'm not sure if testing the i386 back-end when I'm targeting ARM is
the right way or not.
>
> Cheers
> /Johan
>
>
> On Mon, Dec 13, 2010 at 4:49 PM, Justin Holewinski <
> justin.holewin...@gmail.com> wrote:
>
>> I am experiencing a cross-compiling issue that I believe is related to how
>> toolchain files interact with the configure-time compiler checks. For
>> reference, I am targeting the iOS 4.2 SDK. I have a toolchain file that
>> sets CMAKE_C_FLAGS, CMAKE_CXX_FLAGS, CMAKE_C_LINK_FLAGS, and
>> CMAKE_CXX_LINK_FLAGS with appropriate flags for the iOS platform, in
>> particular "-arch armv6 -arch armv7". The toolchain file also sets the
>> proper C and C++ compilers.
>>
>> When CMake is executed and the C compiler is tested, the
>> toolchain-specified compiler arguments are passed to the link line, but
>> *not* the compile line (according to the error output). Since the compile
>> line does not contain the "-arch" arguments, the generated object file is
>> for i386. However, since the link line contains these flags, the linker
>> tries to link ARM code and fails.
>>
>> Are there any additional variables I should be setting in addition to
>> CMAKE_C_FLAGS and CMAKE_CXX_FLAGS in order to get the compiler tests to use
>> the right flags? If I add the "-arch" flags using ADD_DEFINITIONS(), they
>> are passed to the compiler test and it succeeds. That seems like a hack and
>> not a proper solution, though.
>>
>> Below is the CMake output that prints the values of CMAKE_*_FLAGS as set
>> by the toolchain file, as well as the compile and link lines used by CMake.
>>
>> I am using CMake 2.8.3 on Snow Leopard 10.6.5.
>>
>> CMake Output:
>>
>> -- CMAKE_C_FLAGS:-arch armv6 -arch armv7 -pipe -no-cpp-precomp
>> --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
>> -miphoneos-version-min=4.2
>> -- CMAKE_CXX_FLAGS -arch armv6 -arch armv7 -pipe -no-cpp-precomp
>> --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
>> -miphoneos-version-min=4.2
>> -- CMAKE_C_LINK_FLAGS-arch armv6 -arch armv7 -pipe -no-cpp-precomp
>> --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
>> -miphoneos-version-min=4.2
>> -- CMAKE_CXX_LINK_FLAGS -arch armv6 -arch armv7 -pipe -no-cpp-precomp
>> --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
>> -miphoneos-version-min=4.2
>> -- CMAKE_C_FLAGS:-arch armv6 -arch armv7 -pipe -no-cpp-precomp
>> --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
>> -miphoneos-version-min=4.2
>> -- CMAKE_CXX_FLAGS -arch armv6 -arch armv7 -pipe -no-cpp-precomp
>> --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
>> -miphoneos-version-min=4.2
>> -- CMAKE_C_LINK_FLAGS-arch armv6 -arch armv7 -pipe -no-cpp-precomp
>> --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
>> -miphoneos-version-min=4.2
>> -- CMAKE_CXX_LINK_FLAGS -arch armv6 -arch armv7 -pipe -no-cpp-precomp
>> --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
>> -miphoneos-version-min=4.2
>> -- The C compiler identification is GNU
>> -- The CXX compiler identification is GNU
>> -- Check for working C compiler:
>> /Developer/Platforms/iPhoneOS.platform/Developer
[CMake] Cross-compiling, CMAKE_C_FLAGS, and configure-time compiler tests
hitecture armv6 collect2: ld returned 1 exit status ld: warning: in CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj, file was built for i386 which is not the architecture being linked (armv7) Undefined symbols for architecture armv7: "_main", referenced from: start in crt1.3.1.o ld: symbol(s) not found for architecture armv7 collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/pS/pSWOJvZ-FDS4A2Eo7TwIzE+++TI/-Tmp-//ccKkL4CZ.out (No such file or directory) make[1]: *** [cmTryCompileExec] Error 1 make: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:30 (project) -- Configuring incomplete, errors occurred! -- Thanks, Justin Holewinski ___ 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] INSTALL_NAME_DIR with IMPORTED targets
Is there a way to make CMake honor the INSTALL_NAME_DIR property for
IMPORTED library targets?
For the Mac OS X build of an application, I have a binary-only, third-
party library in the form of a .dylib that I keep in the source tree.
I add it to my CMake build script as such:
ADD_LIBRARY(foo SHARED IMPORTED)
SET_TARGET_PROPERTIES(foo PROPERTIES IMPORTED_LOCATION "$
{THIRD_PARTY_LIB}")
where THIRD_PARTY_LIB is the path to the library in the source tree.
When I configure the bundle for the application, I add ``foo'' as a
link library with TARGET_LINK_LIBRARIES, e.g.
ADD_EXECUTABLE(myexe MACOSX_BUNDLE "")
TARGET_LINK_LIBRARIES(myexe foo ${OTHER_LIBRARY_TARGETS})
where OTHER_LIBRARY_TARGETS are additional shared libraries built for
the project.
I install with:
INSTALL(TARGETS myexe DESTINATION .)
INSTALL(TARGETS ${OTHER_LIBRARY_TARGETS} DESTINATION myexe.app/
Contents/MacOS)
INSTALL(FILES ${THIRD_PARTY_LIB})
As is, this builds the app bundle but does not properly adjust
the .dylib paths in the binaries. I can fix this with:
SET_TARGET_PROPERTIES(${OTHER_LIBRARY_TARGETS} PROPERTIES
INSTALL_NAME_DIR "@executable_path")
and this works great for the shared libraries built for the project,
but this does *not* work for the IMPORTED library:
SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_NAME_DIR
"@executable_path")
or
SET_TARGET_PROPERTIES(${THIRD_PARTY_LIB} PROPERTIES INSTALL_NAME_DIR
"@executable_path")
In either case, ``otool -L'' shows that the third-party library name
is not prepended with @executable_path and hence trying to launch the
bundle as an application fails with an error saying the third-party
library could not be located.
Is there a way to make CMake honor INSTALL_NAME_DIR for IMPORTED
targets, or perhaps a better way of linking against and installing
third-party libraries on Mac OS X using CMake's install provisions? I
could probably use a post-build shell script, but I would like to do
this within the CMake build scripts, if possible.
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
[CMake] Using Intel C++ Compiler for Mixed C++/Objective-C++ Project on Mac OS X
I have a project that uses both plain C++ (.cpp) and Objective-C++ (.mm)
sources on Mac OS X. Using the Makefile target of CMake with the native
compiler (GCC) works fine. However, the Intel C++ compiler does not handle
Objective-C++ sources so CMake-generated Makefiles fail when the .mm files
are passed to icc/icpc (the Intel C and C++ compilers). Is there a way to
instruct CMake to use icc/icpc for C/C++ files and gcc for .m/.mm files?
Can this be done without having to rewrite ADD_EXECUTABLE and other macros?
Example:
test.c:
extern void foo();
int main()
{
foo();
return 0;
}
testobjc.m:
#include
int foo()
{
printf("foo()\n");
}
CMakeLists.txt:
cmake_minimum_required(VERSION 2.6)
PROJECT(Test)
ADD_EXECUTABLE(test test.c testobjc.m)
Using GCC:
$ cmake ...
$ make
Scanning dependencies of target test
[ 50%] Building C object CMakeFiles/test.dir/test.c.o
[100%] Building CXX object CMakeFiles/test.dir/testobjc.m.o
Linking CXX executable test
[100%] Built target test
Using ICC:
$ CC=icc CXX=icpc cmake ...
$ make
Scanning dependencies of target test
[ 50%] Building C object CMakeFiles/test.dir/test.c.o
[100%] Building CXX object CMakeFiles/test.dir/testobjc.m.o
icpc: warning #10147: no action performed for specified file(s)
Linking CXX executable test
icpc: error #10236: File not found: 'CMakeFiles/test.dir/testobjc.m.o'
make[2]: *** [test] Error 1
make[1]: *** [CMakeFiles/test.dir/all] Error 2
make: *** [all] Error 2
"Desired":
$ icc -fast test.c -o test.o -c
$ gcc -O3 testobjc.m -o testobjc.o -c
$ icc -fast test.o testobjc.o -o test
--
Thanks,
Justin Holewinski
___
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
