Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
On Wednesday 22 June 2011, Brad King wrote: On 06/21/2011 03:25 PM, Alexander Neundorf wrote: Ok, I pushed the branch again. The new name looks better. Perhaps I missed this last time, but the documentation of the variable within the command is back up in the simple section. Yes, you did ;-) Actually I thought you were ok with it. Please put it at the very bottom of the entire documentation, just above the note about NO_POLICY_SCOPE. Done. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
On 06/23/2011 05:12 AM, Alexander Neundorf wrote: Please put it at the very bottom of the entire documentation, just above the note about NO_POLICY_SCOPE. Done. Thanks. The topic looks good. Please merge it to 'next' when you're ready. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
On Thursday 23 June 2011, Brad King wrote: On 06/23/2011 05:12 AM, Alexander Neundorf wrote: Please put it at the very bottom of the entire documentation, just above the note about NO_POLICY_SCOPE. Done. Thanks. The topic looks good. Please merge it to 'next' when you're ready. Won't this have the effect that it will be in 2.8.5 ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
On 06/23/2011 04:11 PM, Brad King wrote: On 06/23/2011 09:53 AM, Alexander Neundorf wrote: On Thursday 23 June 2011, Brad King wrote: On 06/23/2011 05:12 AM, Alexander Neundorf wrote: Please put it at the very bottom of the entire documentation, just above the note about NO_POLICY_SCOPE. Done. Thanks. The topic looks good. Please merge it to 'next' when you're ready. Won't this have the effect that it will be in 2.8.5 ? No. We manually select topics from 'next' and merge them to 'master'. Only topics in master will be released. http://www.cmake.org/Wiki/CMake/Git#Branches -Brad So, how does that work? Do you look for the merges in 'next' that you like, and then re-merge them to 'master' directly from the topic-branch? Something like this? -- A I -- master \ \ \/ \ \ C --- D -- G -- topic2 \ \ \ \ B -- D -- topic1 \ \\ \ \--- F H -- next i.e. everything starts at A, 'master' and 'next' being identical. Then, someone creates 'topic1' and merges it into 'next' (commit F). Meanwhile, another topic, 'topic2' is created, and also merged into 'next' (commit H). Now, 'topic1' just isn't ready, but 'topic2' is, so it gets merged into 'master' (commmit I). Is this correct? Is 'next' kind of your throw-away integration branch? Do you rebase it regularly onto master? Michael ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
On 06/23/2011 10:36 AM, Michael Wild wrote: On 06/23/2011 04:11 PM, Brad King wrote: We manually select topics from 'next' and merge them to 'master'. Only topics in master will be released. So, how does that work? Do you look for the merges in 'next' that you like, and then re-merge them to 'master' directly from the topic-branch? Yes. The complete workflow is described generically here: http://public.kitware.com/Wiki/Git/Workflow/Topic We use a topic stage repository to keep explicit topic branch heads that are not in all integration branches: http://public.kitware.com/Wiki/Git/Workflow/Stage CMake's topic stage is published here: http://cmake.org/stage/cmake.git The set of branches changes regularly as topics are added or finished. Something like this? -- A I -- master \ \ \/ \ \ C --- D -- G -- topic2 \ \ \ \ B -- D -- topic1 \ \\ \ \--- F H -- next Yes, exactly. i.e. everything starts at A, 'master' and 'next' being identical. Then, someone creates 'topic1' and merges it into 'next' (commit F). Meanwhile, another topic, 'topic2' is created, and also merged into 'next' (commit H). Now, 'topic1' just isn't ready, but 'topic2' is, so it gets merged into 'master' (commmit I). Is this correct? Yes. It gets a little more complicated when there are conflicts: http://public.kitware.com/Wiki/Git/Workflow/Topic/Conflicts Is 'next' kind of your throw-away integration branch? Yes. No topics are allowed to see any of the merges into next. There is even a check on the server that disallows topics (or master) to see the beginning of next. Do you rebase it regularly onto master? So far we haven't rewritten it but the workflow allows that because nothing should be based on it. Currently we have to avoid rewriting the branch because some dashboard clients may do just git pull to update. Recent CTest versions do a fetch reset so that they can handle upstream rewrites. I designed all of the above after reading about Git's own workflow: http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/maintain-git.txt;hb=v1.7.5 Our topic stage takes the place of the maintainer's private repository. I designed it to help distribute some of the maintainer's workload among developers (and they don't even have to know; it's just part of their workflow). -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0012301]: CMAKE_BUILD_TYPE not set on MinGW
On Thursday, June 23, 2011 10:45:25 am Alan W. Irwin wrote: On 2011-06-22 22:06-0600 Clinton Stimpson wrote: This issue is with how Qt plugins are compiled. It has come up a couple times in the past, but this might be the first with MinGW. When Qt is configured, a build key is generated that is configuration specific (see qconfig.h). On Windows, the build key for the debug and release libs are different (regardless of the compiler used -- although they may only need to really do it for MSVC because only it has separate debug and release runtimes). When a user creates a Qt plugin, that build key gets embedded into the plugin (see build key used in qplugin.h), so it can only be loaded with a compatible Qt build. On Windows, the correct debug or release build key needs to be used, and choosing the correct one is dependent on compiling with -DQT_NO_DEBUG or -DQT_DEBUG. If neither is defined, qglobal.h automatically sets QT_DEBUG, which means it is assuming a debug build, even if one links against the release Qt libs. I wonder if there is a way to patch Qt to make a better assumption. So anyway, Stephen was having this issue because the build type was not explicit and Qt assumed debug and CMake assumed Release (by choosing to link with the release Qt libs), and the plugin was compiled with the wrong build key, so it wouldn't load at runtime. CMake sets a build type by default for MSVC compilers, but not MinGW or MSYS. The bug report requests that a default build type be specified instead of left empty. Hi Clint: I looked further at what CMake does currently about this. Here are the files in the CMake-2.8.4 source tree that mention QT_NO_DEBUG or QT_DEBUG software@raven find cmake-2.8.4 -type f -print0 |\ xargs -0 egrep -l '(QT_DEBUG|QT_NO_DEBUG)' cmake-2.8.4/Docs/cmake.html cmake-2.8.4/Docs/cmake-modules.txt cmake-2.8.4/Docs/cmake-modules.html cmake-2.8.4/Docs/cmake.txt cmake-2.8.4/Docs/cmake-gui.docbook cmake-2.8.4/Docs/cmake-gui.1 cmake-2.8.4/Docs/cmake.docbook cmake-2.8.4/Docs/cmake-gui.txt cmake-2.8.4/Docs/cmakemodules.1 cmake-2.8.4/Docs/cmake.1 cmake-2.8.4/Docs/cmake-gui.html cmake-2.8.4/ChangeLog.txt cmake-2.8.4/Modules/UseQt4.cmake cmake-2.8.4/Modules/FindQt3.cmake cmake-2.8.4/Modules/FindQt4.cmake I presume all the Docs ones are generated from FindQt4.cmake and FindQt3.cmake documentation lines, and we can ignore the mention in ChangeLog.txt. That just leaves cmake-2.8.4/Modules/UseQt4.cmake cmake-2.8.4/Modules/FindQt3.cmake cmake-2.8.4/Modules/FindQt4.cmake I will concentrate on just the Qt4 case. FindQt4.cmake just documents QT_NO_DEBUG and QT_DEBUG but takes no action itself. That just leaves one file, UseQt4.cmake which has only the following lines concerning those variables. SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG QT_DEBUG) SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_RELEASE QT_NO_DEBUG) SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_RELWITHDEBINFO QT_NO_DEBUG) SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_MINSIZEREL QT_NO_DEBUG) Shouldn't the general (Qt4) fix for this bug be to add SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS QT_NO_DEBUG) to the above lines? That fix seems simpler and more flexible than forcing a default CMAKE_BUILD_TYPE for the MinGW case. Yeah, I came to the same conclusion and committed a fix. http://cmake.org/gitweb?p=cmake.git;a=commit;h=5a2b20 I also made note of that on the thread in the cmake list and in the bug report. I wonder if this will make it into 2.8.5? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0012301]: CMAKE_BUILD_TYPE not set on MinGW
On 2011-06-23 10:22-0600 Clinton Stimpson wrote: FYI, I realized a patch to UseQt4.cmake could fix this qt-plugin/no-build-type problem. See here: http://cmake.org/gitweb?p=cmake.git;a=commit;h=5a2b20 Maybe it'll make it in 2.8.5? Hi Clint: I am replying to your above off-list comment on the list for obvious reasons. I woke up this morning with a very similar idea which I posted to the list before looking at the above off-list note from you. I notice your patch puts BOOLEAN logic protection around the statement I suggested, e.g., +IF(NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE) + SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS QT_NO_DEBUG) +ENDIF() I don't understand why that protection is necessary, but you understand CMake better than I do so I assume you are right. I have high hopes your minimal patch will get into 2.8.5 since it appears to solve many Qt4/MinGW problems. 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0012301]: CMAKE_BUILD_TYPE not set on MinGW
On Thursday, June 23, 2011 11:10:24 am Alan W. Irwin wrote: On 2011-06-23 10:22-0600 Clinton Stimpson wrote: FYI, I realized a patch to UseQt4.cmake could fix this qt-plugin/no-build-type problem. See here: http://cmake.org/gitweb?p=cmake.git;a=commit;h=5a2b20 Maybe it'll make it in 2.8.5? Hi Clint: I am replying to your above off-list comment on the list for obvious reasons. I woke up this morning with a very similar idea which I posted to the list before looking at the above off-list note from you. I notice your patch puts BOOLEAN logic protection around the statement I suggested, e.g., +IF(NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE) + SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS QT_NO_DEBUG) +ENDIF() I don't understand why that protection is necessary, but you understand CMake better than I do so I assume you are right. Because COMPILE_DEFINTIONS applies to all build types, and we want to avoid defining both QT_NO_DEBUG and QT_DEBUG. I have high hopes your minimal patch will get into 2.8.5 since it appears to solve many Qt4/MinGW problems. Yeah, it appears we're seeing more and more Qt/MinGW developers over time. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] determine 32 vs 64 bit linux
Am Mittwoch, 22. Juni 2011, 17:33:01 schrieb Karl Merkley: I need to install a library into a directory whose name depends on the machine type. For example if (WIN32) if (CMAKE_CL_64) set(ARCH_DIR win32) else() set(ARCH_DIR win64) endif() I'm not sure if that works for Visual Studio generators. Eike signature.asc Description: This is a digitally signed message part. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to deliver a source code package?
CMake suppose you have CMake. OK. Send us your CMakeLists.txt, there is something odd here. I tried on another machine (Red Hat Linux) with a newer version of CMake (2.8.4), but I get the same results. This is what I did: I downloaded Step6.tar.gz from http://public.kitware.com/cgi-bin/viewcvs.cgi/Tests/Tutorial/Step6/?root=CMake Then: $ tar xzvf Step6.tar.gz Step6/ Step6/CMakeLists.txt Step6/License.txt Step6/TutorialConfig.h.in Step6/tutorial.cxx Step6/MathFunctions/ Step6/MathFunctions/CMakeLists.txt Step6/MathFunctions/MakeTable.cxx Step6/MathFunctions/MathFunctions.h Step6/MathFunctions/mysqrt.cxx $ mkdir Step6.build $ cd Step6.build $ cmake ../Step6 $ cpack -C CPackSourceConfig.cmake $ tar xzvf Tutorial-1.0.1-Linux.tar.gz Tutorial-1.0.1-Linux/bin/Tutorial Tutorial-1.0.1-Linux/bin/libMathFunctions.a Tutorial-1.0.1-Linux/include/TutorialConfig.h Tutorial-1.0.1-Linux/include/MathFunctions.h What happen if you do: $ make package_source $ cd .. $ rm -fr Step6 $ rm -fr Step6.build $ tar xzvf Step6.tar.gz Step6/ Step6/CMakeLists.txt Step6/License.txt Step6/TutorialConfig.h.in Step6/tutorial.cxx Step6/MathFunctions/ Step6/MathFunctions/CMakeLists.txt Step6/MathFunctions/MakeTable.cxx Step6/MathFunctions/MathFunctions.h Step6/MathFunctions/mysqrt.cxx $ mkdir Step6.build $ cd Step6.build $ cmake ../Step6 $ make package_source $ tar xzvf Tutorial-1.0.1-Source.tar.gz Tutorial-1.0.1-Source/CMakeLists.txt Tutorial-1.0.1-Source/License.txt Tutorial-1.0.1-Source/TutorialConfig.h.in Tutorial-1.0.1-Source/tutorial.cxx Tutorial-1.0.1-Source/MathFunctions/CMakeLists.txt Tutorial-1.0.1-Source/MathFunctions/MakeTable.cxx Tutorial-1.0.1-Source/MathFunctions/MathFunctions.h Tutorial-1.0.1-Source/MathFunctions/mysqrt.cxx This looks better. Thanks! -- 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
Re: [CMake] determine 32 vs 64 bit linux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/23/2011 03:31 AM, Jean-Christophe Fillion-Robin wrote:
Hi Karl,
You could do so something like that:
set(bitness 32)
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
set(bitness 64)
endif()
The following macro provides a more complete example...
http://viewvc.slicer.org/viewvc.cgi/Slicer4/trunk/CMake/SlicerMacroGetPlatformArchitectureBitness.cmake?view=markup
I think the problem is more complicated than that. The proper directory
differs from one distrib to the other (eg debian and fedora at least
with some not that old versions).
Cmake knows the proper place to look for libraries, but does not
publicize it enough. Personally I do:
# Offer the user the choice of overriding the installation directories
get_property(LIB64 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS)
if (${LIB64} STREQUAL TRUE)
set(LIBSUFFIX 64)
else()
set(LIBSUFFIX )
endif()
set(INSTALL_LIB_DIR lib${LIBSUFFIX}/Odyssee++ CACHE PATH
Installation directory for libraries)
which as far as I can tell selects the proper lib dir for linux.
Theo.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4C5kYACgkQEr8WrU8nPV3yOACdF62q0MGKlBF2279TDreBxAEn
xnMAn0Xu1/o2N5KQUURuIK0JfgiiAj6U
=ghqB
-END PGP SIGNATURE-
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CDash broken after production mode is set to true
Hi I was all set up with my cdash server, after setting production mode to true, things stop working. Clients when they attempt to receive their id when they submit to cdash server get some junk as answer, they don't list up the schedule build thing. Fonts change, menus won't work. For instance, the Administration menu, when i look at a dashboard. Any ideas? -mika___ 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] Invitation to connect on LinkedIn
LinkedIn Weiyu Yi requested to add you as a connection on LinkedIn: -- Robert, I'd like to add you to my professional network on LinkedIn. - Weiyu Accept invitation from Weiyu Yi http://www.linkedin.com/e/-nf7vxk-gp9ge0e4-3/ucd2OXGR4jr_IQjfrDqica5hdW/blk/I1455681267_3/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYPnPsScz4UdzkRd359bORqozlplSZMbPwTdPgNc3cNcPcLrCBxbOYWrSlI/EML_comm_afe/ View invitation from Weiyu Yi http://www.linkedin.com/e/-nf7vxk-gp9ge0e4-3/ucd2OXGR4jr_IQjfrDqica5hdW/blk/I1455681267_3/3dvdPoOcjwSdjkQckALqnpPbOYWrSlI/svi/ -- DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/-nf7vxk-gp9ge0e4-3/abq/inv-24/ -- (c) 2011, LinkedIn Corporation___ 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] Invitation to connect on LinkedIn
LinkedIn Weiyu Yi requested to add you as a connection on LinkedIn: -- Robert, I'd like to add you to my professional network on LinkedIn. - Weiyu Accept invitation from Weiyu Yi http://www.linkedin.com/e/-nf7vxk-gp9gkfw5-1q/ucd2OXGR4jr_IQjfrDqica5hdW/blk/I1455693240_3/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYPnP0QczcVdzkRd359bORqozlplSZMbPwTdPgNc3cNcPcLrCBxbOYWrSlI/EML_comm_afe/ View invitation from Weiyu Yi http://www.linkedin.com/e/-nf7vxk-gp9gkfw5-1q/ucd2OXGR4jr_IQjfrDqica5hdW/blk/I1455693240_3/3dvc3gOcPASdjkQckALqnpPbOYWrSlI/svi/ -- DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/-nf7vxk-gp9gkfw5-1q/abq/inv-24/ -- (c) 2011, LinkedIn Corporation___ 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] CDash broken after production mode is set to true
- Forwarded by Mika Rajala/PATRIA on 23.06.2011 12:42 - From: Mika Rajala/PATRIA To: mika.raj...@patria.fi Date: 23.06.2011 12:42 Subject:Re: [CMake] CDash broken after production mode is set to true Hi I tried installing a different browser and, with that, it seems to work. However, the fonts are still different from what they were before, so something has changed. I have some screenshots so it's easy to verify this. What i still don't understand, is what happened to the client subscription. For SiteId, after a seemingly successful submission, It gets some crap which i cannot type since i don't know the character codes for all those things possibly something in raw binary. off to happy bug hunting, please post your suggestions if you have anything. -mika From: mika.raj...@patria.fi To: cmake@cmake.org Date: 23.06.2011 11:00 Subject:[CMake] CDash broken after production mode is set to true Sent by:cmake-boun...@cmake.org Hi I was all set up with my cdash server, after setting production mode to true, things stop working. Clients when they attempt to receive their id when they submit to cdash server get some junk as answer, they don't list up the schedule build thing. Fonts change, menus won't work. For instance, the Administration menu, when i look at a dashboard. Any ideas? -mika___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] set custom linker in linux
Hello! Please, help to to set custom linker. I use gcc1/g++1 instead of basic gcc/g++ on system. I've tried to export CC/CXX, but I need to change linker from ld to g++1. Is it possible? ___ 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] Passing a CMake list as is to a custom target
Thank you for the feedback. I adopted using :: as a separator and I added en- and decode functions to my macro library. It's probably the cleanest solution. The only remaining comment is that opposed to the example David posted, I get wrong results when escaping the semi-colon in the regular expression. I did not look at the ExternalProject code but its working for me and I am now fine with the solution. Thanks again, - Hauke ___ 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] set custom linker in linux
Torsdag 23 juni 2011 13.34.24 skrev gekso : Hello! Please, help to to set custom linker. I use gcc1/g++1 instead of basic gcc/g++ on system. I've tried to export CC/CXX, but I need to change linker from ld to g++1. Is it possible? ___ 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 Hi, Try: set(CMAKE_LINKER g++1) I think it should work (or something similar), but haven't tested.. Cheers, Yngve ___ 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] mixed-source executables
Hi everyone, I have two questions about building mixed-source executables. First, the context: I am using an experimental C++ compiler that adds support for some additional language features. The compiler produces standard object files for my platform. I've added a custom language to cmake, CXXEX, that can compile source files that use the additional language features (.cxxex files). I don't do any linking with the experimental compiler, nor do I compile standard C++ files with it, generally because it appears to generate debugging information that is only marginally compatible with the gdb on my system---minimizing the exposure of cxxex files helps here. I use the configured CXX compiler for C++ files and for linking. This is generally g++. During configuration CMake automatically detects the CMAKE_CXXEX_IMPLICIT_LINK_(DIRECTORIES/LIBRARIES) used by the experimental compiler. When linking the mixed-source executable, it automatically adds these to the link command, which _is_ the behavior that I need, however there are two problems. 1) The implicit link directories are either the 32-bit directories, or the 64-bit directories, depending on the presence of -m32/-64 in the CXXEX_FLAGS when enable_language is called. I'm no cmake expert, but I think the result of this is that I either can't provide a CMakeCXXEXCompiler.cmake.in cache for the language, and need to redetect the language every time configuration happens, or can't provide an option to the user that allows them to change the build from 32 to 64 bit mode after the initial configuration. Is there any existing cmake mechanism that can solve this problem, i.e., let me provide a configuration variable that can be changed after the initial configuration? I could use an internal cache variable to detect the change, but I'm not sure how to force a reconfiguration of CXXEX if a configured CMakeCXXEXCompiler.cmake exists, would I just delete it? 2) The implicit link directories are added to the link command line with a -L flag, but I would actually prefer that they get added with a -R to get them embedded as an rpath. Is this something that is easily changed in the definition of the CXXEX language? There are a bunch of variables in CMakeCXXInformation.cmake (which I've copied for CXXEX) that I don't understand, is one of them what I need, or is it embedded in the definition of how to link a CXX executable somewhere? Thanks, Luk ___ 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] determine 32 vs 64 bit linux
I use this exact code to determine 64bit vs. 32bit for visual studio 2005/2008/2010. Aaron C. Meadows -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Rolf Eike Beer Sent: Thursday, June 23, 2011 1:08 AM To: cmake@cmake.org Subject: Re: [CMake] determine 32 vs 64 bit linux Am Mittwoch, 22. Juni 2011, 17:33:01 schrieb Karl Merkley: I need to install a library into a directory whose name depends on the machine type. For example if (WIN32) if (CMAKE_CL_64) set(ARCH_DIR win32) else() set(ARCH_DIR win64) endif() I'm not sure if that works for Visual Studio generators. Eike ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] regarding linking functionality and overloading in cmake
This sounds like poorly formed c++, not a CMake issue. Can you include your CMakeLists.txt, a copy of the error, and possibly a simple example which shows the problem? Aaron C. Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Leila Baghdadi Sent: Wednesday, June 22, 2011 3:57 PM To: cmake@cmake.org Subject: [CMake] regarding linking functionality and overloading in cmake hi everyone, I have been trying to use cmake to build ctsim(need to add my own code to it later) and finally managed to do it however I have difficulty understanding why my puny solution works! I have 3 different directories (a,b,c) in ctsim , so I set up cmake files in each one and built liba.so and so on, now I am trying to build the executable cstim by linking to the above three libraries and I kept getting an error, regarding an overloading function in directory a, I thought that using TARGET_LINK_LIBRARIES(target a b c) would address that but instead I had to add the source code with the overloading function from directory a into the list of source codes for the ctsim executable, does that make sense? any thought thanks Leila ___ 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] Problem finding DLLS to use with tests
Can you post your CMakeLists.txt? Did you get different errors for each of the 3 solutions you tried, or were they all the same error? What was the exception code? Aaron C. Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Stephen Torri Sent: Wednesday, June 22, 2011 2:12 PM To: cmake@cmake.org Subject: [CMake] Problem finding DLLS to use with tests I am using cmake 2.8 for building MSVC solutions for a project. The project builds fine as do the tests on Windows. The problem comes when I try to run the tests. I usually get an error message that the dependent DLLs cannot be found. I have searched on google for an answer and came up with a variety of possible solutions. I was not able to get any of them to work. So I am looking for suggestions. The methods I found were: 1. Add the directory to the DLLs to the PATH environment. 2. Copy the DLLs from their installation directory to the directory of the test binary. 3. Statically link the dependent libraries to the target executable/library. I was wondering if someone can point me towards an example, tutorial or appropriate documentation that shows how I can best solve this problem. Stephen ___ 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] Enabling C99 in CMake
On 06/23/2011 05:09 AM, Todd Gamblin wrote: On Jun 22, 2011, at 3:46 PM, Michael Hertling wrote: Wouldn't a simple CC=gcc -std=c99 cmake path/to/source for the initial configuration be an appropriate solution? I would say no, because whether or not the project is written in C99 or not isn't something the caller of cmake should have to know. It's something the developers should know, and whoever is building the code shouldn't have to care. -Todd While I can understand your point, I'm of a different opinion: In the end, it's the responsibility of the user to provide the project with a suitable compiler. The fact that CMake usually finds one automatically is very convenient, but not self-evident, so I'd take it as absolutely normal to specify the compiler used to build the project. Compare the following two cases: (1) You want to use, say, /opt/gcc-4.7/bin/gcc for your project. Of course, CMake doesn't find this compiler by itself, so you issue CC=/opt/gcc-4.7/bin/gcc cmake path/to/source for the project's initial configuration. (2) You need to use a C99 compiler for your project, but CMake invokes the C99-capable GCC without the -std=c99 switch, so you issue CC=gcc -std=c99 cmake path/to/source for the project's initial configuration. Case (1) is widely accepted, and case (2) doesn't differ basically from (1), IMO; in both cases, you specify a desired/needed compiler for your project, or in other words: A specification of your project's compiler is not limited to the latter's location in the file system, but might also span very well compiler-specific switches like the -std=c99 one. Of course, that's just my personal opinion, but in doing so, you do not need to modify any CMake files or even the CMakeLists.txt files of your project; all you need is to have a C99 compiler available. However, you might possibly add a check to your project, e.g. using TRY_COMPILE() or CheckCSourceCompiles(), with C99 source code a C89 compiler can't build, and if this check fails, you can notify the user of the need to reconfigure and specify a C99 compiler. If a project must use the GNU compiler, one would do quite the same. Regards, Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build flags when using Qt plugins (was: Where is QT_USE_IMPORTED_TARGETS not safe to use?)
On Wednesday, June 22, 2011 02:20:08 pm Clinton Stimpson wrote: On Wednesday, June 22, 2011 01:47:33 pm Stephen Kelly wrote: Clinton Stimpson wrote: The output is attached, but I'm not certain it's very helpful. Let me know if anything else would be useful. I can maybe try to create a smaller plugin using qt example for easy reproduction of the issue. Also the files in templates/lib are not compiled with flags from QT_USE_FILE. You can tell that by whether files are compiled with -DQT_CORE_LIB. Good catch. I'll remedy that and re-try. In the mean-time I have created a CMake build system for the Qt echoplugin example. On my setup it fails to load the plugin at runtime unless I comment out the add_definition(-DQT_NO_DEBUG). Could you try the same? That would at least show that it's a problem on my end. I tried the example, and if I use mingw, I have to set CMAKE_BUILD_TYPE to something for the example to work. If I use nmake or visual studio, CMAKE_BUILD_TYPE is defaulted to Debug, so it just works. So it seems one should fix the Platform/Windows-GNU.cmake or something to have something like a SET(CMAKE_BUILD_TYPE_INIT Release) or SET(CMAKE_BUILD_TYPE_INIT Debug) Would you like to submit a bug for this? As a workaround, you can enforce a value for CMAKE_BUILD_TYPE if on Windows and CMAKE_CONFIGURATION_TYPES is empty. If you enforce that, then you don't need to have the add_definition(-DQT_NO_DEBUG). I just realized a perhaps better fix can be done in UseQt4.cmake. And it'll still work if one clears the CMAKE_BUILD_TYPE after a default was set. See the fix here: http://cmake.org/gitweb?p=cmake.git;a=commit;h=5a2b208617d13808287b3c785183fed9c99576f1 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.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] Enabling C99 in CMake
On Thu, Jun 23, 2011 at 17:50, Michael Hertling mhertl...@online.de wrote: You need to use a C99 compiler for your project This is already a problem. C99 introduces new keywords (e.g. restrict) and removes implicit int. It is entirely possible for part of a project to include C89-conforming legacy code that is not valid C99. The use of C99 or C89 should be a file- and directory-level property. It's also horrible to encumber the poor user just trying to build your project with needing to know whether it is written in C99 or whatever else, nor with how to make their compiler deliver that dialect. CMake does not ask the user to provide the full command to link a shared library, it should not require the user to specify dialect C99/C89. ___ 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] Enabling C99 in CMake
On Thu, 23 Jun 2011 18:20:46 +0200, Jed Brown said: You need to use a C99 compiler for your project This is already a problem. C99 introduces new keywords (e.g. restrict) and removes implicit int. It is entirely possible for part of a project to include C89-conforming legacy code that is not valid C99. The use of C99 or C89 should be a file- and directory-level property. It's also horrible to encumber the poor user just trying to build your project with needing to know whether it is written in C99 or whatever else, nor with how to make their compiler deliver that dialect. CMake does not ask the user to provide the full command to link a shared library, it should not require the user to specify dialect C99/C89. I agree. And of course this problem is not limited to C, there are several not-fully-compatible versions of C++ too. gcc accepts flags like -std=c++98 and -std=c++0x to choose between them. Different compilers presumably need different flags. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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] Fwd: Problem finding DLLS to use with tests
On Thu, Jun 23, 2011 at 11:37 AM, aaron.mead...@thomsonreuters.com wrote:
Can you post your CMakeLists.txt? Did you get different errors for each
of the 3 solutions you tried, or were they all the same error? What was the
exception code?
I got the same error. I did not receive a exception throw when I ran the
testing code via Visual Studio. I got a message that said:
The application has failed to start because
boost_unit_test_framework-vc100-mt-gd-1_46_1.dll was not found. Reinstalling
the application may fix the problem.
It looks like I either need to copy the boost dlls I use to my test
directory or somehow add the boost directory to the PATH environment
variable.
-- Master CMakeLists.txt
cmake_minimum_required ( VERSION 2.8 )
SET(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake_modules/)
PROJECT(myproject)
SET ( ${PROJECT_NAME}_MAJOR_VERSION 0 )
SET ( ${PROJECT_NAME}_MINOR_VERSION 5 )
SET ( ${PROJECT_NAME}_PATCH_LEVEL 0 )
SET(BOOST_ROOT C:/Program Files (x86)/boost/boost_1_46_1 CACHE PATH
Installation directory for boost)
#-
# DEBUG
#-
OPTION(DEBUG_TLE_PARSER Enable debugging of TLE parser. OFF)
IF(DEBUG_TLE_PARSER)
SET (DEBUG_PARSER 1)
ENDIF(DEBUG_TLE_PARSER)
#-
#Unix Configuration
#-
IF(UNIX)
SET(INSTALL_BIN_DIR bin CACHE PATH Installation directory for
executables)
SET(INSTALL_LIB_DIR lib CACHE PATH Installation directory for libraries)
SET(INSTALL_INC_DIR include CACHE PATH Installation directory for
headers)
SET(INSTALL_DATA_DIR shared/${PROJECT_NAME} CACHE PATH Installation
directory for data files)
#-
# FLAGS
#
IF(CMAKE_BUILD_TYPE MATCHES Release)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -O3 -Wall -Werror -ansi
-pedantic)
ENDIF(CMAKE_BUILD_TYPE MATCHES Release)
IF(CMAKE_BUILD_TYPE MATCHES Debug)
SET(CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG} -O0 -Wall -Werror
-ansi -pedantic)
ENDIF(CMAKE_BUILD_TYPE MATCHES Debug)
OPTION(BUILD_SHARED_LIBS Build shared libraries. ON)
IF(DEBUG_TLE_PARSER)
SET(CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG} -DDEBUG_PARSER)
ENDIF(DEBUG_TLE_PARSER)
ENDIF(UNIX)
set(myproject_SRC_DIR ${CMAKE_SOURCE_DIR}/myproject)
#-
# SHARED / STATIC
#-
# Allow the developer to select if Dynamic or Static libraries are built
OPTION(BUILD_SHARED_LIBS Build shared libraries. OFF)
# Set the LIB_TYPE variable to STATIC
SET (LIB_TYPE STATIC)
IF (BUILD_SHARED_LIBS)
# User wants to build Dynamic Libraries, so change the LIB_TYPE variable
to CMake keyword 'SHARED'
SET (LIB_TYPE SHARED)
IF(WIN32)
SET (BUILD_SHARED_WIN32 1)
ENDIF(WIN32)
ENDIF (BUILD_SHARED_LIBS)
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/myproject/config.h.in${CMAKE_CURRENT_SOURCE_DIR}/myproject/config.h)
#-
# TESTING
#-
ENABLE_TESTING()
add_custom_target ( check COMMAND ${CMAKE_CTEST_COMMAND} )
SUBDIRS(Testing/units)
SUBDIRS(Testing/myproject)
#-
# FIND PACKAGES
#-
IF(WIN32)
SET(Boost_USE_STATIC_LIBS ON)
SET(Boost_USE_MULTITHREADED ON)
ENDIF(WIN32)
SET(Boost_ADDITIONAL_VERSIONS 1.46 1.44 1.44.0 )
FIND_PACKAGE(Boost REQUIRED COMPONENTS program_options thread
unit_test_framework filesystem system)
#-
# CPACK
#-
#-
# CPACK DESCRIPTION INFORMATION
#-
IF(CMAKE_BUILD_TYPE MATCHES Release)
SET(CPACK_PACKAGE_NAME myproject)
SET(CPACK_PACKAGE_INSTALL_DIRECTORY myproject)
ENDIF(CMAKE_BUILD_TYPE MATCHES Release)
IF(CMAKE_BUILD_TYPE MATCHES Debug)
SET(CPACK_PACKAGE_NAME myproject_debug)
SET(CPACK_PACKAGE_INSTALL_DIRECTORY myproject debug)
ENDIF(CMAKE_BUILD_TYPE MATCHES Debug)
SET(CPACK_PACKAGE_VENDOR Self)
SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY myproject is an implementation of the
myproject satellite model for use in the DTCS project)
SET(CPACK_PACKAGE_DESCRIPTION_FILE ${CMAKE_CURRENT_SOURCE_DIR}/ReadMe.txt)
SET(CPACK_RESOURCE_FILE_LICENSE ${CMAKE_CURRENT_SOURCE_DIR}/Copyright.txt)
SET(CPACK_PACKAGE_VERSION_MAJOR ${myproject_MAJOR_VERSION})
SET(CPACK_PACKAGE_VERSION_MINOR ${myproject_MINOR_VERSION})
SET(CPACK_PACKAGE_VERSION_PATCH ${myproject_PATCH_LEVEL})
#-
# DOCUMENTATION
Re: [CMake] regarding linking functionality and overloading in cmake
Unless ImageFileArrayConst is a typedef for double **, there is not an ImageFile::statistics() function which takes a double** as the first parameter. (Line 288 and 296 have the two versions of ImageFile::statistics()) If you look in views.cpp at the function ImageFileView::OnProperties() function where it is calling the ImageFile::statistics() function, what is the type of the first parameter? Do you have an extra on the front of a double* variable there? Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 12:56 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Hello I have attached the CMakeLists.txt file (note, I commented the source in question line 76) and I get the following error, If I leave line 76 in, I get a clean build Linking CXX executable opt_ctsim CMakeFiles/opt_ctsim.dir/src/views.cpp.o: In function `ImageFileView::OnProperties(wxCommandEvent)': views.cpp:(.text+0x1bfd9): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' views.cpp:(.text+0x1c57a): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' collect2: ld returned 1 exit status I am also attaching the source imagefile.cpp located in libctsim subdirectory. thanks From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 11:29am To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake This sounds like poorly formed c++, not a CMake issue. Can you include your CMakeLists.txt, a copy of the error, and possibly a simple example which shows the problem? Aaron C. Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Leila Baghdadi Sent: Wednesday, June 22, 2011 3:57 PM To: cmake@cmake.org Subject: [CMake] regarding linking functionality and overloading in cmake hi everyone, I have been trying to use cmake to build ctsim(need to add my own code to it later) and finally managed to do it however I have difficulty understanding why my puny solution works! I have 3 different directories (a,b,c) in ctsim , so I set up cmake files in each one and built liba.so and so on, now I am trying to build the executable cstim by linking to the above three libraries and I kept getting an error, regarding an overloading function in directory a, I thought that using TARGET_LINK_LIBRARIES(target a b c) would address that but instead I had to add the source code with the overloading function from directory a into the list of source codes for the ctsim executable, does that make sense? any thought thanks Leila ___ 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] regarding linking functionality and overloading in cmake
yep that's how its defined. (note, this is not my code, it is backprojection code free for download at ctsim.org) typedef double kfloat64; typedef kfloat64** const ImageFileArrayConst; the code has diversions between 32 and 64 bit, anyways, that's how it is defined. Leila From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 2:09pm To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Unless “ImageFileArrayConst” is a typedef for “double **”, there is not an ImageFile::statistics() function which takes a double** as the first parameter. (Line 288 and 296 have the two versions of ImageFile::statistics()) If you look in views.cpp at the function ImageFileView::OnProperties() function where it is calling the ImageFile::statistics() function, what is the type of the first parameter? Do you have an extra on the front of a double* variable there? Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 12:56 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Hello I have attached the CMakeLists.txt file (note, I commented the source in question line 76) and I get the following error, If I leave line 76 in, I get a clean build Linking CXX executable opt_ctsim CMakeFiles/opt_ctsim.dir/src/views.cpp.o: In function `ImageFileView::OnProperties(wxCommandEvent)': views.cpp:(.text+0x1bfd9): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' views.cpp:(.text+0x1c57a): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' collect2: ld returned 1 exit status I am also attaching the source imagefile.cpp located in libctsim subdirectory. thanks From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 11:29am To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake This sounds like poorly formed c++, not a CMake issue. Can you include your CMakeLists.txt, a copy of the error, and possibly a simple example which shows the problem? Aaron C. Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Leila Baghdadi Sent: Wednesday, June 22, 2011 3:57 PM To: cmake@cmake.org Subject: [CMake] regarding linking functionality and overloading in cmake hi everyone, I have been trying to use cmake to build ctsim(need to add my own code to it later) and finally managed to do it however I have difficulty understanding why my puny solution works! I have 3 different directories (a,b,c) in ctsim , so I set up cmake files in each one and built liba.so and so on, now I am trying to build the executable cstim by linking to the above three libraries and I kept getting an error, regarding an overloading function in directory a, I thought that using TARGET_LINK_LIBRARIES(target a b c) would address that but instead I had to add the source code with the overloading function from directory a into the list of source codes for the ctsim executable, does that make sense? any thought thanks Leila ___ 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] regarding linking functionality and overloading in cmake
Oh, sorry.. I missunderstood about the line 76. =D Ok, looking at your CMakeLists.txt, I see the ADD_SUBDIRECTORY(libctsim). I’m assuming there is a CMakeLists.txt in there which does the ADD_LIBRARY. The ADD_SUBDIRECTORY() calls are before you’re doing a bunch of ADD_DEFINITIONS(). The definitions you are setting up below are not going to apply to those subdirectories. Is it possible that the signature of the function is different in the library than in the opt_ctsim executable because of these definitions? On windows, I would suggest using ‘dumpbin.exe /LinkerMember’ to see the mangled signature of the functions in the library and compare them to the expected signature printed in the linker error for the executable (here’s a description I wrote about it: http://stackoverflow.com/questions/261377/lnk2001-error-when-compiling-apps-referencing-stlport-5-1-4-with-vc-2008/687185#687185 ) I’m not sure what the equivolent process would be for gcc if that is what you are using. Looks like it might be the programs ‘nm’ and ‘objdump’. You might try moving your ADD_SUBDIRECTORY() calls to right above ADD_EXECUTABLE and see if that allows the linking to work correctly. Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 1:33 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake yep that's how its defined. (note, this is not my code, it is backprojection code free for download at ctsim.org) typedef double kfloat64; typedef kfloat64** const ImageFileArrayConst; the code has diversions between 32 and 64 bit, anyways, that's how it is defined. Leila From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 2:09pm To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Unless “ImageFileArrayConst” is a typedef for “double **”, there is not an ImageFile::statistics() function which takes a double** as the first parameter. (Line 288 and 296 have the two versions of ImageFile::statistics()) If you look in views.cpp at the function ImageFileView::OnProperties() function where it is calling the ImageFile::statistics() function, what is the type of the first parameter? Do you have an extra on the front of a double* variable there? Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 12:56 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Hello I have attached the CMakeLists.txt file (note, I commented the source in question line 76) and I get the following error, If I leave line 76 in, I get a clean build Linking CXX executable opt_ctsim CMakeFiles/opt_ctsim.dir/src/views.cpp.o: In function `ImageFileView::OnProperties(wxCommandEvent)': views.cpp:(.text+0x1bfd9): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' views.cpp:(.text+0x1c57a): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' collect2: ld returned 1 exit status I am also attaching the source imagefile.cpp located in libctsim subdirectory. thanks From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 11:29am To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake This sounds like poorly formed c++, not a CMake issue. Can you include your CMakeLists.txt, a copy of the error, and possibly a simple example which shows the problem? Aaron C. Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Leila Baghdadi Sent: Wednesday, June 22, 2011 3:57 PM To: cmake@cmake.org Subject: [CMake] regarding linking functionality and overloading in cmake hi everyone, I have been trying to use cmake to build ctsim(need to add my own code to it later) and finally managed to do it however I have difficulty understanding why my puny solution works! I have 3 different directories (a,b,c) in ctsim , so I set up cmake files in each one and built liba.so and so on, now I am trying to build the executable cstim by linking to the above three libraries and I kept getting an error, regarding an overloading function in directory a, I thought that using TARGET_LINK_LIBRARIES(target a b c) would address that but instead I had to add the source code with the overloading function from directory a into the list of source codes for the ctsim executable, does that make sense? any thought thanks Leila ___ Powered by www.kitware.com Visit other Kitware open-source projects at
Re: [CMake] regarding linking functionality and overloading in cmake
Thanks very much aaron for your suggestions, I will do some further investigation and report if I find something, I was just kind of wondering if there was something about libraries and overloading that I was not aware of, Leila From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 2:52pm To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Oh, sorry.. I missunderstood about the line 76. =D Ok, looking at your CMakeLists.txt, I see the ADD_SUBDIRECTORY(libctsim). I’m assuming there is a CMakeLists.txt in there which does the ADD_LIBRARY. The ADD_SUBDIRECTORY() calls are before you’re doing a bunch of ADD_DEFINITIONS(). The definitions you are setting up below are not going to apply to those subdirectories. Is it possible that the signature of the function is different in the library than in the opt_ctsim executable because of these definitions? On windows, I would suggest using ‘dumpbin.exe /LinkerMember’ to see the mangled signature of the functions in the library and compare them to the expected signature printed in the linker error for the executable (here’s a description I wrote about it: http://stackoverflow.com/questions/261377/lnk2001-error-when-compiling-apps-referencing-stlport-5-1-4-with-vc-2008/687185#687185 ) I’m not sure what the equivolent process would be for gcc if that is what you are using. Looks like it might be the programs ‘nm’ and ‘objdump’. You might try moving your ADD_SUBDIRECTORY() calls to right above ADD_EXECUTABLE and see if that allows the linking to work correctly. Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 1:33 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake yep that's how its defined. (note, this is not my code, it is backprojection code free for download at ctsim.org) typedef double kfloat64; typedef kfloat64** const ImageFileArrayConst; the code has diversions between 32 and 64 bit, anyways, that's how it is defined. Leila From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 2:09pm To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Unless “ImageFileArrayConst” is a typedef for “double **”, there is not an ImageFile::statistics() function which takes a double** as the first parameter. (Line 288 and 296 have the two versions of ImageFile::statistics()) If you look in views.cpp at the function ImageFileView::OnProperties() function where it is calling the ImageFile::statistics() function, what is the type of the first parameter? Do you have an extra on the front of a double* variable there? Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 12:56 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Hello I have attached the CMakeLists.txt file (note, I commented the source in question line 76) and I get the following error, If I leave line 76 in, I get a clean build Linking CXX executable opt_ctsim CMakeFiles/opt_ctsim.dir/src/views.cpp.o: In function `ImageFileView::OnProperties(wxCommandEvent)': views.cpp:(.text+0x1bfd9): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' views.cpp:(.text+0x1c57a): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' collect2: ld returned 1 exit status I am also attaching the source imagefile.cpp located in libctsim subdirectory. thanks From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 11:29am To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake This sounds like poorly formed c++, not a CMake issue. Can you include your CMakeLists.txt, a copy of the error, and possibly a simple example which shows the problem? Aaron C. Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Leila Baghdadi Sent: Wednesday, June 22, 2011 3:57 PM To: cmake@cmake.org Subject: [CMake] regarding linking functionality and overloading in cmake hi everyone, I have been trying to use cmake to build ctsim(need to add my own code to it later) and finally managed to do it however I have difficulty understanding why my puny solution works! I have 3 different directories (a,b,c) in ctsim , so I set up cmake files in each one and built liba.so and so on, now I am trying to build the executable cstim by linking to the above three libraries and I kept getting an error, regarding an overloading function in directory a, I thought that using TARGET_LINK_LIBRARIES(target a b c) would address that but instead I had to
Re: [CMake] regarding linking functionality and overloading in cmake
Hope it helps. I’m not completely clear on what you are talking about with the overloading. Are you saying you have the same function defined in multiple static libraries? Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 1:55 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Thanks very much aaron for your suggestions, I will do some further investigation and report if I find something, I was just kind of wondering if there was something about libraries and overloading that I was not aware of, Leila From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 2:52pm To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Oh, sorry.. I missunderstood about the line 76. =D Ok, looking at your CMakeLists.txt, I see the ADD_SUBDIRECTORY(libctsim). I’m assuming there is a CMakeLists.txt in there which does the ADD_LIBRARY. The ADD_SUBDIRECTORY() calls are before you’re doing a bunch of ADD_DEFINITIONS(). The definitions you are setting up below are not going to apply to those subdirectories. Is it possible that the signature of the function is different in the library than in the opt_ctsim executable because of these definitions? On windows, I would suggest using ‘dumpbin.exe /LinkerMember’ to see the mangled signature of the functions in the library and compare them to the expected signature printed in the linker error for the executable (here’s a description I wrote about it: http://stackoverflow.com/questions/261377/lnk2001-error-when-compiling-apps-referencing-stlport-5-1-4-with-vc-2008/687185#687185 ) I’m not sure what the equivolent process would be for gcc if that is what you are using. Looks like it might be the programs ‘nm’ and ‘objdump’. You might try moving your ADD_SUBDIRECTORY() calls to right above ADD_EXECUTABLE and see if that allows the linking to work correctly. Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 1:33 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake yep that's how its defined. (note, this is not my code, it is backprojection code free for download at ctsim.org) typedef double kfloat64; typedef kfloat64** const ImageFileArrayConst; the code has diversions between 32 and 64 bit, anyways, that's how it is defined. Leila From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 2:09pm To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Unless “ImageFileArrayConst” is a typedef for “double **”, there is not an ImageFile::statistics() function which takes a double** as the first parameter. (Line 288 and 296 have the two versions of ImageFile::statistics()) If you look in views.cpp at the function ImageFileView::OnProperties() function where it is calling the ImageFile::statistics() function, what is the type of the first parameter? Do you have an extra on the front of a double* variable there? Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 12:56 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Hello I have attached the CMakeLists.txt file (note, I commented the source in question line 76) and I get the following error, If I leave line 76 in, I get a clean build Linking CXX executable opt_ctsim CMakeFiles/opt_ctsim.dir/src/views.cpp.o: In function `ImageFileView::OnProperties(wxCommandEvent)': views.cpp:(.text+0x1bfd9): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' views.cpp:(.text+0x1c57a): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' collect2: ld returned 1 exit status I am also attaching the source imagefile.cpp located in libctsim subdirectory. thanks From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 11:29am To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake This sounds like poorly formed c++, not a CMake issue. Can you include your CMakeLists.txt, a copy of the error, and possibly a simple example which shows the problem? Aaron C. Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Leila Baghdadi Sent: Wednesday, June 22, 2011 3:57 PM To: cmake@cmake.org Subject: [CMake] regarding linking functionality and overloading in cmake hi everyone, I have been trying to
[CMake] How do you tell FindOpenSSL to find OpenSSL in a non-standard path?
I see that mysql recently switched to using Cmake. Previously, when using configure, I could tell mysql where to find our custom OpenSSL installation, and link mysql to it. So far, however, I'm having no luck getting cmake to do this. Currently I have: /usr/bin/cmake . -DWITH_SSL=system -DOPENSSL_INCLUDE_DIR=/opt/zimbra/openssl-1.0.0d/include -DOPENSSL_LIBRARIES=/opt/zimbra/openssl-1.0.0d/lib -DCMAKE_INSTALL_PREFIX=/opt/zimbra/mysql-5.5.28 -DENABLED_PROFILING=on -DWITH_READLINE=TRUE However, this always errors out that it can't find the SHA512_DIGEST_LENGTH variable set in openssl/sha.h, which exists: #define SHA512_DIGEST_LENGTH64 How do I tell Cmake where to find my openssl build? Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration ___ 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] Fwd: Problem finding DLLS to use with tests
So, you are manually running your tests, for example, the
'test_julian.exe' or 'testcpp.exe'? Running them from a command prompt
gives you that same error about the application has failed to start?
And the name of the dll's exactly match? And you have tried copying the
.dll into the same directory and running it manually?
You can use Dependency Walker to run a program and debug the issues it
has with DLL. Some versions of Visual Studio come with a version of it.
You can run depends.exe from a visual studio command prompt and pass it
the executable. If you don't have it, you can get it from
http://www.dependencywalker.com/. You can profile and executable by
hitting F7 (I usually checkmark all the options to on) and it will tell
you all about what it is doing to bootstrap you exe, including where it
fails. Usually, this will give you a better idea of what happened,
where it looked for the DLL, and why it rejected ones that seemed like
they should have worked. In particular, it might be finding that DLL
fine, but the DLL is returning 0 from DllMain() and failing to be
loaded.
Hope that helps!
Aaron C. Meadows
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Stephen Torri
Sent: Thursday, June 23, 2011 1:19 PM
To: cmake@cmake.org
Subject: [CMake] Fwd: Problem finding DLLS to use with tests
On Thu, Jun 23, 2011 at 11:37 AM, aaron.mead...@thomsonreuters.com
wrote:
Can you post your CMakeLists.txt? Did you get different errors for each
of the 3 solutions you tried, or were they all the same error? What was
the exception code?
I got the same error. I did not receive a exception throw when I ran the
testing code via Visual Studio. I got a message that said:
The application has failed to start because
boost_unit_test_framework-vc100-mt-gd-1_46_1.dll was not found.
Reinstalling the application may fix the problem.
It looks like I either need to copy the boost dlls I use to my test
directory or somehow add the boost directory to the PATH environment
variable.
-- Master CMakeLists.txt
cmake_minimum_required ( VERSION 2.8 )
SET(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake_modules/)
PROJECT(myproject)
SET ( ${PROJECT_NAME}_MAJOR_VERSION 0 )
SET ( ${PROJECT_NAME}_MINOR_VERSION 5 )
SET ( ${PROJECT_NAME}_PATCH_LEVEL 0 )
SET(BOOST_ROOT C:/Program Files (x86)/boost/boost_1_46_1 CACHE PATH
Installation directory for boost)
#-
# DEBUG
#-
OPTION(DEBUG_TLE_PARSER Enable debugging of TLE parser. OFF)
IF(DEBUG_TLE_PARSER)
SET (DEBUG_PARSER 1)
ENDIF(DEBUG_TLE_PARSER)
#-
#Unix Configuration
#-
IF(UNIX)
SET(INSTALL_BIN_DIR bin CACHE PATH Installation directory for
executables)
SET(INSTALL_LIB_DIR lib CACHE PATH Installation directory for
libraries)
SET(INSTALL_INC_DIR include CACHE PATH Installation directory for
headers)
SET(INSTALL_DATA_DIR shared/${PROJECT_NAME} CACHE PATH Installation
directory for data files)
#-
# FLAGS
#
IF(CMAKE_BUILD_TYPE MATCHES Release)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -O3 -Wall -Werror -ansi
-pedantic)
ENDIF(CMAKE_BUILD_TYPE MATCHES Release)
IF(CMAKE_BUILD_TYPE MATCHES Debug)
SET(CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG} -O0 -Wall
-Werror -ansi -pedantic)
ENDIF(CMAKE_BUILD_TYPE MATCHES Debug)
OPTION(BUILD_SHARED_LIBS Build shared libraries. ON)
IF(DEBUG_TLE_PARSER)
SET(CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG} -DDEBUG_PARSER)
ENDIF(DEBUG_TLE_PARSER)
ENDIF(UNIX)
set(myproject_SRC_DIR ${CMAKE_SOURCE_DIR}/myproject)
#-
# SHARED / STATIC
#-
# Allow the developer to select if Dynamic or Static libraries are built
OPTION(BUILD_SHARED_LIBS Build shared libraries. OFF)
# Set the LIB_TYPE variable to STATIC
SET (LIB_TYPE STATIC)
IF (BUILD_SHARED_LIBS)
# User wants to build Dynamic Libraries, so change the LIB_TYPE
variable to CMake keyword 'SHARED'
SET (LIB_TYPE SHARED)
IF(WIN32)
SET (BUILD_SHARED_WIN32 1)
ENDIF(WIN32)
ENDIF (BUILD_SHARED_LIBS)
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/myproject/config.h.in
http://config.h.in/ ${CMAKE_CURRENT_SOURCE_DIR}/myproject/config.h)
#-
# TESTING
#-
ENABLE_TESTING()
add_custom_target ( check COMMAND ${CMAKE_CTEST_COMMAND} )
SUBDIRS(Testing/units)
SUBDIRS(Testing/myproject)
#-
# FIND PACKAGES
Re: [CMake] How do you tell FindOpenSSL to find OpenSSL in a non-standard path?
On 06/23/2011 08:50 PM, Quanah Gibson-Mount wrote: I see that mysql recently switched to using Cmake. Previously, when using configure, I could tell mysql where to find our custom OpenSSL installation, and link mysql to it. So far, however, I'm having no luck getting cmake to do this. Currently I have: /usr/bin/cmake . -DWITH_SSL=system -DOPENSSL_INCLUDE_DIR=/opt/zimbra/openssl-1.0.0d/include -DOPENSSL_LIBRARIES=/opt/zimbra/openssl-1.0.0d/lib -DCMAKE_INSTALL_PREFIX=/opt/zimbra/mysql-5.5.28 -DENABLED_PROFILING=on -DWITH_READLINE=TRUE However, this always errors out that it can't find the SHA512_DIGEST_LENGTH variable set in openssl/sha.h, which exists: #define SHA512_DIGEST_LENGTH64 How do I tell Cmake where to find my openssl build? Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration Usually it is better to set CMAKE_PREFIX_PATH to /opt/zimbra/openssl-1.0.0d, and then let FindOpenSSL.cmake do its work. Without looking at FindOpenSSL.cmake, the -DOPENSSL_LIBRARIES=... argument looks fishy to me, because usually XXX_LIBRARIES variables are not cached, but a concatenation of various XXX_LIBRARY variables. HTH Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug #12189
I've updated the bug with an additional patch (had a bug for some
configuration cases).
What is the procedure to get this patch considered and applied? Do I
need to contact the Visual Studio Generator maintainer directly?
Aaron C. Meadows
From: Meadows, Aaron C.
Sent: Tuesday, June 21, 2011 9:49 AM
To: Meadows, Aaron C.; cmake@cmake.org
Subject: RE: [CMake] Bug #12189
I updated the bug with this patch and some of the details from below.
Aaron C. Meadows
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Meadows, Aaron C.
Sent: Monday, June 20, 2011 5:17 PM
To: cmake@cmake.org
Subject: [CMake] Bug #12189
(link: http://public.kitware.com/Bug/view.php?id=12189)
I just came across the above bug opened last month, Summaraized as: It
is not possible to generate a Visual Studio project with ASCII/SBCS
character set. (Full Bug Text Following Message)
I find myself in the situation where I need this to be set to not set,
so as to have ASCII/SBCS as the character set for all my projects. I
dug back through the last few years of the maillist and didn't see
anything about this issue.
Anyone have experience with this issue? And better yet, know of a
solution?
I checked the source file he indicated (it's on line 702 of the 2.8.4
source):
// If unicode is enabled change the character set to unicode, if not
// then default to MBCS.
if(targetOptions.UsingUnicode())
{
fout \t\t\tCharacterSet=\1\\n;
}
else
{
fout \t\t\tCharacterSet=\2\\n;
}
Additionally, VS 2010 has a different mechanism (line 287 of the 2.8.4
source):
if(this-Target-GetType() = cmTarget::MODULE_LIBRARY
this-ClOptions[*i]-UsingUnicode())
{
this-WriteString(CharacterSetUnicode/CharacterSet\n, 2);
}
else
{
this-WriteString(CharacterSetMultiByte/CharacterSet\n, 2);
}
In the case of VS 2010, the proper ASCII setting is:
CharacterSetNotSet/CharacterSet
It would be fairly trivial to change both these cases to generate the
Not Set case. However, how should backward compatibility be
maintained, if at all?
I've created and attached a patch which resolves this bug by adding an
_SBCS define which is checked. If it is set and _UNICODE is not
set, it will write the correct files for the Not Set ASCII case. This
is slightly different than the suggestion in the Bug, but was very easy
to write and provides identical behavior if _SBCS is not set.
--
Full Bug Text:
--
In Visual Studio 9.0 (and prior, 10.0 i don't know) it is possible
specify three different character sets for your project within the
project properties:
Not Set = ASCII/SBCS (Single Byte Character Set)
Unicode
Multi-Byte
Depending on the option different preprocessor defines are set
(http://msdn.microsoft.com/en-us/library/c426s321(v=vs.80).aspx [^
http://msdn.microsoft.com/en-us/library/c426s321(v=vs.80).aspx ]):
SBCS: neither _UNICODE nor _MBCS defined
Unicode: _UNICODE defined
Multi_Byte: _MBCS defined
The character set settings is stored within the vs proj files as an xml
attribute:
SBCS: CharacterSet=0
Unicode: CharacterSet=1
Multi-Byte: CharacterSet=2
However, the cmake visual studio generators do not support generating of
projects with CharacterSet=0 (see cmLocalVisualStudio7Generator.cxx
line 730). At the moment the generators select unicode if a _UNICODE
macro has been set by add_definitions, otherwise multi-byte is selected.
To solve the problem and to keep backwards compatability, i suggest to
define the _MBCS macro by default for the visual studio generators and
to set CharacterSet=2 only if this macro is still available and
otherwise CharacterSet=0. In that case the user can remove the _MBCS
macro by remove_definitions and select this way the SBCS. If the user
adds _UNICODE by add_definitions CharacterSet=1 should be selected and
the conflicting _MBCS macro must be deleted by the code generator.
--
Aaron Meadows
Software Engineer
Thomson Reuters
Phone: 314.468.3530
Mobile: 636.541.6139
aaron.mead...@thomsonreuters.com
thomsonreuters.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] How do you tell FindOpenSSL to find OpenSSL in a non-standard path?
--On Thursday, June 23, 2011 9:15 PM +0200 Michael Wild them...@gmail.com wrote: Usually it is better to set CMAKE_PREFIX_PATH to /opt/zimbra/openssl-1.0.0d, and then let FindOpenSSL.cmake do its work. Without looking at FindOpenSSL.cmake, the -DOPENSSL_LIBRARIES=... argument looks fishy to me, because usually XXX_LIBRARIES variables are not cached, but a concatenation of various XXX_LIBRARY variables. Well, that fixes finding the library but not the header: -- Found OpenSSL: /opt/zimbra/openssl-1.0.0d/lib/libssl.so -- Looking for SHA512_DIGEST_LENGTH -- Looking for SHA512_DIGEST_LENGTH - not found. CMake Error at cmake/ssl.cmake:83 (MESSAGE): Cannot find appropriate system libraries for SSL. Use WITH_SSL=bundled to enable SSL support Call Stack (most recent call first): CMakeLists.txt:248 (MYSQL_CHECK_SSL) [root@zre-rhel5-64 mysql]# cd /opt/zimbra/openssl-1.0.0d/include/openssl/ [root@zre-rhel5-64 openssl]# ls -l sha.h -rw-r--r-- 1 root root 7299 Jun 23 12:25 sha.h [root@zre-rhel5-64 openssl]# grep SHA512_DIGEST_LENGTH sha.h #define SHA512_DIGEST_LENGTH64 I've tried setting CMAKE_INCLUDE_PATH too, but same error. It seems like for the include files, this is broken. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How do you tell FindOpenSSL to find OpenSSL in a non-standard path?
--On Thursday, June 23, 2011 12:31 PM -0700 Quanah Gibson-Mount qua...@zimbra.com wrote: I've tried setting CMAKE_INCLUDE_PATH too, but same error. It seems like for the include files, this is broken. This seems to be a bug in the mysql files for cmake, I'll follow up further with them. Thanks for the help! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration ___ 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] regarding linking functionality and overloading in cmake
yes, I think for some reasons it has difficulty linking with the function (correct set of parameters), i.e, it has difficulty figuring out which one of the functions to use, Leila From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 3:01pm To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Hope it helps. I’m not completely clear on what you are talking about with the overloading. Are you saying you have the same function defined in multiple static libraries? Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 1:55 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Thanks very much aaron for your suggestions, I will do some further investigation and report if I find something, I was just kind of wondering if there was something about libraries and overloading that I was not aware of, Leila From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 2:52pm To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Oh, sorry.. I missunderstood about the line 76. =D Ok, looking at your CMakeLists.txt, I see the ADD_SUBDIRECTORY(libctsim). I’m assuming there is a CMakeLists.txt in there which does the ADD_LIBRARY. The ADD_SUBDIRECTORY() calls are before you’re doing a bunch of ADD_DEFINITIONS(). The definitions you are setting up below are not going to apply to those subdirectories. Is it possible that the signature of the function is different in the library than in the opt_ctsim executable because of these definitions? On windows, I would suggest using ‘dumpbin.exe /LinkerMember’ to see the mangled signature of the functions in the library and compare them to the expected signature printed in the linker error for the executable (here’s a description I wrote about it: http://stackoverflow.com/questions/261377/lnk2001-error-when-compiling-apps-referencing-stlport-5-1-4-with-vc-2008/687185#687185 ) I’m not sure what the equivolent process would be for gcc if that is what you are using. Looks like it might be the programs ‘nm’ and ‘objdump’. You might try moving your ADD_SUBDIRECTORY() calls to right above ADD_EXECUTABLE and see if that allows the linking to work correctly. Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 1:33 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake yep that's how its defined. (note, this is not my code, it is backprojection code free for download at ctsim.org) typedef double kfloat64; typedef kfloat64** const ImageFileArrayConst; the code has diversions between 32 and 64 bit, anyways, that's how it is defined. Leila From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 2:09pm To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Unless “ImageFileArrayConst” is a typedef for “double **”, there is not an ImageFile::statistics() function which takes a double** as the first parameter. (Line 288 and 296 have the two versions of ImageFile::statistics()) If you look in views.cpp at the function ImageFileView::OnProperties() function where it is calling the ImageFile::statistics() function, what is the type of the first parameter? Do you have an extra on the front of a double* variable there? Aaron C. Meadows From: Leila Baghdadi [mailto:baghd...@phenogenomics.ca] Sent: Thursday, June 23, 2011 12:56 PM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake Hello I have attached the CMakeLists.txt file (note, I commented the source in question line 76) and I get the following error, If I leave line 76 in, I get a clean build Linking CXX executable opt_ctsim CMakeFiles/opt_ctsim.dir/src/views.cpp.o: In function `ImageFileView::OnProperties(wxCommandEvent)': views.cpp:(.text+0x1bfd9): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' views.cpp:(.text+0x1c57a): undefined reference to `ImageFile::statistics(double**, double, double, double, double, double, double) const' collect2: ld returned 1 exit status I am also attaching the source imagefile.cpp located in libctsim subdirectory. thanks From: aaron.mead...@thomsonreuters.com Sent: Thu, 6/23/2011 11:29am To: Leila Baghdadi baghd...@phenogenomics.ca ; cmake@cmake.org Subject: RE: [CMake] regarding linking functionality and overloading in cmake This sounds like poorly formed c++, not a CMake issue. Can you include your CMakeLists.txt, a copy of the error, and possibly a simple example which shows the problem? Aaron C. Meadows From:
Re: [CMake] Enabling C99 in CMake
Thanks to Sean and Jed for useful counterexamples. A few more points: On Jun 23, 2011, at 8:50 AM, Michael Hertling wrote: While I can understand your point, I'm of a different opinion: In the end, it's the responsibility of the user to provide the project with a suitable compiler. If it's not autodetected, then yes. And given this, the user might supply CMake with a perfectly fine compiler, but since they do not know the proper flags for that compiler they won't be able to use it. So now you're adding to the user's responsibility, when the developer could just as easily specify this. Add to this Jed's point that some projects have certain targets/directories that should be built with C99 or not, and I think simply specifying things at the command line is overly cumbersome. Re: Case (1) is widely accepted It's only widely accepted when CMake can't autodetect your compiler, and CMake goes to great lengths to do that for you. I don't see what the harm is in having it also make a good-faith effort to know dialect switches. However, you might possibly add a check to your project, e.g. using TRY_COMPILE() or CheckCSourceCompiles(), with C99 source code a C89 compiler can't build, and if this check fails, you can notify the user of the need to reconfigure and specify a C99 compiler. If a project must use the GNU compiler, one would do quite the same. You could do this, but it seems like a lot of work for the developer AND the user compared to my suggestion of just having a variable for the compiler-specific C99 flags, or some similar mechanism. We know an awful lot of other things about compiler switches. Dialect seems like a useful thing to add to the platform file. Someone does this once for each known compiler ID and now no one has to bother with this stuff anymore. -Todd __ Todd Gamblin, tgamb...@llnl.gov, http://people.llnl.gov/gamblin2 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA ___ 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-commits] CMake branch, next, updated. v2.8.4-1814-g4be5c92
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 4be5c9259dbcca7f7682ea4bc09a8ffa101f33bd (commit)
via 4a50b5f2aaa6965f908f1a64c202cacf175eeb56 (commit)
via a66df0854361479bbfece06e4c0d9d975c084e71 (commit)
via 6e1d3edb4d1e1b491df879a2764d8a24442795dc (commit)
from 9bac8cb0359fc1e98464437ecb588100fc9798a6 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4be5c9259dbcca7f7682ea4bc09a8ffa101f33bd
commit 4be5c9259dbcca7f7682ea4bc09a8ffa101f33bd
Merge: 9bac8cb 4a50b5f
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Thu Jun 23 10:14:38 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jun 23 10:14:38 2011 -0400
Merge topic 'DisableSwitchForFindPackage' into next
4a50b5f Add a basic test for CMAKE_DISABLE_FIND_PACKAGE_package
a66df08 Add documentation for the CMAKE_DISABLE_FIND_PACKAGE_Name switch
6e1d3ed Add a switch to disable a find_package() call completely
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4a50b5f2aaa6965f908f1a64c202cacf175eeb56
commit 4a50b5f2aaa6965f908f1a64c202cacf175eeb56
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Jun 16 22:42:00 2011 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Jun 23 11:09:54 2011 +0200
Add a basic test for CMAKE_DISABLE_FIND_PACKAGE_package
Alex
diff --git a/Tests/FindPackageTest/CMakeLists.txt
b/Tests/FindPackageTest/CMakeLists.txt
index 87fe84e..0169ac9 100644
--- a/Tests/FindPackageTest/CMakeLists.txt
+++ b/Tests/FindPackageTest/CMakeLists.txt
@@ -75,7 +75,7 @@ ENDIF()
# For purposes of the test wipe out previous find results.
SET(PACKAGES
- foo Foo Bar TFramework Tframework TApp Tapp Special
+ foo Foo Bar Blub TFramework Tframework TApp Tapp Special
VersionedA VersionedB VersionedC VersionedD VersionedE
WrongA WrongB WrongC WrongD
wibbleA wibbleB
@@ -104,6 +104,8 @@ set(CMAKE_IGNORE_PATH
${CMAKE_CURRENT_SOURCE_DIR}/lib/cmake/zot-3.1)
FIND_PACKAGE(foo NO_MODULE)
FIND_PACKAGE(Foo CONFIGS FooConfig.cmake)
FIND_PACKAGE(Bar)
+SET(CMAKE_DISABLE_FIND_PACKAGE_Blub TRUE)
+FIND_PACKAGE(Blub NO_MODULE)
FIND_PACKAGE(TFramework CONFIGS TFrameworkConfig.cmake)
FIND_PACKAGE(Tframework)
FIND_PACKAGE(TApp)
@@ -169,6 +171,7 @@ ENDIF()
SET(foo_EXPECTED lib/foo-1.2/foo-config.cmake)
SET(Foo_EXPECTED lib/foo-1.2/CMake/FooConfig.cmake)
SET(Bar_EXPECTED lib/Bar/BarConfig.cmake)
+SET(Blub_MISSING )
SET(Special_EXPECTED lib/suffix/test/SuffixTestConfig.cmake)
SET(TFramework_EXPECTED
TFramework.framework/Versions/A/Resources/CMake/TFrameworkConfig.cmake)
diff --git a/Tests/FindPackageTest/lib/Blub/BlubConfig.cmake
b/Tests/FindPackageTest/lib/Blub/BlubConfig.cmake
new file mode 100644
index 000..deffa57
--- /dev/null
+++ b/Tests/FindPackageTest/lib/Blub/BlubConfig.cmake
@@ -0,0 +1 @@
+# Test config file.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a66df0854361479bbfece06e4c0d9d975c084e71
commit a66df0854361479bbfece06e4c0d9d975c084e71
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Jun 16 22:13:00 2011 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Jun 23 11:09:41 2011 +0200
Add documentation for the CMAKE_DISABLE_FIND_PACKAGE_Name switch
Alex
diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index ea25e60..4e75f9c 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -719,6 +719,20 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
Variables That Change Behavior);
cm-DefineProperty
+(CMAKE_DISABLE_FIND_PACKAGE_PackageName, cmProperty::VARIABLE,
+ Variable for disabling find_package() calls.,
+ Every non-REQUIRED find_package() call in a project can be disabled
+ by setting the variable CMAKE_DISABLE_FIND_PACKAGE_PackageName to
+ TRUE. This can be used to build a project without an optional package,
+ although that package is installed.\n
+ This switch should be used during the initial CMake run. Otherwise if
+ the package has already been found in a previous CMake run, the
+ variables which have been stored in the cache will still be there.
+ In the case it is recommended to remove the cache variables for
+ this package from the cache using the cache editor or cmake -U, false,
+ Variables That Change Behavior);
+
+ cm-DefineProperty
(CMAKE_USER_MAKE_RULES_OVERRIDE, cmProperty::VARIABLE,
Specify a CMake file that overrides platform information.,
CMake loads the specified file while enabling support for each
diff --git
[Cmake-commits] CMake branch, next, updated. v2.8.4-1820-g8eef0ba
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 8eef0ba1321f8c995d1b3852206bd631351731a6 (commit)
via 8555c2b4b768037a37705ef7f2486149ae3cdc13 (commit)
from d9e32669c6492a3650ce46ac00f129d0c0168b0b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8eef0ba1321f8c995d1b3852206bd631351731a6
commit 8eef0ba1321f8c995d1b3852206bd631351731a6
Merge: d9e3266 8555c2b
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Thu Jun 23 15:31:48 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jun 23 15:31:48 2011 -0400
Merge topic 'use_devenv_forvs2010' into next
8555c2b Look for VCExpress as a possible build tool as well as devenv.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8555c2b4b768037a37705ef7f2486149ae3cdc13
commit 8555c2b4b768037a37705ef7f2486149ae3cdc13
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Thu Jun 23 15:29:25 2011 -0400
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Thu Jun 23 15:29:25 2011 -0400
Look for VCExpress as a possible build tool as well as devenv.
diff --git a/Source/cmGlobalVisualStudio10Generator.cxx
b/Source/cmGlobalVisualStudio10Generator.cxx
index 6c3c1ed..328a3da 100644
--- a/Source/cmGlobalVisualStudio10Generator.cxx
+++ b/Source/cmGlobalVisualStudio10Generator.cxx
@@ -123,7 +123,8 @@ std::string cmGlobalVisualStudio10Generator
cmSystemTools::LowerCase(lowerCaseCommand);
// If makeProgram is devenv, parent class knows how to generate command:
- if (lowerCaseCommand.find(devenv) != std::string::npos)
+ if (lowerCaseCommand.find(devenv) != std::string::npos ||
+ lowerCaseCommand.find(VCExpress) != std::string::npos)
{
return cmGlobalVisualStudio7Generator::GenerateBuildCommand(makeProgram,
projectName, additionalOptions, targetName, config, ignoreErrors, fast);
---
Summary of changes:
Source/cmGlobalVisualStudio10Generator.cxx |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.4-596-g26607e9
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 26607e9ae32ab8e62a94cbf9b93f8653a3a7756a (commit) from 672b6ca5e431f511f2638511b0128b6956f3e3ad (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26607e9ae32ab8e62a94cbf9b93f8653a3a7756a commit 26607e9ae32ab8e62a94cbf9b93f8653a3a7756a Author: KWSys Robot kwro...@kitware.com AuthorDate: Fri Jun 24 00:01:28 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Fri Jun 24 00:12:38 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index e3f4108..e5193b4 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 06) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 23) +SET(KWSYS_DATE_STAMP_DAY 24) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
