Re: [CMake] feedback on fortran support
On Tue, Dec 2, 2008 at 11:31 PM, Daniel Franke [EMAIL PROTECTED] wrote: ... 2. Fortran does not have any concept of preprocessing. However, by convention, files with a capital suffix (.F, .FOR, .FPP, .F90, F03, ...) are preprocessed, usually by a C-preprocessor. How do you do that on case-insensitive file system ? -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to find fortran library
Hi all, I have a project that links to another project built with Fortran. My own project is a C++ project and I usually need to link against a fortran library of some sort to use the first one. I use gcc, so it usually is libgfortran or libg2c. Now my question is: if I enable Fortran, will there be a variable that tells me the location of the library I need to link to? What I do at the moment is that I guess which library I need to link to based on the Fortran compiler's name and, since I use gcc, try to find it in the path given by 'gcc -print-search-dirs'. Is this the right way? I would expect that cmake defines a variable with this information somewhere. thanks, Javier ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Rebuild target when external library changes?
Lezz Giles wrote: I have a project set up that imports libraries, and I want to relink if those imported libraries change; For example, in a directory I have hellow.c libfred.a CMakeLists.txt where CMakeLists.txt contains: - LINK_DIRECTORIES(.) ADD_EXECUTABLE(hellow hellow.c) TARGET_LINK_LIBRARIES(hellow fred) - I run 'cmake .' Now if I touch hellow.c, hellow rebuilds, but if I touch libfred.a then hellow doesn't rebuild. This is related to my question and partial solution in the thread [CMake] To specify dependency to other library started 29/11 2008 http://www.cmake.org/pipermail/cmake/2008-November/025661.html http://www.cmake.org/pipermail/cmake/2008-December/025716.html begin:vcard fn:Per Rosengren n:Rosengren;Per org:Royal Institute of Technology (KTH);Computational Vision and Active Perception Laboratory adr:;;Teknikringen 14, room 621;Stockholm;;11428;Sweden email;internet:[EMAIL PROTECTED] title:Ph.D. student tel;work:+46 8 7906203 note:PGP keyID: 0xD40DD8E0 x-mozilla-html:FALSE url:http://www.csc.kth.se/~perrose/ version:2.1 end:vcard signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Rebuild target when external library changes?
Hugo Heden wrote: Is there a reason for why CMake does not complain about the OP:s suggestion, TARGET_LINK_LIBRARIES(hellow fred)? In general, I would want CMake to be stricter and complain more, to make it faster catching bugs like this . Is there a way (a command line flag, a variable or something) to make CMake stricter? The code you had was valid. If CMake complained about every external library that was used without a full path 90% of the projects would be complaining. Take for instance linking in libm on a unix machine. target_link_libraries(foo m) Many times this is a built in library, and you do not want to attempt to specify the full path to the library. If you did, you would have to understand way too much about how each compiler figures stuff like that out. However, I suppose it would not be that hard to add a global property that gave a warning for all non-full path library links. I am just not sure how useful it would be. However, as a matter of style it is certainly preferable to specify a full path to as many libraries as you can. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Rebuild target when external library changes?
One question, one suggestion: If I do specify full paths, doesn't that mean that I'm forcing cmake to use static linking? Doesn't this preclude one of the advantages of cmake - that it's easy to switch from static to dynamic linking? (Not that I'm complaining! I'm definitely going to use Bill's solution.) And how about this behaviour: - if TARGET_LINK_LIBRARIES() is given a full path or the name of a library that it knows about, the dependency is created (in other words, no change), - if it is given a library name that it doesn't know about, it uses the standard method to find the library and adds the dependency (new behaviour), - if it can't find the library then it prints a warning (new behaviour), and finally - this behaviour is added to the documentation (which currently doesn't show TARGET_LINK_LIBRARIES being given pathnames, just library names, and which also doesn't mention TARGET_LINK_LIBRARIES adding dependencies at all). Lezz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Hoffman Sent: Wednesday, December 03, 2008 9:23 AM To: cmake@cmake.org Subject: Re: [CMake] Rebuild target when external library changes? Hugo Heden wrote: Is there a reason for why CMake does not complain about the OP:s suggestion, TARGET_LINK_LIBRARIES(hellow fred)? In general, I would want CMake to be stricter and complain more, to make it faster catching bugs like this . Is there a way (a command line flag, a variable or something) to make CMake stricter? The code you had was valid. If CMake complained about every external library that was used without a full path 90% of the projects would be complaining. Take for instance linking in libm on a unix machine. target_link_libraries(foo m) Many times this is a built in library, and you do not want to attempt to specify the full path to the library. If you did, you would have to understand way too much about how each compiler figures stuff like that out. However, I suppose it would not be that hard to add a global property that gave a warning for all non-full path library links. I am just not sure how useful it would be. However, as a matter of style it is certainly preferable to specify a full path to as many libraries as you can. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] list( LENGTH ) problem
On Tue, Dec 2, 2008 at 3:00 PM, Alexander Neundorf
[EMAIL PROTECTED]wrote:
It expects a variable which holds a list:
set(myList foo bar)
list( LENGTH myList listlen )
message( ${listlen} )
(didn't test or check docs, but I think that should be it)
Why did you do:
list( LENGTH myList listlen )
instead of:
list( LENGTH ${myList} listlen )
This seems pretty inconsistent with how I pass variables into functions in
other places, like message() for example.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] More problems with list()...
Hi,
I have the following macro:
macro( library_component project_name )
if( ${ARGC} EQUAL 2 )
list( GET ARGN 0 component_dependencies )
endif()
endmacro()
I call the macro like this:
library_component( myProjectName item1 )
The conditional in the macro above checks to see if the 1st optional
argument has been specified. If so, I proceed to obtain that argument from
the ARGN list. When I use message() to print the ARGN list, I see item1 in
the output. However, when I call list( GET ), I get NOTFOUND in the output.
Why is this not working?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake 2.6.3 RC 5
I have a release candidate (RC 5) for 2.6.3 ready for CMake. Thanks. The files can be found here: http://www.cmake.org/files/v2.6/*RC-5* The changes from 2.6.2 to 2.6.3 are as follows: Changes in CMake 2.6.3 RC 5 - add EXCLUDE, INCLUDE to ctest_test command in ctest -S scripts - Set CMAKE_SYSTEM in ctest -S scripts by reading CMakeDetermineSystem - Fix for GetLibraryNamesInternal called on imported target issue on osx - Add FortranCInterface.cmake module to discover Fortran/C interfaces - Fix Fortran compiler specified with -D issue - Add support for the MS masm and masm64 assemblers, works with nmake/make - Improvments to FindQt4.cmake - InstallRequiredSystemLibraries fix for win64 - Fix flags for Sun Fortran, and g77 - Fix imported library issue with OSX - Fix -D and CACHE FORCE issue - Have kwsys submit dashboards to cdash.org Changes in CMake 2.6.3 RC 4 - Fix for SccProvider in visual studio - fix for missing package_source target - FindQt4 QT_PHONON_MODULE_DEPENDS fixes - Fixes for GetPrerequisites.cmake system libraries on Mac and UNIX - Merge in kwsys Haiku DynaimcLoader change Changes in CMake 2.6.3 RC 3 - Merge in CMakeLists.txt curl Haiku change Changes in CMake 2.6.3 RC 2 - Merge in more Haiku changes Changes in CMake 2.6.3 RC 1 - Better reporting when nmake compiler environment is not correct - Fix bug #5936 set locale when running cvs and svn - Teach find_library to find OpenBSD-style libs (issue #3470). - Fix lib/ to lib/64/ search path conversion - Fix CPack DESTDIR issue - Support longer command lines with windows nmake and make - Fix bug with color check for dependency scanning - Use new link info during dependency scanning - Fix find_* search order with path suffixes - Fix install with multiple configurations and makefiles. - Improve find_package interface for recursive find modules. - Fix build issues with older visual studio versions - Fix Xcode release builds - Put custom target sources in Xcode projects - Fix return value from cmake -E time commands - Fix documentation for cmake --debug-trycompile - Add Haiku support - Fix bug, allow enable_language to be called for C after CXX - Add FindCoin3D.cmake - Fix bug in FindGLUT.cmake - Better find of perl in FindPerlLibs.cmake - FindQt4 Fix #7784, Fix #7433 - FindQt4 refind qt when qmake changes - Fix to find wxWidgets_LIB_DIR for windows platform more generally. - Find ttkstup in FindTclStub.cmake - Skip a command if its arguments fail to parse - Fix convenience rule working directory - Add support for source code control and visual stuido - Add parenthetical expressions to if - Fix Rc command with -D options and nmake - Fix NSIS detection on windows 2000 - Display an error message in ccmake when there are errors -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] More problems with list()...
On Wednesday 03 December 2008, Robert Dailey wrote:
Hi,
I have the following macro:
macro( library_component project_name )
if( ${ARGC} EQUAL 2 )
list( GET ARGN 0 component_dependencies )
endif()
endmacro()
I call the macro like this:
library_component( myProjectName item1 )
The conditional in the macro above checks to see if the 1st optional
argument has been specified. If so, I proceed to obtain that argument from
the ARGN list. When I use message() to print the ARGN list, I see item1
in the output. However, when I call list( GET ), I get NOTFOUND in the
output. Why is this not working?
I think ARGN and ARGV are handled in a special way, so try if turning it into
a normal variable works, something like
set(tmp ${ARGN})
list( GET tmp 0 component_dependencies )
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] More problems with list()...
On Wed, Dec 3, 2008 at 10:42 AM, Alexander Neundorf [EMAIL PROTECTED]
wrote:
I think ARGN and ARGV are handled in a special way, so try if turning it
into
a normal variable works, something like
set(tmp ${ARGN})
list( GET tmp 0 component_dependencies )
Wow, that actually works. That makes me indescribably sad.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Rebuild target when external library changes?
Lezz Giles wrote: One question, one suggestion: If I do specify full paths, doesn't that mean that I'm forcing cmake to use static linking? Doesn't this preclude one of the advantages of cmake - that it's easy to switch from static to dynamic linking? (Not that I'm complaining! I'm definitely going to use Bill's solution.) You are forcing CMake to use one or the other which ever is found/specified. And how about this behaviour: - if TARGET_LINK_LIBRARIES() is given a full path or the name of a library that it knows about, the dependency is created (in other words, no change), - if it is given a library name that it doesn't know about, it uses the standard method to find the library and adds the dependency (new behaviour), - if it can't find the library then it prints a warning (new behaviour), and finally - this behaviour is added to the documentation (which currently doesn't show TARGET_LINK_LIBRARIES being given pathnames, just library names, and which also doesn't mention TARGET_LINK_LIBRARIES adding dependencies at all). CMake is not a linker. If you say target_link_libraries(foo A), and A is not a CMake target, then CMake will add -lA (unix) or A.lib on windows. I don't think we really want to get into the linker emulation game. Certainly, the documentation can be changed to recommend using a full path in target_link_libraries. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] More problems with list()...
On Dec 3, 2008, at 11:29 AM, Robert Dailey wrote:
Hi,
I have the following macro:
macro( library_component project_name )
if( ${ARGC} EQUAL 2 )
list( GET ARGN 0 component_dependencies )
endif()
endmacro()
I call the macro like this:
library_component( myProjectName item1 )
The conditional in the macro above checks to see if the 1st optional
argument has been specified. If so, I proceed to obtain that
argument from the ARGN list. When I use message() to print the ARGN
list, I see item1 in the output. However, when I call list( GET ),
I get NOTFOUND in the output. Why is this not working?
Working from some of the Boost CMake implementations if you are trying
to create macros that take any number of arguments with some of them
being optional then here is some code that you might be interested in.
https://svn.boost.org/trac/boost/wiki/CMakeLibraryProject
# This utility macro determines whether a particular string value
# occurs within a list of strings:
#
# list_contains(result string_to_find arg1 arg2 arg3 ... argn)
#
# This macro sets the variable named by result equal to TRUE if
# string_to_find is found anywhere in the following arguments.
macro(list_contains var value)
set(${var})
foreach (value2 ${ARGN})
if (${value} STREQUAL ${value2})
set(${var} TRUE)
endif (${value} STREQUAL ${value2})
endforeach (value2)
endmacro(list_contains)
# This utility macro extracts the first argument from the list of
# arguments given, and places it into the variable named var.
#
# car(var arg1 arg2 ...)
macro(car var)
set(${var} ${ARGV1})
endmacro(car)
# This utility macro extracts all of the arguments given except the
# first, and places them into the variable named var.
#
# car(var arg1 arg2 ...)
macro(cdr var junk)
set(${var} ${ARGN})
endmacro(cdr)
# The PARSE_ARGUMENTS macro will take the arguments of another macro and
# define several variables. The first argument to PARSE_ARGUMENTS is a
# prefix to put on all variables it creates. The second argument is a
# list of names, and the third argument is a list of options. Both of
# these lists should be quoted. The rest of PARSE_ARGUMENTS are
# arguments from another macro to be parsed.
#
# PARSE_ARGUMENTS(prefix arg_names options arg1 arg2...)
#
# For each item in options, PARSE_ARGUMENTS will create a variable with
# that name, prefixed with prefix_. So, for example, if prefix is
# MY_MACRO and options is OPTION1;OPTION2, then PARSE_ARGUMENTS will
# create the variables MY_MACRO_OPTION1 and MY_MACRO_OPTION2. These
# variables will be set to true if the option exists in the command line
# or false otherwise.
#
# For each item in arg_names, PARSE_ARGUMENTS will create a variable
# with that name, prefixed with prefix_. Each variable will be filled
# with the arguments that occur after the given arg_name is encountered
# up to the next arg_name or the end of the arguments. All options are
# removed from these lists. PARSE_ARGUMENTS also creates a
# prefix_DEFAULT_ARGS variable containing the list of all arguments up
# to the first arg_name encountered.
MACRO(PARSE_ARGUMENTS prefix arg_names option_names)
SET(DEFAULT_ARGS)
FOREACH(arg_name ${arg_names})
SET(${prefix}_${arg_name})
ENDFOREACH(arg_name)
FOREACH(option ${option_names})
SET(${prefix}_${option} FALSE)
ENDFOREACH(option)
SET(current_arg_name DEFAULT_ARGS)
SET(current_arg_list)
FOREACH(arg ${ARGN})
LIST_CONTAINS(is_arg_name ${arg} ${arg_names})
IF (is_arg_name)
SET(${prefix}_${current_arg_name} ${current_arg_list})
SET(current_arg_name ${arg})
SET(current_arg_list)
ELSE (is_arg_name)
LIST_CONTAINS(is_option ${arg} ${option_names})
IF (is_option)
SET(${prefix}_${arg} TRUE)
ELSE (is_option)
SET(current_arg_list ${current_arg_list} ${arg})
ENDIF (is_option)
ENDIF (is_arg_name)
ENDFOREACH(arg)
SET(${prefix}_${current_arg_name} ${current_arg_list})
ENDMACRO(PARSE_ARGUMENTS)
#- And Now finally your macro can use it like the following:
macro(library_component project_name)
parse_arguments(THIS_PROJECT
DEPENDENCIES
SOME_OPTION
${ARGN}
)
message(STATUS THIS_PROJECT_DEPENDENCIES: $
{THIS_PROJECT_DEPENDENCIES})
list(LENGTH THIS_PROJECT_DEPENDENCIES THIS_PROJECT_DEPENDENCIES_NUM)
if (THIS_PROJECT_DEPENDENCIES_NUM EQUAL 1)
set(THIS_PROJECT_DESCRIPTION ${THIS_PROJECT_DESCRIPTION}\n
\nAuthor: )
else()
set(THIS_PROJECT_DESCRIPTION ${THIS_PROJECT_DESCRIPTION}\n
\nAuthors: )
endif()
macro(library_component project_name)
#--- and you should be able to call it like this:
library_component(MyNewLibrary DEPENDENCIES item1)
library_component(MyOtherLibrary DEPENDENCIES item1 item2 SOME_OPTION)
HTH
__
Mike Jackson [EMAIL PROTECTED]
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
Re: [CMake] cmake 2.6.3 RC 5
On Wednesday 03 December 2008 16:36:23 Bill Hoffman wrote: I have a release candidate (RC 5) for 2.6.3 ready for CMake. Did my PATCH: Bundle Generator need not require CPACK_BUNDLE_STARTUP_COMMAND ever get applied for 2.6.3? -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] More problems with list()...
On Wed, Dec 3, 2008 at 11:05 AM, Michael Jackson [EMAIL PROTECTED] wrote: Working from some of the Boost CMake implementations if you are trying to create macros that take any number of arguments with some of them being optional then here is some code that you might be interested in. https://svn.boost.org/trac/boost/wiki/CMakeLibraryProject snip #- And Now finally your macro can use it like the following: snip macro(library_component project_name) #--- and you should be able to call it like this: library_component(MyNewLibrary DEPENDENCIES item1) library_component(MyOtherLibrary DEPENDENCIES item1 item2 SOME_OPTION) Thanks Michael! This is great stuff and will help me simplify things. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
Mike Arthur wrote: On Wednesday 03 December 2008 16:36:23 Bill Hoffman wrote: I have a release candidate (RC 5) for 2.6.3 ready for CMake. Did my PATCH: Bundle Generator need not require CPACK_BUNDLE_STARTUP_COMMAND ever get applied for 2.6.3? I don't think so... Is it in CVS CMake yet? What is the bug entry for it? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
Robert Dailey wrote: Well, good news and bad news on this subject. The good news is that I managed to get my includes working in my initial case. I had my includes.cmake file in the wrong directory The bad news is now I'm having another issue with include(), and this time I DO have my cmake files in the correct directory. I have a file called utility.cmake which has a couple of Boost CMake utility functions in it that I'm borrowing, PARSE_ARGUMENTS() being one of them. When I do include( utility.cmake ) it works fine and I get no errors when I include it, however when I try to call parse_arguments() in the CMakeLists.txt file that's performing the include() it says: /*Unknown CMake command parse_arguments.*/ Any idea why it can't find that macro? Maybe it finds the wrong utility.cmake file? Try adding some message(here) type stuff to make sure the correct files are being loaded. With cmake 2.6.2 you can run cmake --trace to see all the files and commands as they are run by cmake. Should help you find the problem pretty quick. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
2008/12/3 Bill Hoffman [EMAIL PROTECTED]: I have a release candidate (RC 5) for 2.6.3 ready for CMake. I think the following patch http://public.kitware.com/Bug/view.php?id=7904 deserve inclusion since it is fully backward compatible and adds a requested feature. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
On Wed, Dec 3, 2008 at 1:18 PM, Bill Hoffman [EMAIL PROTECTED]wrote: Maybe it finds the wrong utility.cmake file? Try adding some message(here) type stuff to make sure the correct files are being loaded. With cmake 2.6.2 you can run cmake --trace to see all the files and commands as they are run by cmake. Should help you find the problem pretty quick. I did as you suggested and added a message() call inside of utility.cmake and I see it printed when I run CMake. So this means I'm loading the correct file then? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
On Wed, Dec 3, 2008 at 1:55 PM, Bill Hoffman [EMAIL PROTECTED]wrote:
Did you try the --trace? Maybe a spelling error? Please post a complete
small example that shows the problem if none of that helps.
Below is the relevant portion of the output from --trace. It's a bit hard to
read, but notice that after the include( utility.cmake ) line there is no
code included. Odd.
C:/IT/work/jewett/CMakeLists.txt(1): cmake_minimum_required(VERSION 2.6 )
C:/IT/work/jewett/CMakeLists.txt(5): set(third_party
${CMAKE_CURRENT_SOURCE_DIR}/third_party )
C:/IT/work/jewett/CMakeLists.txt(7): add_subdirectory(vfx )
C:/IT/work/jewett/vfx/CMakeLists.txt(1): cmake_minimum_required(VERSION 2.6
)
C:/IT/work/jewett/vfx/CMakeLists.txt(3): project(vfx )
C:/IT/work/jewett/vfx/CMakeLists.txt(5): include(utility.cmake )
C:/IT/work/jewett/vfx/CMakeLists.txt(6): include(include_directories.cmake
)
C:/IT/work/jewett/vfx/include_directories.cmake(1): set(include_directories
${third_party}/.. ${thi
rd_party}/boost/1_36_0 ${third_party}/boost/sandbox/channel
${third_party}/boost/sandbox/chrono ${th
ird_party}/boost/sandbox/dataflow ${third_party}/boost/sandbox/dispatcher
${third_party}/boost/sandb
ox/extension ${third_party}/boost/sandbox/flyweight
${third_party}/boost/sandbox/move ${third_party}
/boost/sandbox/tree ${third_party}/boost/sandbox/unique_ptr
${third_party}/cg/include ${third_party}
/Eigen ${third_party}/EMotionFX/Source ${third_party}/fmod/include
${third_party}/FreeImage ${third_
party}/glew ${third_party}/glib/include ${third_party}/glibmm/include
${third_party}/glut ${third_pa
rty}/iconv/include ${third_party}/libRocket/include
${third_party}/libxml2/include ${third_party}/li
bxml++/include ${third_party}/OpenSSL/include ${third_party}/python/inc
${third_party}/tbb/21_200806
05oss/include ${third_party}/VisualLeakDetector/include
${third_party}/zlib/include )
C:/IT/work/jewett/vfx/CMakeLists.txt(7): include(link_directories.cmake )
C:/IT/work/jewett/vfx/link_directories.cmake(1): set(link_directories
${third_party}/boost/1_36_0/l
ib ${third_party}/cg/lib ${third_party}/EMotionFX/Bin
${third_party}/EMotionFX/Core/Bin ${third_part
y}/fmod/lib ${third_party}/FreeImage ${third_party}/glew
${third_party}/glib/lib ${third_party}/glib
mm/lib ${third_party}/glut ${third_party}/iconv/lib
${third_party}/libRocket/bin ${third_party}/libx
ml2/lib ${third_party}/libxml++/lib ${third_party}/python/lib
${third_party}/zlib/lib )
C:/IT/work/jewett/vfx/CMakeLists.txt(11): macro(create_test project_name )
C:/IT/work/jewett/vfx/CMakeLists.txt(22): macro(component project_name )
C:/IT/work/jewett/vfx/CMakeLists.txt(43): macro(library_component
project_name )
C:/IT/work/jewett/vfx/CMakeLists.txt(60): macro(executable_component
project_name libraries )
C:/IT/work/jewett/vfx/CMakeLists.txt(69): add_subdirectory(messenger )
C:/IT/work/jewett/vfx/messenger/CMakeLists.txt(1):
library_component(messenger )
CMake Error at vfx/CMakeLists.txt:44 (parse_arguments):
Unknown CMake command parse_arguments.
Call Stack (most recent call first):
vfx/messenger/CMakeLists.txt:1 (library_component)
-- Configuring incomplete, errors occurred!
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
On Wed, Dec 3, 2008 at 2:19 PM, Bill Hoffman [EMAIL PROTECTED]wrote:
Robert Dailey wrote:
On Wed, Dec 3, 2008 at 1:55 PM, Bill Hoffman [EMAIL PROTECTED]mailto:
[EMAIL PROTECTED] wrote:
Did you try the --trace? Maybe a spelling error? Please post a
complete small example that shows the problem if none of that helps.
Below is the relevant portion of the output from --trace. It's a bit hard
to read, but notice that after the include( utility.cmake ) line there is no
code included. Odd.
Do you still have the message in the utility.cmake?
That should show up in the trace??
lol. I actually removed it on accident. I can't seem to get this right,
sorry. Below is the trace output with the message() back in:
C:/IT/work/jewett/CMakeLists.txt(1): cmake_minimum_required(VERSION 2.6 )
C:/IT/work/jewett/CMakeLists.txt(5): set(third_party
${CMAKE_CURRENT_SOURCE_DIR}/third_party )
C:/IT/work/jewett/CMakeLists.txt(7): add_subdirectory(vfx )
C:/IT/work/jewett/vfx/CMakeLists.txt(1): cmake_minimum_required(VERSION 2.6
)
C:/IT/work/jewett/vfx/CMakeLists.txt(3): project(vfx )
C:/IT/work/jewett/vfx/CMakeLists.txt(5): include(utility.cmake )
C:/IT/work/jewett/vfx/utility.cmake(1): message(utility.cmake loaded )
utility.cmake loaded
C:/IT/work/jewett/vfx/CMakeLists.txt(6): include(include_directories.cmake
)
C:/IT/work/jewett/vfx/include_directories.cmake(1): set(include_directories
${third_party}/.. ${thi
rd_party}/boost/1_36_0 ${third_party}/boost/sandbox/channel
${third_party}/boost/sandbox/chrono ${th
ird_party}/boost/sandbox/dataflow ${third_party}/boost/sandbox/dispatcher
${third_party}/boost/sandb
ox/extension ${third_party}/boost/sandbox/flyweight
${third_party}/boost/sandbox/move ${third_party}
/boost/sandbox/tree ${third_party}/boost/sandbox/unique_ptr
${third_party}/cg/include ${third_party}
/Eigen ${third_party}/EMotionFX/Source ${third_party}/fmod/include
${third_party}/FreeImage ${third_
party}/glew ${third_party}/glib/include ${third_party}/glibmm/include
${third_party}/glut ${third_pa
rty}/iconv/include ${third_party}/libRocket/include
${third_party}/libxml2/include ${third_party}/li
bxml++/include ${third_party}/OpenSSL/include ${third_party}/python/inc
${third_party}/tbb/21_200806
05oss/include ${third_party}/VisualLeakDetector/include
${third_party}/zlib/include )
C:/IT/work/jewett/vfx/CMakeLists.txt(7): include(link_directories.cmake )
C:/IT/work/jewett/vfx/link_directories.cmake(1): set(link_directories
${third_party}/boost/1_36_0/l
ib ${third_party}/cg/lib ${third_party}/EMotionFX/Bin
${third_party}/EMotionFX/Core/Bin ${third_part
y}/fmod/lib ${third_party}/FreeImage ${third_party}/glew
${third_party}/glib/lib ${third_party}/glib
mm/lib ${third_party}/glut ${third_party}/iconv/lib
${third_party}/libRocket/bin ${third_party}/libx
ml2/lib ${third_party}/libxml++/lib ${third_party}/python/lib
${third_party}/zlib/lib )
C:/IT/work/jewett/vfx/CMakeLists.txt(11): macro(create_test project_name )
C:/IT/work/jewett/vfx/CMakeLists.txt(22): macro(component project_name )
C:/IT/work/jewett/vfx/CMakeLists.txt(43): macro(library_component
project_name )
C:/IT/work/jewett/vfx/CMakeLists.txt(60): macro(executable_component
project_name libraries )
C:/IT/work/jewett/vfx/CMakeLists.txt(69): add_subdirectory(messenger )
C:/IT/work/jewett/vfx/messenger/CMakeLists.txt(1):
library_component(messenger )
CMake Error at vfx/CMakeLists.txt:44 (parse_arguments):
Unknown CMake command parse_arguments.
Call Stack (most recent call first):
vfx/messenger/CMakeLists.txt:1 (library_component)
-- Configuring incomplete, errors occurred!
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
Robert Dailey wrote:
lol. I actually removed it on accident. I can't seem to get this right,
sorry. Below is the trace output with the message() back in:
C:/IT/work/jewett/CMakeLists.txt(1): cmake_minimum_required(VERSION 2.6 )
C:/IT/work/jewett/CMakeLists.txt(5): set(third_party
${CMAKE_CURRENT_SOURCE_DIR}/third_party )
C:/IT/work/jewett/CMakeLists.txt(7): add_subdirectory(vfx )
C:/IT/work/jewett/vfx/CMakeLists.txt(1): cmake_minimum_required(VERSION
2.6 )
C:/IT/work/jewett/vfx/CMakeLists.txt(3): project(vfx )
C:/IT/work/jewett/vfx/CMakeLists.txt(5): include(utility.cmake )
C:/IT/work/jewett/vfx/utility.cmake(1): message(utility.cmake loaded )
utility.cmake loaded
C:/IT/work/jewett/vfx/CMakeLists.txt(6):
include(include_directories.cmake )
Seems to be the only thing in the file. Maybe it would help if you
posted utility.cmake...
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
On Wed, Dec 3, 2008 at 2:33 PM, Bill Hoffman [EMAIL PROTECTED]wrote: Seems to be the only thing in the file. Maybe it would help if you posted utility.cmake... It's attached. utility.cmake Description: Binary data ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
Robert Dailey wrote: On Wed, Dec 3, 2008 at 2:33 PM, Bill Hoffman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Seems to be the only thing in the file. Maybe it would help if you posted utility.cmake... It's attached. Found it... The file has mac format line endings. If I change it to unix or windows line feeds it works fine. The mac file format must fool the parser into only reading one line of the file and thinking that it is all done. That first message statement was the only thing that was being run. (which is why trace did not show anything...) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How do you determine what compiler is being used?
Hello, How can determine what general type of compiler is being used? For example, how can we determine if our project is being configured to use the Sun CC compiler? In C++ code I can just check for the define __sun but how can I get this info in my CMakeLists.txt file? I could use try_compile(...) to figure this out but is there already a way to do this? - Ross ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Why does dependency scanning in version 2.6 seem so slow?
Hi folks, Is there a way to speed up the dependency scan in version 2.6? I recently installed a new Linux OS (Mandriva 2009) which included an upgrade to cmake 2.6 (I _think_ I had version 2.4 before). However, when I run make (after running cmake .) it takes a long time (1min) to do the dependency scan. (i.e. the time when the message Scanning dependencies of target foo is printed) whereas the rest of the build takes about 10 seconds. This happens every time I run make but it does successfully build (and the cmake . step is fast). The odd thing is that it was almost instantaneous (with essentially the same code) under version 2.4 and is almost instantaneous on a (faster) mac (again, with the same code). Is there any way to speed this up without using the make foo/fast option every time? Thank you very much for your consideration, Mark Pearson (a few more details that might be relevant follow)... My project is quite simple but makes use of the STL, gnu scientific library (gsl) and boost. Specifically, it includes the following: #include iostream #include fstream #include sstream #include stdio.h #include math.h #include vector #include string #include unistd.h #include gsl/gsl_statistics_double.h #include gsl/gsl_rng.h #include gsl/gsl_randist.h #include boost/numeric/ublas/matrix.hpp #include boost/numeric/ublas/io.hpp #include boost/program_options.hpp ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] FIND_LIBRARY not using CMAKE_FIND_LIBRARY_SUFFIXES
Hi, I am using Cygwin on Windows, using CMake 2.6.2. I was originally debugging FindBoost, when I narrowed the problem down to FIND_LIBRARY. This simple statement does not find the library: SET (CMAKE_FIND_LIBRARY_SUFFIXES .a) FIND_LIBRARY(NAMES test HINTS /usr/local/lib) However, this works: FIND_LIBRARY(NAMES test.a HINTS /usr/local/lib) Is this a known bug (that's only prevalent on Cygwin)? To solve my problem with FindBoost, I had to manually add in the .a into the FIND_LIBRARY command. Thanks, Oliver ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why does dependency scanning in version 2.6 seem so slow?
2008/12/3 Senanu Pearson [EMAIL PROTECTED]: Hi folks, Is there a way to speed up the dependency scan in version 2.6? I recently installed a new Linux OS (Mandriva 2009) which included an upgrade to cmake 2.6 (I _think_ I had version 2.4 before). However, when I run make (after running cmake .) it takes a long time (1min) to do the dependency scan. (i.e. the time when the message Scanning dependencies of target foo is printed) whereas the rest of the build takes about 10 seconds. This happens every time I run make but it does successfully build (and the cmake . step is fast). I did not experienced such slow down when going from 2.4 to 2.6 would you be able to try a CMake 2.4 on the same system? You may 1) download a tarball http://www.cmake.org/files/v2.4/cmake-2.4.8-Linux-i386.tar.gz 2) untar it somewhere, 3) update you path 4) retry the build. The odd thing is that it was almost instantaneous (with essentially the same code) under version 2.4 and is almost instantaneous on a (faster) mac (again, with the same code). CMake is not the only thing which have changed then: - system - compiler -- this may be important. - disk speed, cpu, ..; -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How do you determine what compiler is being used?
2008/12/3 Bartlett, Roscoe A [EMAIL PROTECTED]: Hello, How can determine what general type of compiler is being used? For example, how can we determine if our project is being configured to use the Sun CC compiler? In C++ code I can just check for the define __sun but how can I get this info in my CMakeLists.txt file? I could use try_compile(...) to figure this out but is there already a way to do this? There are some variables like CMAKE_COMPILER_IS_GNUCC MINGW MSVC but there is nothing for Sun CC http://www.cmake.org/Wiki/CMake_Useful_Variables You may guess it using CMAKE_C_COMPILER which contains the full path to the compiler. may be the set of recognized compilers may be enhanced using macro predefined by those compilers: http://predef.sourceforge.net/precomp.html -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How do you determine what compiler is being used?
Here is some CMake code that I wrote to determine this:
# Determine compiler version
INCLUDE(CheckCXXSourceCompiles)
CHECK_CXX_SOURCE_COMPILES(
int main() {
#ifdef __sun
// This is the SUN!
#else
THIS IS NOT THE SUN
#endif
return 0;
}
Trilinos_USING_SUN_COMPILER
)
I was going to put this into a module called CheckCXXDefineExists.cmake with
the function CHECK_CXX_DEFINE_EXISTS(...) that would be used like:
CHECK_CXX_DEFINE_EXISTS(__sun Trilinos_USING_SUN_COMPILER)
CMake does not appear to have a module/macro like this.
Should I define this module/function and would CMake like to have it to add to
its sources?
- Ross
-Original Message-
From: Eric Noulard [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2008 4:06 PM
To: Bartlett, Roscoe A
Cc: cmake@cmake.org; Pawlowski, Roger P
Subject: Re: [CMake] How do you determine what compiler is being used?
2008/12/3 Bartlett, Roscoe A [EMAIL PROTECTED]:
Hello,
How can determine what general type of compiler is being used? For
example, how can we determine if our project is being configured to
use the Sun CC compiler? In C++ code I can just check for
the define
__sun but how can I get this info in my CMakeLists.txt
file? I could
use try_compile(...) to figure this out but is there
already a way to do this?
There are some variables like
CMAKE_COMPILER_IS_GNUCC
MINGW
MSVC
but there is nothing for Sun CC
http://www.cmake.org/Wiki/CMake_Useful_Variables
You may guess it using
CMAKE_C_COMPILER
which contains the full path to the compiler.
may be the set of recognized compilers may be enhanced using
macro predefined by those compilers:
http://predef.sourceforge.net/precomp.html
--
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
On Wed, Dec 3, 2008 at 2:53 PM, Bill Hoffman [EMAIL PROTECTED]wrote: Found it... The file has mac format line endings. If I change it to unix or windows line feeds it works fine. The mac file format must fool the parser into only reading one line of the file and thinking that it is all done. That first message statement was the only thing that was being run. (which is why trace did not show anything...) Thanks for looking into this for me, I really appreciate it. This sounds like a bug to me, as the CMake program didn't give me any hint as to what the problem was. I hope this is fixed later! ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Getting a list of the defined CMake cache variables along with properties and documentation?
Hello, Is there a way in a CMakeLists.txt file to get a list of all of the defined CMake cache variables, get their properties, and their documentation? I would like to have this so that I can build more general documentation for our CMake project. I could of course just parse the CMakeCache.txt file myself but if there is a way to do this in CMake then that might be better. Otherwise, I will need to create a tool that would do a configure, then read the CMakeCache.txt file and build documentation output like you would see for our current autotools build system. Thanks, - Ross - Dr. Roscoe A. Bartlett Senior Member of the Technical Staff Trilinos Software Engineering Technologies and Integration Lead Sandia National Laboratories Phone: (505) 275-6147 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]
Hi folks, Is there a way to speed up the dependency scan in version 2.6? I recently installed a new Linux OS (Mandriva 2009) which included an upgrade to cmake 2.6 (I _think_ I had version 2.4 before). However, when I run make (after running cmake .) it takes a long time (1min) to do the dependency scan. (i.e. the time when the message Scanning dependencies of target foo is printed) whereas the rest of the build takes about 10 seconds. This happens every time I run make but it does successfully build (and the cmake . step is fast). I did not experienced such slow down when going from 2.4 to 2.6 would you be able to try a CMake 2.4 on the same system? You may 1) download a tarball http://www.cmake.org/files/v2.4/cmake-2.4.8-Linux-i386.tar.gz 2) untar it somewhere, 3) update you path 4) retry the build. The odd thing is that it was almost instantaneous (with essentially the same code) under version 2.4 and is almost instantaneous on a (faster) mac (again, with the same code). CMake is not the only thing which have changed then: - system - compiler -- this may be important. - disk speed, cpu, ..; -- Erk Erk, Yes, you are right - the 2.4 build doesn't seem to be any faster. All my hardware is the same but I'm using gcc 4.3.2 and KDE4. Still, it seems strange that it is so incredibly slow. Unless anyone can offer a better solution, I'm inclined to simply switch targets in the Makefile so that I can get a quick build without having to do quite as much typing every time (yeah, and break my habit, too). Thank you, Mark ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]
If this helps anyone, I'm working on a large project using CMake and in two different computers, both with the same version of Ubuntu and cmake, it is *REALLY SLOW* in only one of them while scanning dependencies, but it's not in the other laptop. (The slow dep. scanning is ~1 min. too) I'd be happy to help debugging this, because it's really annoying :-( Regards, Jose Luis On Thu, Dec 4, 2008 at 12:46 AM, Senanu Pearson [EMAIL PROTECTED]wrote: Hi folks, Is there a way to speed up the dependency scan in version 2.6? I recently installed a new Linux OS (Mandriva 2009) which included an upgrade to cmake 2.6 (I _think_ I had version 2.4 before). However, when I run make (after running cmake .) it takes a long time (1min) to do the dependency scan. (i.e. the time when the message Scanning dependencies of target foo is printed) whereas the rest of the build takes about 10 seconds. This happens every time I run make but it does successfully build (and the cmake . step is fast). I did not experienced such slow down when going from 2.4 to 2.6 would you be able to try a CMake 2.4 on the same system? You may 1) download a tarball http://www.cmake.org/files/v2.4/cmake-2.4.8-Linux-i386.tar.gz 2) untar it somewhere, 3) update you path 4) retry the build. The odd thing is that it was almost instantaneous (with essentially the same code) under version 2.4 and is almost instantaneous on a (faster) mac (again, with the same code). CMake is not the only thing which have changed then: - system - compiler -- this may be important. - disk speed, cpu, ..; -- Erk Erk, Yes, you are right - the 2.4 build doesn't seem to be any faster. All my hardware is the same but I'm using gcc 4.3.2 and KDE4. Still, it seems strange that it is so incredibly slow. Unless anyone can offer a better solution, I'm inclined to simply switch targets in the Makefile so that I can get a quick build without having to do quite as much typing every time (yeah, and break my habit, too). Thank you, Mark ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- ___ Jose-Luis Blanco-Claraco Phone: +34 952 132848 Dpto. Ingenieria de Sistemas y Automatica E.T.S.I. Telecomunicacion Fax: +34 952 133361 Universidad de Malaga Campus Universitario de Teatinos 29071 Malaga, Spain http://www.isa.uma.es/jlblanco ___ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
Robert Dailey wrote: On Wed, Dec 3, 2008 at 2:53 PM, Bill Hoffman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Found it... The file has mac format line endings. If I change it to unix or windows line feeds it works fine. The mac file format must fool the parser into only reading one line of the file and thinking that it is all done. That first message statement was the only thing that was being run. (which is why trace did not show anything...) Thanks for looking into this for me, I really appreciate it. This sounds like a bug to me, as the CMake program didn't give me any hint as to what the problem was. I hope this is fixed later! Perhaps a bug in the standard c++ library streams... But really who creates text files in this format anymore? I think you have to go back to pre-OSX days to get files like this by default. I will check to see if there is a quick fix, but I am guessing most text based programs would yack on this file -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
On Dec 3, 2008, at 8:42 PM, Bill Hoffman wrote: Robert Dailey wrote: On Wed, Dec 3, 2008 at 2:53 PM, Bill Hoffman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Found it... The file has mac format line endings. If I change it to unix or windows line feeds it works fine. The mac file format must fool the parser into only reading one line of the file and thinking that it is all done. That first message statement was the only thing that was being run. (which is why trace did not show anything...) Thanks for looking into this for me, I really appreciate it. This sounds like a bug to me, as the CMake program didn't give me any hint as to what the problem was. I hope this is fixed later! Perhaps a bug in the standard c++ library streams... But really who creates text files in this format anymore? I think you have to go back to pre-OSX days to get files like this by default. I will check to see if there is a quick fix, but I am guessing most text based programs would yack on this file -Bill Actaully, on OS X some of the text editors including BBEdit and TextMate and Eclipse all give you the option of setting your line endings to mac, dos or unix. In some of those the defaults are mac which is /r/n. It is up to the user to set the default for new files to unix. Just FYI. _ Mike Jackson [EMAIL PROTECTED] BlueQuartz Softwarewww.bluequartz.net Principal Software Engineer Dayton, Ohio ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
Michael Jackson wrote: Actaully, on OS X some of the text editors including BBEdit and TextMate and Eclipse all give you the option of setting your line endings to mac, dos or unix. In some of those the defaults are mac which is /r/n. It is up to the user to set the default for new files to unix. \ http://en.wikipedia.org/wiki/End-of-line * LF:Multics, Unix and Unix-like systems (GNU/Linux, AIX, Xenix, Mac OS X, FreeBSD, etc.), BeOS, Amiga, RISC OS, and others * CR+LF: DEC RT-11 and most other early non-Unix, non-IBM OSes, CP/M, MP/M, DOS, OS/2, Microsoft Windows, Symbian OS * CR:Commodore machines, Apple II family, Mac OS up to version 9 and OS-9 So, it is just a \r in this file, and not a \r\n. \r\n is Windows, and unix uses \n only. I guess the problem is in the lexer CMake uses, and not the C++ library... It uses \n as the line ending. That works on but unix and windows, but not with \r only mac files. I suppose we could put a check to see if a file has no \n, but lots of \r, and complain that it is an invalid file. Robert, how did you create the file, was it the default for some editor? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]
Jose Luis Blanco wrote: If this helps anyone, I'm working on a large project using CMake and in two different computers, both with the same version of Ubuntu and cmake, it is *REALLY SLOW* in only one of them while scanning dependencies, but it's not in the other laptop. (The slow dep. scanning is ~1 min. too) I'd be happy to help debugging this, because it's really annoying :-( I wonder if it is hitting a network mount disk or something like that... Are the same versions of cmake identical binaries? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
On Wed, Dec 3, 2008 at 8:41 PM, Bill Hoffman [EMAIL PROTECTED]wrote: http://en.wikipedia.org/wiki/End-of-line * LF:Multics, Unix and Unix-like systems (GNU/Linux, AIX, Xenix, Mac OS X, FreeBSD, etc.), BeOS, Amiga, RISC OS, and others * CR+LF: DEC RT-11 and most other early non-Unix, non-IBM OSes, CP/M, MP/M, DOS, OS/2, Microsoft Windows, Symbian OS * CR:Commodore machines, Apple II family, Mac OS up to version 9 and OS-9 So, it is just a \r in this file, and not a \r\n. \r\n is Windows, and unix uses \n only. I guess the problem is in the lexer CMake uses, and not the C++ library... It uses \n as the line ending. That works on but unix and windows, but not with \r only mac files. I suppose we could put a check to see if a file has no \n, but lots of \r, and complain that it is an invalid file. Robert, how did you create the file, was it the default for some editor? The problem isn't about MAC line endings not working. I could care less about line ending requirements, I'll go with whatever works. The main problem I have is that CMake didn't TELL me what the problem was. It should have said, Hey dummy, your line endings are unacceptable. Please change them to LINUX line endings. That would have saved me hours of time! ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting a list of the defined CMake cache variables along with properties and documentation?
On Wed, Dec 3, 2008 at 9:44 PM, Bill Hoffman [EMAIL PROTECTED]wrote: Bartlett, Roscoe A wrote: Hello, Is there a way in a CMakeLists.txt file to get a list of all of the defined CMake cache variables, get their properties, and their documentation? I would like to have this so that I can build more general documentation for our CMake project. I could of course just parse the CMakeCache.txt file myself but if there is a way to do this in CMake then that might be better. Otherwise, I will need to create a tool that would do a configure, then read the CMakeCache.txt file and build documentation output like you would see for our current autotools build system. There is no such tool. There are also problems with such a tool. The main problem is the if statement. To get complete docs for a project you would have to evaluate each if both true and false to make sure you found all possible cache values for a project. It has come up on the list a few imes, but no general solution has been discovered. There is also the problem of what to do with all of the cache variables you wouldn't want in your documentation. And also what to do when you aren't happy with the docstring provided by the maintainer of FindFoo.cmake and want to override it with your own (perhaps to explain the effect of having or not having FOO_LIBRARY on your project if it's an optional dependency). That being said, it probably still would be a useful feature even if it doesn't overcome the if/else issue the first go-around. Many people would probably be OK with this limitation. Incidentally, I don't think the if() else() issue would be that hard to solve once you had a basic cache documentation generator implemented. At least there would be more of an incentive to fix this use case then. :) The simple (probably naive) approach would seem to be to just set cmIfFunctionBlocker::isBlocking always to false when the cache documentation generator is running, and see what happens. Not sure if this would work correctly or not and result in all branches being taken, but it probably would be a good start. It seems to me the hard part would be disabling all of the harmful CMake commands you wouldn't want to run while generating the documentation . And getting CMake to not save everything to the cache, and all of the other crazy stuff you wouldn't want it to do while trying to detect cache variables. (A new virtual hook on cmCommand similar to InvokeInitialPass() that gets run in the special generation mode which would either simply return or call InvokeInitialPass() would probably be a good start). Obviously a CMakeCache.txt file parser might be quicker to implement but it would have at least these drawbacks: 1. A chicken and the egg problem, a configure has to occur and CMakeCache.txt created first before you can even parse it for documentation. Depending on the system being configured generation of a CMakeCache.txt can take some time due to all of the time needed to do compilation checks, etc. It's not as if the user is going to be able to run cmake --configure-help . and have it immediately spit out documentation like GNU AutoTools prior to the user even configuring the build. There would have to be an initial delay as the cache is created. Obviously there is the apriori option here though (distribute configuration help ahead of time or require the user to configure manually first). 2. The generated documentation (as Bill alluded to) would be dependent on which branches were taken during the configure -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How do you determine what compiler is being used?
On Wed, Dec 3, 2008 at 9:48 PM, Bill Hoffman [EMAIL PROTECTED]wrote: This is already done in CMake 2.6. See Modules/CMakeCCompilerId.c.in, it is even better than the above because it works when cross compiling. It does not use a try-run, but rather a try-compile, and then it looks for strings in the executable that was created. Anyway, it is already done, and it sets the following variables: CMAKE_C_COMPILER_ID CMAKE_CXX_COMPILER_ID CMAKE_Fortran_COMPILER_ID Thanks for adding this Bill. With the exception of dealing with MinGW or differing versions of MSVC this would seem to be a very good replacement for conditionals like: IF(CMAKE_COMPILER_IS_GNUCC) IF(MSVC) Is this feature here to stay? The documentation doesn't seem very encouraging. =) - *CMAKE_LANG_COMPILER_ID*: An internal variable subject to change. This is used in determining the compiler and is subject to change. -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to find fortran library
Am Mittwoch, 3. Dezember 2008 schrieb Javier Gonzalez: Hi all, I have a project that links to another project built with Fortran. My own project is a C++ project and I usually need to link against a fortran library of some sort to use the first one. I use gcc, so it usually is libgfortran or libg2c. Now my question is: if I enable Fortran, will there be a variable that tells me the location of the library I need to link to? No. The compiler frontend (gfortran, g77, ...) makes the decision which system and compiler libraries have to be linked in. If you or cmake link an fortran executable with g77 -o myapp a.o b.o .. libg2c will be linked in by g77. When doing g77 -o myapp a.o b.o .. libgfortran will be linked in by gfortran. The same is true for g++, which links in libstdc++ by default. What I do at the moment is that I guess which library I need to link to based on the Fortran compiler's name and, since I use gcc, try to find it in the path given by 'gcc -print-search-dirs'. Is this the right way? I would expect that cmake defines a variable with this information somewhere. This is the right way. Maybe an effort to write cmake module which handles this task is worthy. Best, -- Maik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
