On Mon, Sep 30, 2013 at 11:04 AM, Dan Kegel wrote:
> If CMake is going to only
> behave properly when an argument is given in uppercase, it should
> abort if the argument is given in lowercase. Throw the users a bone!
> There is *no excuse* for forcing users to guess.
>
> I thought there was a bu
On Mon, Sep 30, 2013 at 10:29 AM, Williams, Norman K
wrote:
> I don't know why that is scary. It is the way CMake works, something that
> one must accomodate in order to use CMake.
I find it scary, annoying, and difficult to learn. If CMake is going to only
behave properly when an argument is gi
I don't know why that is scary. It is the way CMake works, something that
one must accomodate in order to use CMake.
Obviously, if the Kitware people had it to do all over again, they
probably would do some things differently. But CMake has evolved (a lot!)
over the years, and it has some syntact
Furthermore gvim adds more confusion to it
On Mon, Sep 30, 2013 at 10:43 PM, Sumit Adhikari
wrote:
> Thanks. This is scary :(
>
> Regards, Sumit
>
>
> On Mon, Sep 30, 2013 at 10:32 PM, Williams, Norman K <
> norman-k-willi...@uiowa.edu> wrote:
>
>> It might be confusing -- well it is confusing!
Thanks. This is scary :(
Regards, Sumit
On Mon, Sep 30, 2013 at 10:32 PM, Williams, Norman K <
norman-k-willi...@uiowa.edu> wrote:
> It might be confusing -- well it is confusing! -- but CMake built-in
> commands, functions and macro names are case insensitive. CMake command
> keywords are cas
It might be confusing -- well it is confusing! -- but CMake built-in
commands, functions and macro names are case insensitive. CMake command
keywords are case sensitive.
The first is a legal CMake command. The second is a fatal CMake error:
CMake Error at CMakeLists.txt:13 (if):
if given argum
Dear All,
if(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
differs from
if(${CMAKE_SYSTEM_NAME} matches "Linux")
Is this behavior expected ?
Regards, Sumit
--
Sumit Adhikari,
Senior Architect - Product Development,
Synphony Teleca
--
Powered by www.kitware.com
Please keep messages on-topic and ch
Ken,
> A macro in cmake is a bit like a cpp macro. It is a string
> replacement operation that replaces ${varname} with the
> actual argument to the macro.
> [...]
> After string replacement of ${boolarg} with TRUE looks like
>
> MACRO (MYMACRO boolarg)
> MESSAGE ("MYMACRO(TRUE)")
>
A macro in cmake is a bit like a cpp macro. It is a string replacement
operation that replaces ${varname} with the actual argument to the macro.
Then it executes the commands. At one point we considered (and tried) making
the macro arguments be variables but there are existing projects out there
th
On 2007-05-28 23:17+0100 Trevor Kellaway wrote:
Alan,
Do you concur the following is a real problem?
No, but then I am not really a CMake expert. Instead, I am a
goal-oriented CMake user (i.e., I just want PLplot or
whatever to build with no problems) so I just try stuff until
something wor
Alan,
> > Do you concur the following is a real problem?
>
> No, but then I am not really a CMake expert. Instead, I am a
> goal-oriented CMake user (i.e., I just want PLplot or
> whatever to build with no problems) so I just try stuff until
> something works.
Same here, my primary aim is
On 2007-05-28 18:27+0100 Trevor Kellaway wrote:
Alan,
Do you concur the following is a real problem?
No, but then I am not really a CMake expert. Instead, I am a goal-oriented
CMake user (i.e., I just want PLplot or whatever to build with no problems)
so I just try stuff until something work
Alan,
Do you concur the following is a real problem?
<> #
# Possible bug in cmake version 2.4-patch 6 where macro arguments
# don't test correctly. When run this produces:
#
# mytrue=TRUE [msg1]
# MYMACRO(TRUE)
# boolarg=TRUE [False path]
# _var=TRUE [True path]
#
MACRO
13 matches
Mail list logo
