Re: [CMake] CMake 2.8.2 RC 1 ready for testing!
Hi, Will the nice PROJECT_GROUP feature described here: http://public.kitware.com/Bug/view.php?id=3796 be in this release? Regards, Fabrice Aeschbacher > > I am happy to announce that CMake 2.8.2 has entered the release > candidate stage! You can find the source and binaries here: > http://www.cmake.org/files/v2.8/. > > Following is the list of changes in this release. (If you notice > something missing please let me know and I will add it to the official > release when 2.8.2 is finalized.) > > Changes in CMake 2.8.2 RC 1 (since CMake 2.8.1) > - Build on Tru64 (#10542) > - Build on mingw-w64 > - Build on old Sun (#10550, #10543) > - CPack: Add native BZip2 support > - CPack: Set compression type in RPM spec (#10363) > - CPack: Try harder to initialize staging directory (#10793) > - CTest: Add --stop-time argument > - CTest: Cost data with '-j' > - CTest: Fix memory report > - CTest: Glob for uncovered files during coverage tests > - CTest: Option to specify cdash server > - CTest: PHP Coverage support > - CTest: Process tree kill for OpenBSD, FreeBSD, kFreeBSD, GNU/Hurd > - CTest: Report failure in Update.xml > - CTest: Submit author email in Update.xml > - CTest: Teach ctest_update about Git submodules > - Cygwin: Export all symbols with ENABLE_EXPORTS (#10122) > - Do not list file names during 'cmake -E tar xz' > - Documentation: Comply with "XHTML 1.0 Strict" > - Documentation: Fix typo in CMAKE_LIBRARY_PATH (#10291) > - Documentation: Fix typo in HAS_CXX docs (#10578) > - Documentation: More consistent command signatures > - Eclipse: Do not add INCLUDE to environment twice > - Enable extra CodeBlocks generator on Cygwin > - ExternalProject: Support .zip and .bz2 archives, MD5 verification > - ExternalProject: Reconfigure when args change (#10258) > - ExternalProject: Support Git, SVN username/password > - FindCurses: Fix for cygwin ncurses package > - FindHSPELL: Version support > - FindJava: Error if version is not found only when REQUIRED > - FindJava: Support runtime and development components (#9840) > - FindKDE4: Prefer kdeconfig results over system paths > - FindMPEG: Check for 'vo' library > - FindPNG: Support png 1.4 versioned lib names (#10551) > - FindPkgConfig: Add QUIET keyword to pkgconfig macros (see #10469) > - FindZLIB: GnuWin32 support, version support (#5588) > - FindwxWidget: Fix CXX flag parsing (#10209) > - Fix .pdb name attribute in VS project files (#10614) > - Fix CodeBlocks to work with Fortran-only > - Fix VS 2010 custom commands (#10503) > - Fix VS 6 support for COMPILE_DEFINITIONS_MINSIZEREL (#10700) > - Fix cross-compiling from Linux to iPhone (#10526) > - Fix documentation typos > - Fix g95 Fortran compiler support > - Fix uname masking in file(WRITE) and write_file (#10789) > - GetPrerequisites: Provide an override hook > - Handle non-ASCII terminators in file(STRINGS) > - Module fixes: FindPythonLibs, FindQt4, FindX11, FindwxWidgets > - PathScale Fortran compiler tool detection > - Qt4 OpenGL framework fix > - Qt4ConfigDependentSettings.cmake Qt4Macros.cmake UseQt4.cmake > - Recognize ARM ABI/EABI with GNU compilers > - Recognize Clang compiler > - Search basic directories on "Generic" platform > - Set MSVC* variables consistently on all generators, and test > - Support SunPro C++ 5.11 on Linux (new compiler) > - Support VS 10 Express (related to #10670) > - Support compression with 'cmake -E tar' > - Support multiple arguments in CC,CXX,FC environment variables > - Support per-configuration librarian flags (#10768) > - Support per-platform initial ASM language flags (#10577) > - Use Fortran ABI detection results conservatively > - Use libarchive to replace the unmaintained libtar > - UseQt4: Support QtMultimedia (#10675) > - bootstrap: Fix make tool detection (#10544) > - cmake-gui: Add simple grouped view > - cmake-gui: Support build tree under symlink (#9975) > - Cleanup modules FindASPELL, FindAVIFile, FindBZip2, FindDart, > FindEXPAT, FindGCCXML, FindGLU, FindHSPELL, FindJasper, FindLibXml2, > FindLibXslt, FindMPEG, FindOpenAL, FindPhysFS, FindQuickTime, > FindSubversion, FindZLIB. > > > Please try this version of CMake on your projects and report any > issues to the list or the bug tracker. > > Happy building! > > -Dave > ___ > 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] vcproj2cmake.rb script: announcing new version / hosting questions
On 06/14/2010 05:00 PM, Andreas Mohr wrote: Frankly the entire distinction between CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE remains one of the more confusing things, as can be witnessed in several confused postings about this topic. (but I'm afraid that's just the way it is - there's nothing to be improved about these mechanisms since they're likely just doing what they should) The biggest annoyment I have with CMake is the fact the the makefile generators don't support building multiple configurations in the same build tree. Not sure if it would be practical to fix, though. -- Jesper Eskilson Developer IAR Systems http://www.iar.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] The find_xxx family and VS
It seems, that CMake can detect the MSVC specific headers and libraries only, if it runs within Visual Studio. For example: FIND_FILE(STD_FILE stdio.h), FIND_PATH(STD_PATH stdio.h) or FIND_LIBRARY(LIB_PATH comctl32) results in "NOT-FOUND", if CMake is run outside the IDE with an empty Build-Directory. This means the first run of the compiler/linker always fails, since CMake regenerates the solution-/config-files only if there is a change in the script/config files inside VS. This always leads to complex instructions for third-party users who just want to build the programs/libraries, like this. "After you have build the solution files with cmake-gui: - open VS, - open the project - open the "Top-level"-CMakeList.txt file - Hit a space in an empty line - Rebuild the project. Is there a better foolproof method to solve this. Micha ___ 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] ${PROJECT}-config.cmake
Michael Hertling wrote: > On 06/14/2010 12:09 PM, Biddiscombe, John A. wrote: >> I've modified the project so that it generates an hdf5-config.cmake >> file, which checks for If(NOT target blah blah) and then loads the >> hdf5-targets.cmake file. [snip] > To make things more convenient, would it be possible to > automatically protect the imported targets' definitions in the targets > file generated by INSTALL(EXPORT ...) using IF(NOT TARGET ...) along > with the associated properties in the configuration-specific files? The targets.cmake files are supposed to be included through a -config.cmake file as discussed in this thread. The outer config file would need blockers for its settings to handle the use case under discussion, so doing it in the targets file is redundant. I want to keep the targets file as simple as possible, providing only information that developers cannot get reliably. This means there should be minimal logic. Using "if(NOT TARGET)" could cause silent failure when one of the targets accidentally conflicts with a target defined by the including project. One might end up with some of the imported targets configured properly and others confused by target name collisions. > Currently, as far as I can see, a parent > directory and its subdirectories have no possibility to load the same > package involving imported targets independently. It works if the subdirectory is added before the parent directory loads the targets: ... add_subdirectory(dir-using-Foo) find_package(Foo) ... The add_subdirectory command initializes processing in the subdirectory with the state of the parent directory, including currently imported targets. However, in a single project the inner directory should know that the targets were imported by an ancestor and not bother loading the package. The trouble comes when the inner directory is a project that can also build stand-alone. In this case it is probably a third-party dependency which should be configured before the rest of the project anyway. > to ask if it would be feasible to make imported targets really scoped, > i.e. the latest definition hides - but doesn't touch - the previous > one and remains valid until hidden by a descendant's definition. This would be cool, but I do not think it would work well. First, it can cause mixing of targets from different versions of imported package. For example: # finds version 1, but parent already loaded version 2 find_package(Foo) if(TARGET target_from_version_2) # ... uses target from wrong Foo endif() Second, the lazy evaluation of link dependencies makes the scope hard to define. The names passed to target_link_libraries() are not processed until generation time. This allows code like # lib_from_Foo not yet defined target_link_libraries(mylib1 lib_from_Foo) find_package(Foo) # loads lib_from_Foo target_link_libraries(mylib2 lib_from_Foo) to work. (The delayed evaluation allows things like circular dependencies among static libraries to work.) Now consider the scoped replacement case: # ...parent already loaded package Foo target_link_libraries(mylib1 lib_from_Foo) # ...finds different Foo than parent find_package(Foo) target_link_libraries(mylib2 lib_from_Foo) By the time CMake looks for an imported target "lib_from_Foo" to link to mylib1, it has been replaced by the one from a different version of Foo. This may be what the author intended, or it may not. -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] Problems with linking on MinGW?
I am using CMake 2.8.1 on Windows 7. I have MinGW installed with GCC 4.5
I have successfully compiled a library with a MinGW and cmake. The full
path to the library is: c:\working\etk_binaries\libetk-mgw45.a
However, when I want to link this file into an executable (no need to have
the CMake dependencies, etc. in projects) it can't seem to find this file.
My cmakelists.txt is:
cmake_minimum_required(VERSION 2.6)
set(PROJECT_NAME "test" )
set(SRCS test.cpp )
project(${PROJECT_NAME})
add_executable(${PROJECT_NAME} ${SRCS})
link_directories( "c:/working/etk_binaries")
target_link_libraries(${PROJECT_NAME} libetk-mgw45)
The error I get is:
c:\MinGW\bin/ld.exe: cannot find -llibetk-mgw45
collect2: ld returned 1 exit status
mingw32-make[2]: *** [test.exe] Error 1
mingw32-make[1]: *** [CMakeFiles/test.dir/all] Error 2
Any ideas on what I have done wrong?
Thanks,
Jesse
___
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] CheckForPthreads.c
I have been converting an existing make based build system over to cmake,
and overall I am loving it so far.
I happened to run across CheckForPthreads.c, and was a little surprised to
see that it was basically a classic example of racy code.
The two spawned threads both increment res, which is then used as the return
value of the whole program. So to prove to myself that this was a real
issue, not just theoretical raciness, I compile the program, and ran it a
couple million times on my linux box, and 7 of those two million runs
returned 1 instead of 2. So the chance of screwup is quite small, but
definitely non-zero.
Looking over the source I have a few questions:
Should it protect the increment with a mutex?
Or, should it really just spawn 1 thread? Is there a point to the spawning
two?
Is there a purpose to all the prints?
What is the line "if(ac > 1000){return *av[0];}" there for? If it has a
purpose that definitely deserves a comment.
What about the "#if defined(__BEOS__)"... lines? The usleep will only be
there on BEOS, but the comment on the usleep line mentions sun.
Kevin
___
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] The find_xxx family and VS
Am Dienstag, den 15.06.2010, 14:12 +0200 schrieb Micha Renner: > It seems, that CMake can detect the MSVC specific headers and libraries > only, if it runs within Visual Studio. > > For example: > FIND_FILE(STD_FILE stdio.h), > FIND_PATH(STD_PATH stdio.h) or > FIND_LIBRARY(LIB_PATH comctl32) > > results in "NOT-FOUND", if CMake is run outside the IDE with an empty > Build-Directory. > > This means the first run of the compiler/linker always fails, since > CMake regenerates the solution-/config-files only if there is a change > in the script/config files inside VS. > > This always leads to complex instructions for third-party users who just > want to build the programs/libraries, like this. > "After you have build the solution files with cmake-gui: > - open VS, > - open the project > - open the "Top-level"-CMakeList.txt file > - Hit a space in an empty line > - Rebuild the project. > > Is there a better foolproof method to solve this. cmake-2.8.2-rc1, a very good solution. Just in time, thanks Micha ___ 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] Problems with linking on MinGW?
On 06/15/2010 09:54 AM, Jesse Perla wrote:
I am using CMake 2.8.1 on Windows 7. I have MinGW installed with GCC 4.5
I have successfully compiled a library with a MinGW and cmake. The
full path to the library is: c:\working\etk_binaries\libetk-mgw45.a
However, when I want to link this file into an executable (no need to
have the CMake dependencies, etc. in projects) it can't seem to find
this file.
My cmakelists.txt is:
cmake_minimum_required(VERSION 2.6)
set(PROJECT_NAME "test" )
set(SRCS test.cpp )
project(${PROJECT_NAME})
add_executable(${PROJECT_NAME} ${SRCS})
link_directories( "c:/working/etk_binaries")
target_link_libraries(${PROJECT_NAME} libetk-mgw45)
The error I get is:
c:\MinGW\bin/ld.exe: cannot find -llibetk-mgw45
collect2: ld returned 1 exit status
mingw32-make[2]: *** [test.exe] Error 1
mingw32-make[1]: *** [CMakeFiles/test.dir/all] Error 2
Any ideas on what I have done wrong?
Thanks,
Jesse
You should use or create a FindXXX.cmake module that locates the desired
library and include files. Then, you should do something like
target_link_libraries(${PROJECT_NAME} ${ETK_LIBRARIES})
(The issue you are having is because you aren't using the full path to
the library.)
Ryan
--
Ryan Pavlik
HCI Graduate Student
Virtual Reality Applications Center
Iowa State University
rpav...@iastate.edu
http://academic.cleardefinition.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
Re: [CMake] Problems with linking on MinGW?
Am Dienstag 15 Juni 2010, 16:54:28 schrieb Jesse Perla:
> I am using CMake 2.8.1 on Windows 7. I have MinGW installed with GCC 4.5
>
> I have successfully compiled a library with a MinGW and cmake. The full
> path to the library is: c:\working\etk_binaries\libetk-mgw45.a
>
> However, when I want to link this file into an executable (no need to have
> the CMake dependencies, etc. in projects) it can't seem to find this file.
> My cmakelists.txt is:
> cmake_minimum_required(VERSION 2.6)
> set(PROJECT_NAME "test" )
> set(SRCS test.cpp )
> project(${PROJECT_NAME})
> add_executable(${PROJECT_NAME} ${SRCS})
>
> link_directories( "c:/working/etk_binaries")
> target_link_libraries(${PROJECT_NAME} libetk-mgw45)
>
>
> The error I get is:
>
> c:\MinGW\bin/ld.exe: cannot find -llibetk-mgw45
Your library name is NOT "libetk-mgw45". Try "etk-mgw45" instead and read
about library file names.
Also, do not use link_directories() but use find_library() and the value you
get from it.
HS
___
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] The find_xxx family and VS
Am Dienstag 15 Juni 2010, 14:12:38 schrieb Micha Renner: > It seems, that CMake can detect the MSVC specific headers and libraries > only, if it runs within Visual Studio. > > For example: > FIND_FILE(STD_FILE stdio.h), > FIND_PATH(STD_PATH stdio.h) or > FIND_LIBRARY(LIB_PATH comctl32) > > results in "NOT-FOUND", if CMake is run outside the IDE with an empty > Build-Directory. > > This means the first run of the compiler/linker always fails, since > CMake regenerates the solution-/config-files only if there is a change > in the script/config files inside VS. > > This always leads to complex instructions for third-party users who just > want to build the programs/libraries, like this. > "After you have build the solution files with cmake-gui: > - open VS, > - open the project > - open the "Top-level"-CMakeList.txt file > - Hit a space in an empty line > - Rebuild the project. > > Is there a better foolproof method to solve this. Yes. You must call cmake from the Visual Studio Command Prompt (either in the Windows start menu or from the IDE). Additional, there is no gain in trying to find libraries that come with the compiler or system when they are always there. Additionally, the compiler itself knows where to find them. HS ___ 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 2.8.2 RC 1 ready for testing!
The patch in issue #3796 has not been applied to the CMake 'next' branch yet. I think it is too late to consider for the 2.8.2 release, but it could easily be in for the release after that if it's acceptable as-is. (And somebody pushes it to next for testing on the dashboards...) However, it would be nice to generalize that feature so that it works with Xcode in addition to Visual Studio. There's a note in the bug to that effect. Thanks, David On Tue, Jun 15, 2010 at 4:09 AM, Aeschbacher, Fabrice < fabrice.aeschbac...@siemens.com> wrote: > Hi, > > Will the nice PROJECT_GROUP feature described here: > > http://public.kitware.com/Bug/view.php?id=3796 > > be in this release? > > Regards, > Fabrice Aeschbacher > > > > > I am happy to announce that CMake 2.8.2 has entered the release > > candidate stage! You can find the source and binaries here: > > http://www.cmake.org/files/v2.8/. > > > > Following is the list of changes in this release. (If you notice > > something missing please let me know and I will add it to the official > > release when 2.8.2 is finalized.) > > > > Changes in CMake 2.8.2 RC 1 (since CMake 2.8.1) > > - Build on Tru64 (#10542) > > - Build on mingw-w64 > > - Build on old Sun (#10550, #10543) > > - CPack: Add native BZip2 support > > - CPack: Set compression type in RPM spec (#10363) > > - CPack: Try harder to initialize staging directory (#10793) > > - CTest: Add --stop-time argument > > - CTest: Cost data with '-j' > > - CTest: Fix memory report > > - CTest: Glob for uncovered files during coverage tests > > - CTest: Option to specify cdash server > > - CTest: PHP Coverage support > > - CTest: Process tree kill for OpenBSD, FreeBSD, kFreeBSD, GNU/Hurd > > - CTest: Report failure in Update.xml > > - CTest: Submit author email in Update.xml > > - CTest: Teach ctest_update about Git submodules > > - Cygwin: Export all symbols with ENABLE_EXPORTS (#10122) > > - Do not list file names during 'cmake -E tar xz' > > - Documentation: Comply with "XHTML 1.0 Strict" > > - Documentation: Fix typo in CMAKE_LIBRARY_PATH (#10291) > > - Documentation: Fix typo in HAS_CXX docs (#10578) > > - Documentation: More consistent command signatures > > - Eclipse: Do not add INCLUDE to environment twice > > - Enable extra CodeBlocks generator on Cygwin > > - ExternalProject: Support .zip and .bz2 archives, MD5 verification > > - ExternalProject: Reconfigure when args change (#10258) > > - ExternalProject: Support Git, SVN username/password > > - FindCurses: Fix for cygwin ncurses package > > - FindHSPELL: Version support > > - FindJava: Error if version is not found only when REQUIRED > > - FindJava: Support runtime and development components (#9840) > > - FindKDE4: Prefer kdeconfig results over system paths > > - FindMPEG: Check for 'vo' library > > - FindPNG: Support png 1.4 versioned lib names (#10551) > > - FindPkgConfig: Add QUIET keyword to pkgconfig macros (see #10469) > > - FindZLIB: GnuWin32 support, version support (#5588) > > - FindwxWidget: Fix CXX flag parsing (#10209) > > - Fix .pdb name attribute in VS project files (#10614) > > - Fix CodeBlocks to work with Fortran-only > > - Fix VS 2010 custom commands (#10503) > > - Fix VS 6 support for COMPILE_DEFINITIONS_MINSIZEREL (#10700) > > - Fix cross-compiling from Linux to iPhone (#10526) > > - Fix documentation typos > > - Fix g95 Fortran compiler support > > - Fix uname masking in file(WRITE) and write_file (#10789) > > - GetPrerequisites: Provide an override hook > > - Handle non-ASCII terminators in file(STRINGS) > > - Module fixes: FindPythonLibs, FindQt4, FindX11, FindwxWidgets > > - PathScale Fortran compiler tool detection > > - Qt4 OpenGL framework fix > > - Qt4ConfigDependentSettings.cmake Qt4Macros.cmake UseQt4.cmake > > - Recognize ARM ABI/EABI with GNU compilers > > - Recognize Clang compiler > > - Search basic directories on "Generic" platform > > - Set MSVC* variables consistently on all generators, and test > > - Support SunPro C++ 5.11 on Linux (new compiler) > > - Support VS 10 Express (related to #10670) > > - Support compression with 'cmake -E tar' > > - Support multiple arguments in CC,CXX,FC environment variables > > - Support per-configuration librarian flags (#10768) > > - Support per-platform initial ASM language flags (#10577) > > - Use Fortran ABI detection results conservatively > > - Use libarchive to replace the unmaintained libtar > > - UseQt4: Support QtMultimedia (#10675) > > - bootstrap: Fix make tool detection (#10544) > > - cmake-gui: Add simple grouped view > > - cmake-gui: Support build tree under symlink (#9975) > > - Cleanup modules FindASPELL, FindAVIFile, FindBZip2, FindDart, > > FindEXPAT, FindGCCXML, FindGLU, FindHSPELL, FindJasper, FindLibXml2, > > FindLibXslt, FindMPEG, FindOpenAL, FindPhysFS, FindQuickTime, > > FindSubversion, FindZLIB. > > > > > > Please try this version of CMake on your projects and report any > > issues to the list or the bug tracker. > > > > Happy building! > > > > -Dave > > _
Re: [CMake] Problems with linking on MinGW?
On Tue, Jun 15, 2010 at 12:01 PM, Hendrik Sattler
wrote:
> Your library name is NOT "libetk-mgw45". Try "etk-mgw45" instead and read
> about library file names.
>
Thanks for your help. Alas, on MSVC10 and Intel11.1 windows, the
"link_directories" and "target_link_libraries" approach I used above (with
the full filename) worked fine and hence never tried other methods
I had tried the "etk-mgw45" without the "lib" and it didn't seem to work.
Also, do not use link_directories() but use find_library() and the value you
> get from it.
I have tried a few permutations with find_library, but not having a lot of
luck. Here is the current section of code I am testing with.
link_directories( "c:/working/etk_binaries")
find_library(LIB_NAME "etk-mgw45-d" "c:/working/etk_binaries")
message("Value of LIB_NAME ${LIB_NAME}")
if(${LIB_NAME} STREQUAL "LIB_NAME-NOTFOUND")
MESSAGE("FAILED TO FIND LIBRARY!!!")
endif(${LIB_NAME} STREQUAL "LIB_NAME-NOTFOUND")
I have c:\working\etk_binaries in my windows path, I have tried putting the
libetk-mgw45-d.a inside of the directory with the CMakeLists.txt/test.cpp.
And tried a few variations of find_library such as:
find_library(LIB_NAME NAME etk-mgw45-d PATHS "c:/working/etk_binaries"
PATH_SUFFIXES "a")
But I always get the NOTFOUND.
Any ideas?
___
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] plugin dependencies and TARGET_LINK_LIBRARIES()
How do i inform cmake when building a module that it depends on another module? Does cmake need to even know that? I am building a plugin based qt application (my first time with plugins) and my situlation like with many other applications is that plugin A depends on plugin B. In my application i take care to load plugin B before A. However, loading plugin A fails complaining that it could not resolve links which are in B. plugin B which only depends on the application loads fine. Now, everything works fine if i declare that plugin A depends on B using the TARGET_LINK_LIBRARIES() function. But for this to work, i have to declare both A and B as SHARED instead of MODULE libraries. What is the right way to go? I believe that since my application loads B before A, B should not fail to load and there really should be no need for the TARGET_LINK_LIBRARIES() call. -- Cheers! Kishore ___ 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] Problems with linking on MinGW?
Am Dienstag 15 Juni 2010, 18:25:20 schrieb Jesse Perla: > On Tue, Jun 15, 2010 at 12:01 PM, Hendrik Sattler > > wrote: > > Your library name is NOT "libetk-mgw45". Try "etk-mgw45" instead and read > > about library file names. > > Thanks for your help. Alas, on MSVC10 and Intel11.1 windows, the > "link_directories" and "target_link_libraries" approach I used above (with > the full filename) worked fine and hence never tried other methods > > I had tried the "etk-mgw45" without the "lib" and it didn't seem to work. gcc and msvc differ in their library naming. While gcc uses libfoo.a, msvc uses foo.lib. So your library must have the right naming according to the compiler you are going to use. To avoid other problems, you should have used the same compiler for the library. > Also, do not use link_directories() but use find_library() and the value > you > > > get from it. > > I have tried a few permutations with find_library, but not having a lot of > luck. Here is the current section of code I am testing with. > > link_directories( "c:/working/etk_binaries") > find_library(LIB_NAME "etk-mgw45-d" "c:/working/etk_binaries") You are not using find_library() correctly!: find_library(LIB_NAME etk-mgw45-d HINTS "c:/working/etk_binaries") And omit the link_directories() call. > Any ideas? You _really_ need to read about the proper library naming for your compilers! That's why you got confused. HS ___ 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] plugin dependencies and TARGET_LINK_LIBRARIES()
Am Dienstag 15 Juni 2010, 18:48:04 schrieb Kishore: > How do i inform cmake when building a module that it depends on another > module? Does cmake need to even know that? > > I am building a plugin based qt application (my first time with plugins) > and my situlation like with many other applications is that plugin A > depends on plugin B. In my application i take care to load plugin B before > A. However, loading plugin A fails complaining that it could not resolve > links which are in B. plugin B which only depends on the application loads > fine. > > Now, everything works fine if i declare that plugin A depends on B using > the TARGET_LINK_LIBRARIES() function. But for this to work, i have to > declare both A and B as SHARED instead of MODULE libraries. > > What is the right way to go? I believe that since my application loads B > before A, B should not fail to load and there really should be no need for > the TARGET_LINK_LIBRARIES() call. What about splitting the common part of B into a library that both B and A link to? HS ___ 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] plugin dependencies and TARGET_LINK_LIBRARIES()
On 15.06.10 22:18:04, Kishore wrote: > How do i inform cmake when building a module that it depends on another > module? Does cmake need to even know that? > > I am building a plugin based qt application (my first time with plugins) and > my > situlation like with many other applications is that plugin A depends on > plugin B. In my application i take care to load plugin B before A. However, > loading plugin A fails complaining that it could not resolve links which are > in B. plugin B which only depends on the application loads fine. > > Now, everything works fine if i declare that plugin A depends on B using the > TARGET_LINK_LIBRARIES() function. But for this to work, i have to declare > both > A and B as SHARED instead of MODULE libraries. > > What is the right way to go? Thats not a real plugin system, plugins don't link against other plugins directly. Your options are: - extract the code from B that you need in A into the shared lib (that you should already have) that both A and B (and your application) link against - provide an interface header from B and a way in your app for a plugin to get a pointer to such an interface. Then provide the necessary api functions you need in A in that interface as pure virtual. That way A can use this virtual interface to get at the B functions without directly linking against it. Andreas -- You will be awarded a medal for disregarding safety in saving someone. ___ 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] Problems with linking on MinGW?
Am Dienstag 15 Juni 2010, 19:32:44 schrieb Hendrik Sattler: > You _really_ need to read about the proper library naming for your > compilers! That's why you got confused. To correct myself: actually the linkers, not the compilers (although they are always used as set). HS ___ 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] Converting a OpenCL program into a C++ header?
Hi,
We would like to convert an OpenCL program written in a separate file to a
C++ header (essentially a long string).
For example, if my OpenCL program is in the file Square.cl
__kernel square(
__global float* input,
__global float* output,
const unsigned int count)
{
int i = get_global_id(0);
if(i < count)
output[i] = input[i] * input[i];
}
I¹d like to turn it into something like this in Square.h:
const char *KernelSource = "\n" \
"__kernel square( \n"
\
" __global float* input, \n"
\
" __global float* output, \n"
\
" const unsigned int count) \n"
\
"{ \n"
\
" int i = get_global_id(0); \n"
\
" if(i < count) \n"
\
" output[i] = input[i] * input[i];\n"
\
"} \n"
\
"\n";
So that my OpenCL code can be directly compiled into my executable. This is
also useful for OpenGL shaders.
The question: is this something that CMake could do? If so, any examples
where to begin looking?
Thanks,
-dan
--
Daniel Blezek, PhD
Medical Imaging Informatics Innovation Center
P 127 or (77) 8 8886
T 507 538 8886
E blezek.dan...@mayo.edu
Mayo Clinic
200 First St. S.W.
Harwick SL-44
Rochester, MN 55905
mayoclinic.org
___
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] Converting a OpenCL program into a C++ header?
On Tue, Jun 15, 2010 at 5:13 PM, Daniel Blezek wrote:
> Hi,
>
> We would like to convert an OpenCL program written in a separate file to
> a C++ header (essentially a long string).
>
> For example, if my OpenCL program is in the file Square.cl
>
> __kernel square(
>__global float* input,
>__global float* output,
>const unsigned int count)
> {
>int i = get_global_id(0);
>if(i < count)
>output[i] = input[i] * input[i];
> }
>
> I’d like to turn it into something like this in Square.h:
>
> const char *KernelSource = "\n" \
> "__kernel square( \n"
> \
> " __global float* input, \n"
> \
> " __global float* output, \n"
> \
> " const unsigned int count) \n"
> \
> "{ \n"
> \
> " int i = get_global_id(0); \n"
> \
> " if(i < count) \n"
> \
> " output[i] = input[i] * input[i];\n"
> \
> "} \n"
> \
> "\n";
>
> So that my OpenCL code can be directly compiled into my executable. This
> is also useful for OpenGL shaders.
>
> The question: is this something that CMake could do? If so, any examples
> where to begin looking?
>
It is. CMake can definitely do that. I know I've written code like this
somewhere... I have to dash off at the moment, but when I get back to a
computer, I'll see if I can look it up and pass along a function that does
something similar.
Unless somebody else beats me to it. :-)
- 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] Converting a OpenCL program into a C++ header?
Am 15.06.2010 23:13, schrieb Daniel Blezek:
Hi,
We would like to convert an OpenCL program written in a separate
file to a C++ header (essentially a long string).
For example, if my OpenCL program is in the file Square.cl
__kernel square(
__global float* input,
__global float* output,
const unsigned int count)
{
int i = get_global_id(0);
if(i < count)
output[i] = input[i] * input[i];
}
I'd like to turn it into something like this in Square.h:
const char *KernelSource = "\n" \
"__kernel square(
\n" \
" __global float* input,
\n" \
" __global float* output,
\n" \
" const unsigned int count)
\n" \
"{
\n" \
" int i = get_global_id(0);
\n" \
" if(i < count)
\n" \
" output[i] = input[i] * input[i];
\n" \
"}
\n" \
"\n";
So that my OpenCL code can be directly compiled into my executable.
This is also useful for OpenGL shaders.
The question: is this something that CMake could do? If so, any
examples where to begin looking?
You could write a little application that reads in the source file and
generates the header file just as in your example. Then you could use
CMake to execute that application e.g. using add_custom_command() before
building your executables that include the generated header files. You
could even build the tool itself as a dependency first.
Hope that helps...
Stefan
___
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] Converting a OpenCL program into a C++ header?
Hi Stefan,
Yes, I¹ve done this sort of thing with Lua (which is built as part of our
code), but I¹d prefer to do this with CMake to avoid the extra headache of
maintaining my code. I suspect it¹s just a few lines (but knowing the right
few lines is the key).
Thanks,
-dan
On 6/15/10 4:33 PM, "Stefan Buschmann" wrote:
> Am 15.06.2010 23:13, schrieb Daniel Blezek:
>> Converting a OpenCL program into a C++ header? Hi,
>>
>> We would like to convert an OpenCL program written in a separate file to a
>> C++ header (essentially a long string).
>>
>> For example, if my OpenCL program is in the file Square.cl
>>
>> __kernel square(
>>__global float* input,
>>__global float* output,
>>const unsigned int count)
>> {
>>int i = get_global_id(0);
>>if(i < count)
>>output[i] = input[i] * input[i];
>> }
>>
>> I¹d like to turn it into something like this in Square.h:
>>
>> const char *KernelSource = "\n" \
>> "__kernel square( \n" \
>> " __global float* input, \n" \
>> " __global float* output, \n" \
>> " const unsigned int count) \n" \
>> "{ \n" \
>> " int i = get_global_id(0); \n" \
>> " if(i < count) \n" \
>> " output[i] = input[i] * input[i];\n" \
>> "} \n" \
>> "\n";
>>
>> So that my OpenCL code can be directly compiled into my executable. This is
>> also useful for OpenGL shaders.
>>
>> The question: is this something that CMake could do? If so, any examples
>> where to begin looking?
>>
> You could write a little application that reads in the source file and
> generates the header file just as in your example. Then you could use CMake to
> execute that application e.g. using add_custom_command() before building your
> executables that include the generated header files. You could even build the
> tool itself as a dependency first.
>
> Hope that helps...
>
> Stefan
>
>
>
> ___
> 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
--
Daniel Blezek, PhD
Medical Imaging Informatics Innovation Center
P 127 or (77) 8 8886
T 507 538 8886
E blezek.dan...@mayo.edu
Mayo Clinic
200 First St. S.W.
Harwick SL-44
Rochester, MN 55905
mayoclinic.org
___
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] NCurses issues with OS X 10.6.3 and ccmake
Just FYI that Apple released the OS X 10.6.4 update today that among other things _should_ have fixed the messed up ncurses library that stopped the arrow keys from working with ccmake. As usual use the usual update mechanisms that Apple provides. If anyone _does_ update could you post back to the list to verify that the curses problem is either fixed or still remains broken. Thanks ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio ___ 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] Reusing an already built object
On 06/13/2010 10:08 PM, Linghua Tseng wrote:
> On 06/12/2010 23:30:50 Michael Hertling wrote:
>> On 06/12/2010 04:10 AM, Linghua Tseng wrote:
>>> ...
>> Look at the following CMakeLists.txt:
>>
>> project(main)
>> cmake_minimum_required(VERSION 2.8)
>>
>> add_library(gen1 STATIC src1.c)
>> set(gen_src2_SRCS gen_src2.c)
>> add_executable(gen_src2 ${gen_src2_SRCS})
>> target_link_libraries(gen_src2 gen1)
>> get_target_property(gen_src2_EXE gen_src2 LOCATION)
>> add_custom_command(
>>OUTPUT src2.c
>>COMMAND ${gen_src2_EXE}
>>ARGS > src2.c
>>DEPENDS gen_src2
>> )
>>
>> add_library(gen2 STATIC ${PROJECT_BINARY_DIR}/src2.c)
>> set(gen_src3_SRCS gen_src3.c)
>> add_executable(gen_src3 ${gen_src3_SRCS})
>> target_link_libraries(gen_src3 gen2 gen1)
>> get_target_property(gen_src3_EXE gen_src3 LOCATION)
>> add_custom_command(
>>OUTPUT src3.c
>>COMMAND ${gen_src3_EXE}
>>ARGS > src3.c
>>DEPENDS gen_src3
>> )
>>
>> add_library(gen3 STATIC ${PROJECT_BINARY_DIR}/src3.c)
>> set(gen_src4_SRCS gen_src4.c)
>> add_executable(gen_src4 ${gen_src4_SRCS})
>> target_link_libraries(gen_src4 gen3 gen2 gen1)
>> get_target_property(gen_src4_EXE gen_src4 LOCATION)
>> add_custom_command(
>>OUTPUT src4.c
>>COMMAND ${gen_src4_EXE}
>>ARGS > src4.c
>>DEPENDS gen_src4
>> )
>>
>> set(mylib_SRCS src1.c
>> ${PROJECT_BINARY_DIR}/src2.c
>> ${PROJECT_BINARY_DIR}/src3.c
>> ${PROJECT_BINARY_DIR}/src4.c
>> )
>> add_library(mylib ${mylib_SRCS})
>>
>> After cmaking, a "make | grep Building" yields:
>>
>> [ 6%] Building C object CMakeFiles/gen1.dir/src1.c.o
>> [ 13%] Building C object CMakeFiles/gen_src2.dir/gen_src2.c.o
>> [ 26%] Building C object CMakeFiles/gen2.dir/src2.c.o
>> [ 33%] Building C object CMakeFiles/gen_src3.dir/gen_src3.c.o
>> [ 46%] Building C object CMakeFiles/gen3.dir/src3.c.o
>> [ 53%] Building C object CMakeFiles/gen_src4.dir/gen_src4.c.o
>> [ 66%] Building C object CMakeFiles/mylib.dir/src1.c.o
>> [ 73%] Building C object CMakeFiles/mylib.dir/src2.c.o
>> [ 80%] Building C object CMakeFiles/mylib.dir/src3.c.o
>> [ 86%] Building C object CMakeFiles/mylib.dir/src4.c.o
>>
>> Thus, the sources whose object files will be incorporated in the
>> executables as well as in your library are compiled just twice, and this
>> is unavoidable, or at least shouldn't be bypassed, as AN has pointed out.
>
> I knew this approach, and I also found that I can write this line in the end
> of CMakeLists.txt:
> add_library(mylib gen4 gen3 gen2 gen1)
> instead of re-listing sources.
> (Assume that you wrote: add_library(gen4 STATIC ...) before)
This won't work as desired since gen{4,3,2,1} aren't source files; in
fact, it will result in the same "Cannot find source file" errors you
mention in your later example. Nevertheless, there're chances that it
maliciously pretends to work, see below.
> Now I modified something in order to explain the next issue:
> project(main)
> cmake_minimum_required(VERSION 2.8)
>
> add_library(src1 STATIC src1.c)
> set(lower_layer_lib_LIBRARIES src1)
>
> set(gen_src2_SRCS gen_src2.c)
> add_executable(gen_src2 ${gen_src2_SRCS})
> target_link_libraries(gen_src2 src1)
> get_target_property(gen_src2_EXE gen_src2 LOCATION)
> add_custom_command(
> OUTPUT src2.c
> COMMAND ${gen_src2_EXE}
> ARGS > src2.c
> DEPENDS gen_src2
> )
BTW, you don't need to bother with the LOCATION target property here;
ADD_CUSTOM_COMMAND() is smart enough to figure out the executable by
itself.
> add_library(src2 STATIC src2.c)
> set(lower_layer_lib_LIBRARIES src2 ${lower_layer_lib_LIBRARIES})
>
> set(gen_src3_SRCS gen_src3.c)
> add_executable(gen_src3 ${gen_src3_SRCS})
> target_link_libraries(gen_src3 src2 src1)
> get_target_property(gen_src3_EXE gen_src3 LOCATION)
> add_custom_command(
> OUTPUT src3.c
> COMMAND ${gen_src3_EXE}
> ARGS > src3.c
> DEPENDS gen_src3
> )
> add_library(src3 STATIC src3.c)
> set(lower_layer_lib_LIBRARIES src3 ${lower_layer_lib_LIBRARIES})
>
> set(gen_src4_SRCS gen_src4.c)
> add_executable(gen_src4 ${gen_src4_SRCS})
> target_link_libraries(gen_src4 src3 src2 src1)
> get_target_property(gen_src4_EXE gen_src4 LOCATION)
> add_custom_command(
> OUTPUT src4.c
> COMMAND ${gen_src4_EXE}
> ARGS > src4.c
> DEPENDS gen_src4
> )
> add_library(src4 STATIC src4.c)
> set(lower_layer_lib_LIBRARIES src4 ${lower_layer_lib_LIBRARIES})
>
> # Yes, it works.
> add_library(lower_layer_lib ${lower_layer_lib_LIBRARIES})
This line expands to add_library(lower_layer_lib src4 src3 src2 src1),
and since you have src{4,3,2,1}.c available from the custom commands -
you're doing an in-source-build, I suppose - CMake takes them as the
sources for lower_layer_lib. Rename the libraries from srcN to genN
like in the previous example, and you'll probably see that it's not
working anymore. Subsequently, do a "touch gen{4,3,2,1
Re: [CMake] Problems with linking on MinGW?
On Tue, Jun 15, 2010 at 7:54 AM, Jesse Perla wrote:
> I am using CMake 2.8.1 on Windows 7. I have MinGW installed with GCC 4.5
> I have successfully compiled a library with a MinGW and cmake. The full
> path to the library is: c:\working\etk_binaries\libetk-mgw45.a
> However, when I want to link this file into an executable (no need to have
> the CMake dependencies, etc. in projects) it can't seem to find this file.
> My cmakelists.txt is:
> cmake_minimum_required(VERSION 2.6)
> set(PROJECT_NAME "test" )
> set(SRCS test.cpp )
> project(${PROJECT_NAME})
> add_executable(${PROJECT_NAME} ${SRCS})
> link_directories( "c:/working/etk_binaries")
> target_link_libraries(${PROJECT_NAME} libetk-mgw45)
>
PROJECT_NAME is actually a variable that gets set with project... so
this is a bit simpler...
PROJECT( "test" )
set(SRCS test.cpp )
add_executable(${PROJECT_NAME} ${SRCS})
..
> The error I get is:
> c:\MinGW\bin/ld.exe: cannot find -llibetk-mgw45
> collect2: ld returned 1 exit status
> mingw32-make[2]: *** [test.exe] Error 1
> mingw32-make[1]: *** [CMakeFiles/test.dir/all] Error 2
>
> Any ideas on what I have done wrong?
> Thanks,
> Jesse
> ___
> 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] Converting a OpenCL program into a C++ header?
This script will work for your simple input. It will require extra escaping
work if you need to embed double quotes or backslashes. And I do not claim
it is correct for all arbitrary input. But it's a starting point, in the
CMake language. Let me know if it gives you any troubles.
set(input_file "square.cl")
set(output_file "square.h")
# Read the whole input file:
#
file(READ "${input_file}" contents)
# Split it into lines:
#(insert line-ending 'E' chars to allow lines to be blank or end with
# semi-colons but still be iterate-able via CMake foreach...)
#
string(REGEX REPLACE ";" ";" contents "${contents}")
string(REGEX REPLACE "\n" "E;" contents "${contents}")
# Open output file:
#
file(WRITE "${output_file}"
"const char *KernelSource =\n")
# Send each line to output file:
#
foreach(lineE ${contents})
# Get rid of the trailing 'E':
#
string(REGEX REPLACE "^(.*)E$" "\\1" line "${lineE}")
file(APPEND "${output_file}"
" \"${line}\"\n")
endforeach()
# Close output file:
#
file(APPEND "${output_file}"
";\n")
Cheers,
David
On Tue, Jun 15, 2010 at 5:24 PM, David Cole wrote:
> On Tue, Jun 15, 2010 at 5:13 PM, Daniel Blezek wrote:
>
>> Hi,
>>
>> We would like to convert an OpenCL program written in a separate file to
>> a C++ header (essentially a long string).
>>
>> For example, if my OpenCL program is in the file Square.cl
>>
>> __kernel square(
>>__global float* input,
>>__global float* output,
>>const unsigned int count)
>> {
>>int i = get_global_id(0);
>>if(i < count)
>>output[i] = input[i] * input[i];
>> }
>>
>> I’d like to turn it into something like this in Square.h:
>>
>> const char *KernelSource = "\n" \
>> "__kernel square(
>> \n" \
>> " __global float* input,
>> \n" \
>> " __global float* output,
>> \n" \
>> " const unsigned int count)
>> \n" \
>> "{
>> \n" \
>> " int i = get_global_id(0);
>> \n" \
>> " if(i < count)
>> \n" \
>> " output[i] = input[i] * input[i];
>>\n" \
>> "}
>> \n" \
>> "\n";
>>
>> So that my OpenCL code can be directly compiled into my executable. This
>> is also useful for OpenGL shaders.
>>
>> The question: is this something that CMake could do? If so, any examples
>> where to begin looking?
>>
>
>
> It is. CMake can definitely do that. I know I've written code like this
> somewhere... I have to dash off at the moment, but when I get back to a
> computer, I'll see if I can look it up and pass along a function that does
> something similar.
>
> Unless somebody else beats me to it. :-)
>
> - 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] Combining projects made by several CMake solutions into 1 solution
Hi, I'm currently using some projects that solutions are built from CMake. They are Delta 3D, Open Scene Graph, osgOcean, and dtOcean. So what I wanted is to combine a few of those projects into one solution so I don't have to make them separately and for better organization. I know that I also must include the ALL_BUILD and ZERO_CHECK projects so that the IDE won't have to rebuild the projects all the time. But can one ZERO_CHECK work for projects from different solutions? BTW, my IDE is Visual C++ 2005. Thanks in advance. Fare thee well, Bawenang R. P. P. "127.0.0.1 sweet 127.0.0.1. There's no place like 127.0.0.1." -- http://www.its.ac.id ___ 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] plugin dependencies and TARGET_LINK_LIBRARIES()
On Tuesday 15 Jun 2010 11:32:17 pm Andreas Pakulat wrote: > On 15.06.10 22:18:04, Kishore wrote: > > How do i inform cmake when building a module that it depends on another > > module? Does cmake need to even know that? > > > > I am building a plugin based qt application (my first time with plugins) > > and my situlation like with many other applications is that plugin A > > depends on plugin B. In my application i take care to load plugin B > > before A. However, loading plugin A fails complaining that it could not > > resolve links which are in B. plugin B which only depends on the > > application loads fine. > > > > Now, everything works fine if i declare that plugin A depends on B using > > the TARGET_LINK_LIBRARIES() function. But for this to work, i have to > > declare both A and B as SHARED instead of MODULE libraries. > > > > What is the right way to go? > > Thats not a real plugin system, plugins don't link against other plugins > directly. Your options are: > > - extract the code from B that you need in A into the shared lib (that > you should already have) that both A and B (and your application) link > against This i could do... > - provide an interface header from B and a way in your app for a plugin > to get a pointer to such an interface. Then provide the necessary api > functions you need in A in that interface as pure virtual. That way A > can use this virtual interface to get at the B functions without > directly linking against it. This I don't fully understand. If A depends in B which would mean that it extends functionality in B, it would have to call some methods in B. No? In my implementation, I have a base class in B that has some pure virtual functions that are implemented by a class in A. On loading A it registers a factory object declaring availability of a certain functionality. The registration API resides in B. Apparently, I do not properly understand the concept of one plugin depending on another. -- Cheers! Kishore Ps: I initially thought this may have to do with cmake but it seems that this is more to do with general C++ and qt programming. If there is a more appropriate list for this please let me know. ___ 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 2.8.2 RC1 <-> Visual Studio Express
There still some problems with the Express version of VS I started the gui-version of CMake and generated the solution files (empty build directory). No errors. First run in the IDE generates a lot of CMake errors (see appendix). Another hit on the F7 key: Most errors are gone. Okay, I can live with this, others may be not. A bad point is what happens, if there is change in the script files. - the IDE saves all files (ok) - CMake starts (ok) - the compiler/linker starts and works with the old solution files - the new generated solution files are loaded in the IDE (too late). The problems with the filter-files are gone, very good, but there are still the problems with the reloading of solution files if they are not changed. I know this is an old problem, but it still exists. Greetings Micha FirstIdeRun.pdf Description: Adobe PDF document ___ 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
