hello
I assign the list of all directories the names of which starts with a
pattern like pattern_ to a cmake variable which I then pass as a
preprocessor macro:
FILE(GLOB MYPROJECT_LIST_SYSTEMS RELATIVE ${CMAKE_SOURCE_DIR} system_*)
MYPROJECT_LIST_SYSTEMS is then a cmake list, a string
On Sun, Jun 27, 2010 at 11:05 AM, Hicham Mouline hic...@mouline.org wrote:
hello
I assign the list of all directories the names of which starts with a
pattern like pattern_ to a cmake variable which I then pass as a
preprocessor macro:
FILE(GLOB MYPROJECT_LIST_SYSTEMS RELATIVE
I don't expect a lot of support for what I'm about to say, but I think it's
perhaps worth saying anyway...
It seems like CMake's and CTest's have outgrown their scripting languages.
As far as I can tell, all CMake/CTest variables are either macro formal
parameters, or variables in a single
2010/6/27 Convey, Christian J CIV NUWC NWPT christian.con...@navy.mil:
I don't expect a lot of support for what I'm about to say, but I think it's
perhaps worth saying anyway...
It seems like CMake's and CTest's have outgrown their scripting languages.
As far as I can tell, all CMake/CTest
Hi Eric,
Thanks for all those details. I wasn't aware that CMake drew a distinction
between macros and functions. I'll try to have a look at the ML archives.
- Christian
-Original Message-
From: Eric Noulard [mailto:eric.noul...@gmail.com]
Sent: Sunday, June 27, 2010 16:42
To:
Your remarks focus on old-fashioned macros so it is possible you are not
aware of functions? As far as I know, most or all macros can be replaced by
functions which do have the nice property of not polluting the global
namespace. So newly developed build systems should use functions wherever
Hi Alan,
Thanks, I wasn't aware of the shift towards the use of FUNCTIONs. Because of
the developers I need to support, I've been mosting working with CMake 2.6. I
didn't realize that this was one of the things 2.8 brought to the table.
- Christian
-Original Message-
From: Alan W.
CMake 2.6 supports functions as well. CMake 2.4 doesn't, however.
I think your initial point is good one, though. There is still a significant
dependence on global variables in CMake and especially CTest. Additionally,
as has been discussed, there's not even a completely consistent naming
Hello,
I've been trying to set up CMake on different build machines.
Everything went perfectly on Linux machines (32/64bit),
however, CMake gave me the following error message during configuration on
HP IA64.
-- The C compiler identification is GNU
-- Check for working C compiler:
CMake's dependency scanner uses its own parser to scan for #include directives,
and then builds up the dependency tree this way. I know it's possible to rig up
an invocation of gcc -M to generate the correct dependencies, and then feed
this into the OBJECT_DEPENDS property of source files, but
Hello,
On Sun, Jun 27, 2010 at 05:09:41PM -0400, cmake-requ...@cmake.org wrote:
Your remarks focus on old-fashioned macros so it is possible you are not
aware of functions? As far as I know, most or all macros can be replaced by
functions which do have the nice property of not polluting the
11 matches
Mail list logo