Re: [CMake] Watcom Support
J Decker wrote: I see the reference to setting verbose there, but I don't know what else I would edit there. ... enabling the verbosity early doesn't help. CMAKELinking C shared library sack_bag.dll /* how do I get this command? what follows is the output from wlink, but no command line ... same thing when I enable RC compiler, I don't get to see the command line...*/ Open Watcom Linker Version 1.8 Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved. Source code is available under the Sybase Open Watcom Public License. See http://www.openwatcom.org/ for details. loading object files searching libraries creating a Windows NT dynamic link library CMAKE[ 89%] Built target sack_bag If you edit that spot, and do make VERBOSE=1 then you should see what you want. -Bill ___ 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] Watcom Support
J Decker wrote: Is there CMAKE_C_FLAGS_EXE_INIT and CMAKE_C_FLAGS_SHARED_INIT ? I also just tried exporting the blow mentioned values on 2.8.1-RC4, with the same result. You are clearing the CMakeCache.txt file each time you change the _INIT values right? The other thing you can try is editing the variables in the CMakeCache.txt directly until you get it working. Then change the _INIT variables. -Bill ___ 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] Watcom Support
On Sat, Mar 6, 2010 at 6:22 AM, Bill Hoffman bill.hoff...@kitware.com wrote: J Decker wrote: Is there CMAKE_C_FLAGS_EXE_INIT and CMAKE_C_FLAGS_SHARED_INIT ? I also just tried exporting the blow mentioned values on 2.8.1-RC4, with the same result. You are clearing the CMakeCache.txt file each time you change the _INIT values right? The other thing you can try is editing the variables in the CMakeCache.txt directly until you get it working. Then change the _INIT variables. Yes, I'm even deleting everything to double make sure - twice. the linker optoins just aren't showing up. -Bill ___ 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 interview for FLOSS Weekly in about 1 hour
Bill Hoffman wrote: Matt Williams wrote: On 4 March 2010 14:04, Michael Jackson mike.jack...@bluequartz.net wrote: Is there an archive of the interview? I'm guessing it will appear at http://twit.tv/FLOSS Yup, it should be 111, which is not up yet. -Bill So, the pod cast show (FLOSS Weekly) that some of you watched the making of live video on Wednesday, is now complete. It is show 111, and can be found here: http://twit.tv/floss111 -Bill ___ 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] Watcom Support
Simple CMakeLists.txt, creates some source, links a library and a executable.
Attatched 'cmake -G Watcom WMake ..' command line output in an empty
./build direcotry
attached 'wmake VERBOSE=1' output.
have modified the end of Windows.cmake
# uncomment these out to debug nmake and borland makefiles
#SET(CMAKE_START_TEMP_FILE )
#SET(CMAKE_END_TEMP_FILE )
SET(CMAKE_VERBOSE_MAKEFILE 1)
SET(VERBOSE 1)
On Sat, Mar 6, 2010 at 6:21 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
J Decker wrote:
I see the reference to setting verbose there, but I don't know what
else I would edit there. ... enabling the verbosity early doesn't
help.
CMAKELinking C shared library sack_bag.dll
/* how do I get this command? what follows is the output from wlink,
but no command line ... same thing when I enable RC compiler, I don't
get to see the command line...*/
Open Watcom Linker Version 1.8
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a Windows NT dynamic link library
CMAKE[ 89%] Built target sack_bag
If you edit that spot, and do make VERBOSE=1 then you should see what you
want.
-Bill
cmake_minimum_required(VERSION 2.8)
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/main.c
COMMAND echo int main( void ){return 0\;}
${CMAKE_CURRENT_SOURCE_DIR}/main.c
)
add_library( main_lib ${CMAKE_CURRENT_SOURCE_DIR}/main.c )
add_executable( main_prog ${CMAKE_CURRENT_SOURCE_DIR}/main.c )
cmake-output.log
Description: Binary data
wmake-output.log
Description: Binary data
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MingW Update for resource compilation.
On Fri, Mar 5, 2010 at 10:20 PM, J Decker d3c...@gmail.com wrote: All of the examples indicating ENABLE_LANGUAGE(RC) have the compiler set afterwards, and it turns out that the following lines work much better... I Added these to WIndows-GNU.cmake SET(CMAKE_RC_COMPILER windres) SET(CMAKE_RC_COMPILE_OBJECT CMAKE_RC_COMPILER FLAGS DEFINES -O coff -o OBJECT SOURCE) ENABLE_LANGUAGE(RC) by specifying -O coff, it outputs .obj format file containing the resources, and the link works. This was working in my cygwin configurations also, but I can't test if resource compilation under cygwin would work well with these. only thing that's really wrong with this is that FLAGS is the full set of C definitions, and it may be different with more or less in reality. ___ 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.1 RC 4 is ready to try
Am Freitag, den 05.03.2010, 22:39 +0100 schrieb Eric Noulard: 2010/3/5 Bill Hoffman bill.hoff...@kitware.com: CMake 2.8.1 RC 4 is ready to try: http://www.cmake.org/files/v2.8/?C=M;O=D Please try your projects with it. If you find any issues, let me know. I think this is about it. So, if I don't hear anything by Monday, this is going to be 2.8.1. Not really a show-stopper since I have no problem using this RC but I do have a problem Building it on 2 linux boxes (first is Ubuntu 9.10 and the other is Fedora 11) using gcc 4.4.1: I can confirm this for Ubuntu 9.10. In the appendix is the generated output. Micha gildemeis...@ix4:~/temp/cmake-2.8.1-rc4$ ./bootstrap - , Copyright 2000-2009 Kitware, Inc. C compiler on this system is: cc C++ compiler on this system is: g++ Makefile processor on this system is: make g++ is GNU compiler g++ has STL in std:: namespace g++ has ANSI streams g++ has streams in std:: namespace g++ has sstream g++ has operator!=(string, char*) g++ has stl iterator_traits g++ has standard template allocator g++ has allocator::rebind g++ does not have non-standard allocator::max_size argument g++ has stl containers supporting allocator objects g++ has header cstddef g++ requires template friends to use g++ supports member templates g++ has standard template specialization syntax g++ has argument dependent lookup g++ has struct stat with st_mtim member g++ has ios::binary openmode g++ has ANSI for scoping - g++ -I/home/gildemeister/temp/cmake-2.8.1-rc4/Bootstrap.cmk -I/home/gildemeister/temp/cmake-2.8.1-rc4/Source -I/home/gildemeister/temp/cmake-2.8.1-rc4/Bootstrap.cmk -c /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.cxx -o cmake.o In file included from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmStandardIncludes.h:21, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmSystemTools.h:15, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.h:38, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.cxx:12: /home/gildemeister/temp/cmake-2.8.1-rc4/Bootstrap.cmk/cmConfigure.h:27:24: warning: missing terminating character /home/gildemeister/temp/cmake-2.8.1-rc4/Bootstrap.cmk/cmConfigure.h:29:1: warning: missing terminating character In file included from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmStandardIncludes.h:21, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmSystemTools.h:15, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.h:38, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.cxx:12: /home/gildemeister/temp/cmake-2.8.1-rc4/Bootstrap.cmk/cmConfigure.h:29: error: missing terminating character /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.cxx:891: error: missing terminating character /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.cxx:906: error: missing terminating character In file included from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmStandardIncludes.h:21, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmSystemTools.h:15, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.h:38, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.cxx:12: /home/gildemeister/temp/cmake-2.8.1-rc4/Bootstrap.cmk/cmConfigure.h:28: error: expected unqualified-id before numeric constant In file included from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmStandardIncludes.h:43, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmSystemTools.h:15, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.h:38, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.cxx:12: /usr/lib/gcc/i486-linux-gnu/4.4.1/include/stdarg.h:102: error: ‘__gnuc_va_list’ does not name a type In file included from /usr/include/c++/4.4/cwchar:47, from /usr/include/c++/4.4/bits/postypes.h:42, from /usr/include/c++/4.4/iosfwd:42, from /usr/include/c++/4.4/ios:39, from /usr/include/c++/4.4/istream:40, from /usr/include/c++/4.4/fstream:40, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmStandardIncludes.h:83, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmSystemTools.h:15, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.h:38, from /home/gildemeister/temp/cmake-2.8.1-rc4/Source/cmake.cxx:12: /usr/include/wchar.h:612: error: ‘__gnuc_va_list’ has not been declared /usr/include/wchar.h:619: error: ‘__gnuc_va_list’ has not been declared /usr/include/wchar.h:625: error: ‘__gnuc_va_list’ has not been declared /usr/include/wchar.h:689: error: ‘__gnuc_va_list’ has not been declared /usr/include/wchar.h:696: error:
Re: [CMake] CMake 2.8.1 RC 4 is ready to try
2010/3/6 Micha Renner micha.ren...@t-online.de: Am Freitag, den 05.03.2010, 22:39 +0100 schrieb Eric Noulard: 2010/3/5 Bill Hoffman bill.hoff...@kitware.com: CMake 2.8.1 RC 4 is ready to try: http://www.cmake.org/files/v2.8/?C=M;O=D Please try your projects with it. If you find any issues, let me know. I think this is about it. So, if I don't hear anything by Monday, this is going to be 2.8.1. Not really a show-stopper since I have no problem using this RC but I do have a problem Building it on 2 linux boxes (first is Ubuntu 9.10 and the other is Fedora 11) using gcc 4.4.1: I can confirm this for Ubuntu 9.10. In the appendix is the generated output. After investigating with Bill it looks like I can only reproduce the bug if I build CMake 2.8.1 RC 4 using CMake 2.6.4 ***GUI***. If I use command line only or if I use 2.8.1 to build 2.8.1 there is no problem. This looks like a bug in cmake-gui 2.6.4. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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] CMake 2.8.1 RC 4 is ready to try
2010/3/6 Eric Noulard eric.noul...@gmail.com: 2010/3/6 Micha Renner micha.ren...@t-online.de: Am Freitag, den 05.03.2010, 22:39 +0100 schrieb Eric Noulard: 2010/3/5 Bill Hoffman bill.hoff...@kitware.com: CMake 2.8.1 RC 4 is ready to try: http://www.cmake.org/files/v2.8/?C=M;O=D Please try your projects with it. If you find any issues, let me know. I think this is about it. So, if I don't hear anything by Monday, this is going to be 2.8.1. Not really a show-stopper since I have no problem using this RC but I do have a problem Building it on 2 linux boxes (first is Ubuntu 9.10 and the other is Fedora 11) using gcc 4.4.1: I can confirm this for Ubuntu 9.10. In the appendix is the generated output. Reading your output, your problem is not the same as mine. You did bootstrap when I was using cmake 2.6.4 to compile 2.8.1. After investigating with Bill it looks like I can only reproduce the bug if I build CMake 2.8.1 RC 4 using CMake 2.6.4 ***GUI***. If I use command line only or if I use 2.8.1 to build 2.8.1 there is no problem. This looks like a bug in cmake-gui 2.6.4. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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] OpenWatcom support
I would like to add something like this, so an option appears in the
gui I can select
set(CMAKE_WATCOM_WMAKE_TARGET_SYSTEM CACHE STRING
Set build type (blank is compiler-default))
set_property(CACHE CMAKE_WATCOM_WMAKE_TARGET_SYSTEM PROPERTY STRINGS
=NT =OS2 =DOS =QNX )
and then modify the flags to include the build target type... however,
when I change it in the gui, the changes aren't reflected in the new
flags...
SET (CMAKE_CXX_FLAGS_INIT -w=3 -xs
-bt${CMAKE_WATCOM_WMAKE_TARGET_SYSTEM} -zld)
SET (CMAKE_C_FLAGS_INIT -w=3 -bt${CMAKE_WATCOM_WMAKE_TARGET_SYSTEM} -zld)
how am I doing this wrong?
___
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.1 RC 4 is ready to try
On Fri, Mar 5, 2010 at 9:39 PM, Bill Hoffman bill.hoff...@kitware.com wrote: CMake 2.8.1 RC 4 is ready to try: http://www.cmake.org/files/v2.8/?C=M;O=D Please try your projects with it. If you find any issues, let me know. I think this is about it. So, if I don't hear anything by Monday, this is going to be 2.8.1. Not really an issue as such, but cmake-2.8.1-rc4.tar.gz contained the whole git repository, making it much larger than a normal source tarball. RC3 was 3.4M, RC4 was 26M. I assume that this wasn't intended, and that the final release download should not have .git in there. -- Richard ___ 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.1 RC 4 is ready to try
On 2010-03-06 17:02+0100 Eric Noulard wrote: 2010/3/6 Eric Noulard eric.noul...@gmail.com: Not really a show-stopper since I have no problem using this RC but I do have a problem Building it on 2 linux boxes (first is Ubuntu 9.10 and the other is Fedora 11) using gcc 4.4.1: I can confirm this for Ubuntu 9.10. In the appendix is the generated output. Reading your output, your problem is not the same as mine. You did bootstrap when I was using cmake 2.6.4 to compile 2.8.1. You should try to bootstrap out-of-source: cd /path/to/CMake cd .. mkdir build cd build ../CMake/bootstrap Just to add some more data and opinion to this thread, I always bootstrap in a clean source tree (freshly downloaded from kitware) out of inertia. That procedure is how I started to build CMake years ago, and it has always worked. In fact, that procedure worked just fine for cmake-2.8.1-rc3 on my Debian Lenny platform. So I suspect Micha Renner didn't have a clean bootstrap=source tree or some issue like that. If there is no easy clean-tree solution to the issue found by Micha, then one rather wild possibility is cmake bootstrap might make configuration assumptions that are not compatible with the newer version of g++ which I assume Micha has installed on his Ubuntu-9.10 platform. For what it is worth, my Debian Lenny g++ version is g++ (Debian 4.3.2-1.1) 4.3.2 Ubuntu-9.10 may have a legacy gcc package that Micha could install that provides something nearer this version of g++ if using either a clean source=bootstrap tree or a clean out-of-source bootstrap tree does not work. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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.1 RC 4 is ready to try
Am Samstag, den 06.03.2010, 17:02 +0100 schrieb Eric Noulard: 2010/3/6 Eric Noulard eric.noul...@gmail.com: Not really a show-stopper since I have no problem using this RC but I do have a problem Building it on 2 linux boxes (first is Ubuntu 9.10 and the other is Fedora 11) using gcc 4.4.1: I can confirm this for Ubuntu 9.10. In the appendix is the generated output. Reading your output, your problem is not the same as mine. Yes, what I wanted to say: I had a problem building CMake too. You did bootstrap when I was using cmake 2.6.4 to compile 2.8.1. You should try to bootstrap out-of-source: Of course, but I read autotools in the readMe.txt, so I forgot out-of-source. cd /path/to/CMake cd .. mkdir build cd build ../CMake/bootstrap In the directory CMake I did: ../bootstrap = Same result. 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] CMake 2.8.1 RC 4 is ready to try
Am Samstag, den 06.03.2010, 09:08 -0800 schrieb Alan W. Irwin: On 2010-03-06 17:02+0100 Eric Noulard wrote: 2010/3/6 Eric Noulard eric.noul...@gmail.com: Not really a show-stopper since I have no problem using this RC but I do have a problem Building it on 2 linux boxes (first is Ubuntu 9.10 and the other is Fedora 11) using gcc 4.4.1: I can confirm this for Ubuntu 9.10. In the appendix is the generated output. Reading your output, your problem is not the same as mine. You did bootstrap when I was using cmake 2.6.4 to compile 2.8.1. You should try to bootstrap out-of-source: cd /path/to/CMake cd .. mkdir build cd build ../CMake/bootstrap Just to add some more data and opinion to this thread, I always bootstrap in a clean source tree (freshly downloaded from kitware) out of inertia. That procedure is how I started to build CMake years ago, and it has always worked. In fact, that procedure worked just fine for cmake-2.8.1-rc3 on my Debian Lenny platform. So I suspect Micha Renner didn't have a clean bootstrap=source tree or some issue like that. No, it was clean. I downloaded the compressed file, unpacked, read readme.txt and started bootstrap. That's all. If there is no easy clean-tree solution to the issue found by Micha, then one rather wild possibility is cmake bootstrap might make configuration assumptions that are not compatible with the newer version of g++ which I assume Micha has installed on his Ubuntu-9.10 platform. For what it is worth, my Debian Lenny g++ version is g++ (Debian 4.3.2-1.1) 4.3.2 Ubuntu-9.10 may have a legacy gcc package that Micha could install that provides something nearer this version of g++ if using either a clean source=bootstrap tree or a clean out-of-source bootstrap tree does not work. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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] Best way to Generate String
aaron_wri...@selinc.com wrote:
Is this the best way to generate a comment bar, such as this:
or this:
or this:
IF(OUTPUT_FILE_EXT MATCHES ^\\.h|\\.cpp$)
SET(COMMENT_CHARACTER /)
ELSEIF(OUTPUT_FILE_EXT MATCHES ^\\.sql$)
SET(COMMENT_CHARACTER -)
ELSEIF(OUTPUT_FILE_EXT MATCHES ^\\.nsi|\\.nsh$)
SET(COMMENT_CHARACTER #)
ELSE()
MESSAGE(WARNING Unknown file type)
ENDIF()
STRING(RANDOM LENGTH 80 ALPHABET ${COMMENT_CHARACTER} COMMENT_BAR)
IMHO, it looks OK.
The only reason I ask is that is seems weird to use the STRING(RANDOM
function to get this done.
The RANDOM is just a generalized generator.
In your case, you specify one-character alphabet
and it is still a random string of values from one element interval.
I don't see anything strange here myself.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.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] CMake 2.8.1 RC 4 is ready to try
On Friday 05 March 2010, Bill Hoffman wrote:
CMake 2.8.1 RC 4 is ready to try:
http://www.cmake.org/files/v2.8/?C=M;O=D
Please try your projects with it. If you find any issues, let me know.
I think this is about it. So, if I don't hear anything by Monday, this
is going to be 2.8.1.
FindQt4.cmake seems to have a bug with OpenGl on Mac:
http://lists.kde.org/?l=kde-buildsystemm=126780519900727w=2
I'm attaching a patch which probably fixes it, but I'm still waiting for
confirmation that it really does.
Alex
Index: Qt4ConfigDependentSettings.cmake
===
--- Qt4ConfigDependentSettings.cmake (revision 1099551)
+++ Qt4ConfigDependentSettings.cmake (working copy)
@@ -77,7 +77,18 @@
# QtOpenGL dependencies
QT_QUERY_QMAKE(QMAKE_LIBS_OPENGL QMAKE_LIBS_OPENGL)
-SEPARATE_ARGUMENTS(QMAKE_LIBS_OPENGL)
+IF(Q_WS_MAC)
+# On the Mac OpenGL is probably frameworks and QMAKE_LIBS_OPENGL can be e.g. -framework OpenGL -framework AGL.
+# The separate_arguments() call in the other branch makes -framework;-OpenGL;-framework;-lAGL appear in the
+# linker command. So we need to protect the -framework foo as non-separatable strings.
+# We do this by replacing the space after -framework with an underscore, then calling separate_arguments(),
+# and then we replace the underscores again with spaces. So we get proper linker commands. Alex
+ STRING(REGEX REPLACE -framework + -framework_ QMAKE_LIBS_OPENGL ${QMAKE_LIBS_OPENGL})
+ SEPARATE_ARGUMENTS(QMAKE_LIBS_OPENGL)
+ STRING(REGEX REPLACE -framework_ -framework QMAKE_LIBS_OPENGL ${QMAKE_LIBS_OPENGL})
+ELSE(Q_WS_MAC)
+ SEPARATE_ARGUMENTS(QMAKE_LIBS_OPENGL)
+ENDIF(Q_WS_MAC)
SET (QT_QTOPENGL_LIB_DEPENDENCIES ${QT_QTOPENGL_LIB_DEPENDENCIES} ${QMAKE_LIBS_OPENGL})
___
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] Canonical use of FindPackageHandleStandardArgs
Ryan Pavlik wrote: I took a quick look at your MySQL script and can offer these suggestions: Ryan, Thank you very much for your valuable comments and I'm going to improve my scripts according them. - Be sure to set the plural versions of the variables (INCLUDE_DIRS, LIBRARIES) to include the dependencies (these should not be cached), and leave the singular version for just a single path/file (these should be cached, as by default Good point. I'll have to re-read the Modules/readme.txt guidelines In your emailed example: I presume the mylib in step 2 is different than the mylib in step 1 and 3/4, because otherwise you have an infinitely-recursive find script. Please clarify, preferably with an actual example. It's an interesting observation. I'm not If the lib in step 2 is a dependency, convention varies, but it seems prudent to me to always find dependencies quietly: this prevents them from showing up in lists from FeatureSummary, etc. Anything you require in that dependency package should be passed to your find_package_handle_standard_args call which will make the appropriate noises if it shouldn't be quiet and it can't be found. OK, I think I got the point. If you're not doing find scripts that depend on other find scripts, All the scripts I've written so far are standalone scripts. then look in the archives from a month or so ago: I posted some sample find scripts that are modern and clean in style. You mean the mailing list archives or a repository? You can also take a peek at everything except FindDirectShow.cmake (I didn't write that one or rewrite it beyond running my cleanup app on it, and it's sorely in need of work) here: http://github.com/rpavlik/vrpn/tree/master/vrpn/cmake/ Great, I'll check it. Hope this helps! Absolutely, it helps! I'm glad getting my scripts reviewed. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.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] CMake 2.8.1 RC 4 is ready to try
On 2010-03-06 18:21+0100 Micha Renner wrote: Am Samstag, den 06.03.2010, 09:08 -0800 schrieb Alan W. Irwin: Just to add some more data and opinion to this thread, I always bootstrap in a clean source tree (freshly downloaded from kitware) out of inertia. That procedure is how I started to build CMake years ago, and it has always worked. In fact, that procedure worked just fine for cmake-2.8.1-rc3 on my Debian Lenny platform. So I suspect Micha Renner didn't have a clean bootstrap=source tree or some issue like that. No, it was clean. I downloaded the compressed file, unpacked, read readme.txt and started bootstrap. That's all. Hi Micha: What specific URL did you download? My previous data was for 2.8.1-rc3. Just now I downloaded http://www.cmake.org/files/v2.8/cmake-2.8.1-rc4.tar.gz. Bootstrap in source tree (and subsequent build, install, and use of CMake-2.8.1-rc4) worked fine on Debian Lenny. Did you download some other file (perhaps one with Windows line endings)? If the file downloaded was actually cmake-2.8.1-rc4.tar.gz are you sure it was a clean download? (In the absence of a checksum or signature file, the only way you can assure a clean download is to download twice to two separate directories and then compare the two compressed tarballs with diff.) Normally, I don't download twice, but if I get peculiar errors that nobody else can reproduce (like it appears you have done), that's one of the first things I would try. I am pretty sure some simple issue like this is the answer, but if not, there is always extremely unlikely possibilities like the g++ version sensitivity issue I mentioned. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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] Decompressing a file with cmake
Hello, is it possible to uncompress a zip file with cmake? I use file(download...) to get a zip from an url, but I need to uncompress the downloaded archive... Nader ___ 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] This has to have been asked before...
I'm probably not using the right keywords on my search. I want to add a target (a gcc precompiled header) as a dependency for every target so it'll get compiled with the flags for that particular target, including altering the resulting file name. I did try looking at the precompiled header CMake include, but that just confused the bejeezus out of me, not helped by the fact that it didn't work :) - Oliver ___ 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] This has to have been asked before...
On 3/6/2010 6:39 PM, Oliver Smith wrote: I want to add a target (a gcc precompiled header) as a dependency for every target so it'll get compiled with the flags for that particular target, including altering the resulting file name. I should say: /automatically/ add... I don't want to add them by hand :) (Project has a lot of targets =/) - Oliver ___ 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_RC_FLAGS has no effect
Setting a value into the CMAKE_RC_FLAGS field in the CMakeCache.txt file has no effect. I am using the Visual Studio 2005 generator, although I have seen this also reported against VS2009. I am using cmake 2.8 (from source with the midl quoting patch applied) Instead of obeying _RC_FLAGS, any values set in CMAKE_CXX_FLAGS are passed to RC.EXE. This presents a problem when attempting to pass a string. The resource compiler requires the quotes around a string to be quoted, like this /D__USER__=\$(username)\ but passing this same string to the compiler causes it to choke. Conversely, excluding the backslash is valid for the compiler, /D__USER__=$(username) but causes the resource compiler to complain of unknown command. Is there a way to isolate arguments for the resource compiler only ? Many thanks /tony - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ 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] Watcom Support
Is there CMAKE_C_FLAGS_EXE_INIT and CMAKE_C_FLAGS_SHARED_INIT ? Sorta... apparently there is CMAKE_SHARED_LIBRARY_C_FLAGS but as far as I can tell CMAKE_EXECUTABLE_C_FLAGS doesn't exist or isn't ever used. Also under watcom, these options in windows-cl.cmake SET(CMAKE_CREATE_WIN32_EXE /subsystem:windows) SET(CMAKE_CREATE_CONSOLE_EXE /subsystem:console) are not passed to watcom linker. But then this leads me to say that really CMAKE_WIN32_C_FLAGS and CMAKE_CONSOLE_C_FLAGS are useful :) I also just tried exporting the blow mentioned values on 2.8.1-RC4, with the same result. (sory to branch conversation to 3 heads) On Fri, Mar 5, 2010 at 6:15 AM, Bill Hoffman bill.hoff...@kitware.com wrote: J Decker wrote: but then, for every project that already exists, it won't build correctly using watcom, because the options just aren't set in the generator, or 3 more flavors of generators aren't added to support static library, executlable and dynamic library with correct compile time options. It should go in Modules/Platform/Windows-wcl386.cmake. Just set these: CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT CMAKE_SHARED_LINKER_FLAGS_INIT CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT See Windows-cl.cmake for an example, you will also want to set RELWITHDEBINFO to have the same flag. If you can verify this works, I will merge into git master for CMake. -Bill ___ 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] FindHDF5.cmake improvement proposal
Hi Will,
Il giorno Tue, 02 Mar 2010 09:07:48 -0700
Will Dicharry wdicha...@stellarscience.com ha scritto:
Antonio Valentino wrote:
Hi list,
pasted below a snippet I use in a project of mine to handle HDF5
library.
The purpose is to improve detection of required library zlib and
szip in cases when the HDF5_C_COMPILER_EXECUTABLE is not available
e.g. when one try to use pre-build HDF5 libraries on win32.
The snippet also adds an option (WIN32 only) to set defines
required by HDF5 dlls. This part could be further automated with
some regexp (i suppose).
I'm not a cmake expert so I would like to receive some comment by
users more expert than me.
If the approach is correct I could try to submit a patch that
integrates the snippet in the FindHDF5.cmake module.
Hi Antonio,
I'm the maintainer of the FindHDF5 module, and I think your additions
would be useful when the wrapper compiler is not found (or if you
happen to be on Windows, as much of the command line stripping code
won't work there).
please find attached the modified version of FindHDF5.cmake that
includes:
* improved logic for detecting zlib and szib dependencies when the
wrapper compiler is not available
* code for setting windows specific defines for using DLLs when the
wrapper compiler is not available
* code for setting component specific libraries
(HDF5_${LANGUAGE}_LIBRARIES). The variable was always empty in the
previous version
Please note that the modified module depends on Michael
Jackson's FindSZIP.cmake module available at
http://gitorious.org/hdf5/hdf5-v18/blobs/master/Resources/CMake/FindSZIP.cmake
If you like I could file a new ticket on the bug tracker.
best regards
--
Antonio Valentino
# - Find HDF5, a library for reading and writing self describing array data.
#
# This module invokes the HDF5 wrapper compiler that should be installed
# alongside HDF5. Depending upon the HDF5 Configuration, the wrapper compiler
# is called either h5cc or h5pcc. If this succeeds, the module will then call
# the compiler with the -show argument to see what flags are used when compiling
# an HDF5 client application.
#
# The module will optionally accept the COMPONENTS argument. If no COMPONENTS
# are specified, then the find module will default to finding only the HDF5 C
# library. If one or more COMPONENTS are specified, the module will attempt to
# find the language bindings for the specified components. Currently, the only
# valid components are C and CXX. The module does not yet support finding the
# Fortran bindings. If the COMPONENTS argument is not given, the module will
# attempt to find only the C bindings.
#
# On UNIX systems, this module will read the variable HDF5_USE_STATIC_LIBRARIES
# to determine whether or not to prefer a static link to a dynamic link for HDF5
# and all of it's dependencies. To use this feature, make sure that the
# HDF5_USE_STATIC_LIBRARIES variable is set before the call to find_package.
#
# To provide the module with a hint about where to find your HDF5 installation,
# you can set the environment variable HDF5_ROOT. The Find module will then
# look in this path when searching for HDF5 executables, paths, and libraries.
#
# In addition to finding the includes and libraries required to compile an HDF5
# client application, this module also makes an effort to find tools that come
# with the HDF5 distribution that may be useful for regression testing.
#
# This module will define the following variables:
# HDF5_INCLUDE_DIR - Location of the hdf5 includes
# HDF5_DEFINITIONS - Required compiler definitions for HDF5
# HDF5_C_LIBRARIES - Required libraries for the HDF5 C bindings.
# HDF5_CXX_LIBRARIES - Required libraries for the HDF5 C++ bindings
# HDF5_LIBRARIES - Required libraries for all requested bindings
# HDF5_FOUND - true if HDF5 was found on the system
# HDF5_LIBRARY_DIRS - the full set of library directories
# HDF5_IS_PARALLEL - Whether or not HDF5 was found with parallel IO support
# HDF5_C_COMPILER_EXECUTABLE - the path to the HDF5 C wrapper compiler
# HDF5_CXX_COMPILER_EXECUTABLE - the path to the HDF5 C++ wrapper compiler
# HDF5_DIFF_EXECUTABLE - the path to the HDF5 dataset comparison tool
#=
# Copyright 2009 Kitware, Inc.
#
# Distributed under the OSI-approved BSD License (the License);
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#=
# (To distributed this file outside of CMake, substitute the full
# License text for the above reference.)
# This module is maintained by Will Dicharry wdicha...@stellarscience.com.
include(SelectLibraryConfigurations)
include(FindPackageHandleStandardArgs)
#
