Re: [CMake] Explanation....
On Thursday, 24. April 2014, 17:34:40, Matthew Woehlke wrote:
On 2014-04-24 04:53, Johannes Zarl wrote:
On Wednesday, 23. April 2014, 18:54:39, Matthew Woehlke wrote:
if ( ${arg} STREQUAL TOTO)
set( TOTO evil)
You sure? When I checked, this did not work.
Are *you* sure? :-)
Yes, I am. For the specific use-case given in this thread (the STREQUAL), the
prefix *is* safe to use. I still prefer the MATCHES syntax, as it is not too
much overhead and prods the programmer to think about why it was used and what
is happening.
And of course, David Cole is totally right when he says:
It's just ridiculous to waste time trying to justify the existing
behavior. It's more confusing than useful, and ought to be changed.
Right; *explicit* expansion is limited in what characters are allowed.
As David Cole points out, you must expand such variables indirectly. Of
course, implicit expansion counts as indirect expansion, which is why
there is no safe character/prefix that can guarantee implicit expansion
won't occur.
I'm always happy to learn something new. How would you manage to make the
following if statement trigger?
set( arg value)
if ( ${arg} STREQUAL TOTO )
message ( arg equals 'TOTO', and arg equals 'value' )
endif()
(And - again as David Cole already noted - you didn't get an error in
the set() command, did you?)
No, but the if statement didn't trigger, either.
On 2014-04-24 06:31, David Cole wrote:
I, for one, would fully support breaking backwards compatibility to fix
this, and be strict with variable and macro and function name
identifiers.
Of course, the *real* problem is implicit expansion. The permissiveness
of variable naming makes it harder to work around this, but would be
less of an issue if implicit expansion was less eager.
I aggree 100% with both of you, here.
Cheers,
Johannes
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
I'm always happy to learn something new. How would you manage to make
the following if statement trigger?
set( arg value)
if ( ${arg} STREQUAL TOTO )
message ( arg equals 'TOTO', and arg equals 'value' )
endif()
By having a variable named value that you didn't know about...
This makes it print out:
set( value TOTO)
set( arg value)
if ( ${arg} STREQUAL TOTO )
message ( arg equals 'TOTO', and arg equals 'value' )
endif()
:-)
Ridiculous, I know, but possible, and therefore, I'm sure somebody has
seen the unexpected as a result of this feature...
Cheers,
David C.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
On 2014-04-28 04:58, Johannes Zarl wrote:
I'm always happy to learn something new. How would you manage to make the
following if statement trigger?
set( arg value)
if ( ${arg} STREQUAL TOTO )
message ( arg equals 'TOTO', and arg equals 'value' )
endif()
Exactly how you would expect:
set( TOTO value)
...and it does trigger:
$ cmake -P evil.cmake
arg equals 'TOTO', and arg equals 'value'
No, but the if statement didn't trigger, either.
Well, yes, but that's because I caused arg to be compared against 'evil'
instead of 'TOTO'. Since arg is set to 'value', it still didn't match.
The previous example was more metaphorical.
--
Matthew
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2014 12:31 PM, David Cole wrote: You sure? When I checked, this did not work. Also, the following gives me a syntax error: I, for one, would fully support breaking backwards compatibility to fix this, and be strict with variable and macro and function name identifiers. It's just ridiculous to waste time trying to justify the existing behavior. It's more confusing than useful, and ought to be changed. + 1 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNaL6UACgkQEr8WrU8nPV1TuACeJR8lNfWL6vDUDwnKLpkguvSm /yAAnibx3MX9EbY0EQyfdjrqBnvN5cfq =HLhL -END PGP SIGNATURE- -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
On Wednesday, 23. April 2014, 18:54:39, Matthew Woehlke wrote:
if ( ${arg} STREQUAL TOTO)
set( TOTO evil)
You sure? When I checked, this did not work. Also, the following gives me a
syntax error:
set ( foo Evil!)
message( ${ foo})
Syntax error in cmake code at
/home/zing/scratch/cmake_testbed/CMakeLists.txt:100
when parsing string
${ foo}
syntax error, unexpected cal_SYMBOL, expecting } (7)
See also
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9936.
This is totally different, in that it uses an unsafe prefix. Just like the
_ASDF_ I used in my first response, the x *can* be the beginning of a
variable name. The space can not start a vaariable name.
Cheers,
Johannes
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
You sure? When I checked, this did not work. Also, the following
gives me a syntax error:
set ( foo Evil!)
message( ${ foo})
But you *can* still do it indirectly (even with the 3.0 RCs):
set ( variable with spaces Evil too!)
set (varname variable with spaces)
message(${${varname}})
(Sorry, but I refuse to use foo in example code...)
You'll notice that in your original example, the error was reported on
the message command. The parser simply could not parse a directly
coded variable name containing spaces inside the context of ${}... but
de-referencing indirectly, as is commonly done, still makes it possible
to end up with weirdly named variables if you're not extremely careful
with your variable naming schemes.
I, for one, would fully support breaking backwards compatibility to fix
this, and be strict with variable and macro and function name
identifiers.
It's just ridiculous to waste time trying to justify the existing
behavior. It's more confusing than useful, and ought to be changed.
Just my opinion,
David C.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
On 2014-04-24 04:53, Johannes Zarl wrote:
On Wednesday, 23. April 2014, 18:54:39, Matthew Woehlke wrote:
if ( ${arg} STREQUAL TOTO)
set( TOTO evil)
You sure? When I checked, this did not work.
Are *you* sure? :-)
Also, the following gives me a syntax error:
message( ${ foo})
Right; *explicit* expansion is limited in what characters are allowed.
As David Cole points out, you must expand such variables indirectly. Of
course, implicit expansion counts as indirect expansion, which is why
there is no safe character/prefix that can guarantee implicit expansion
won't occur.
(And - again as David Cole already noted - you didn't get an error in
the set() command, did you?)
See also
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9936.
This is totally different, in that it uses an unsafe prefix.
No it doesn't. The point being made there (and here) is that *ANY*
prefix is unsafe. (Granted, some are more unsafe than others...)
On 2014-04-24 06:31, David Cole wrote:
I, for one, would fully support breaking backwards compatibility to fix
this, and be strict with variable and macro and function name
identifiers.
Of course, the *real* problem is implicit expansion. The permissiveness
of variable naming makes it harder to work around this, but would be
less of an issue if implicit expansion was less eager.
--
Matthew
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
On 2014-04-16 06:03, Rolf Eike Beer wrote:
Am 16.04.2014 11:39, schrieb Johannes Zarl:
Instead of ``${var} STREQUAL VALUE'', write:
IF ( var MATCHES ^VALUE$ )
NO, please don't! I try hard to kill all those as it requires
compiling a regular expression for a simple string match. Just change it
to something that is no valid variable name, i.e. will never get expanded:
if ( ${arg} STREQUAL TOTO)
set( TOTO evil)
Admittedly it's much less likely that variable names containing
non-identifier characters¹ will occur by accident, the only truly safe
way to avoid unintended implicit expansion is to either rely on implicit
expansion (i.e. always assign your operands to variables and give the
variable names as the literal arguments), or use some other command that
doesn't perform expansion.
(¹ except for '-', which will often occur in automatically created
variable names when used in project names, e.g. my-project_SOURCE_DIR.)
See also
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9936.
--
Matthew
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
Hi,
On Monday, 14. April 2014, 19:23:19, Theodore Papadopoulo wrote:
if (${arg} STREQUAL TOTO) - if (TOTO STREQUAL TOTO) - if
(B STREQUAL B)
What I do not follow is why there is an implicit evaluation of TOTO
into B (in both this case or the next I explicitely asked for a
string containing the content of the variable ${arg}, if I had
intended the content of the variable which name is in ${arg} I would
have written ${${arg}}.
If it is any consolence to you, this is one of the most-hated (anti-)features
of cmake. The best you can do is to embrace this oddity (it's not going to go
away soon), and use a different idiom:
Instead of ``${var} STREQUAL VALUE'', write:
IF ( var MATCHES ^VALUE$ )
- The MATCHES expression only does string/variable expansion on the right
side. Therefore you get a well-defined behaviour regardless of any possible
aliasing effects on variable names and values.
Of course, you are right about what happened, it is just very unsafe.
That means that if I'm using as a variable name the name of a constant
used in some other module, there will be very unexpected failures
You are totally right. I guess if there was a way to change this in a
backwards-compatible way, cmake developers would not hesitate to do so.
For example taking /usr/share/cmake/Modules/FeatureSummary.cmake as an
example, if I set a variable PROPERTIES with a value might (untested)
provoke quite unexpected results (if(NOT ${_props} STREQUAL
PROPERTIES)). Or if I do set(0 1) before calling
CheckLanguage.cmake (if(CMAKE_${lang}_COMPILER AND ${result}
STREQUAL 0)).
You can have even more fun by redefining some version strings:
set(MY_VERSION 2.8.15)
set(2.8.15 hehehe)
if (MY_VERSION VERSION_EQUAL 2.8.15 )
message(All as expected...)
else()
message(I'm so evil!)
endif()
# You can probably guess what this prints out ;-)
IMO one thing that *could* be done would be to deprecate the unsafe
expressions and replace them with some safe version.
I realize now that this is what probably means the
if(variable|string STREQUAL variable|string)
in the cmake manual. But in my reading that was meaning some
overloading so that
TOTO is a variable so evaluated into ${TOTO}
but TOTO remains a string and is not evaluated any further.
At least that what I thought (basically at some type system
differentiating variables and strings)... I'm clearly wrong as:
set(TOTO B)
if (B STREQUAL TOTO)
message(AhAh)
endif()
What helped me to understand it was to see this as a two-step procedure:
1) Parsing: ${variable} gets replaced by its value
2) Execution: IF is called with the strings as argument.
At step 2, the IF statement cannot possibly determine how its arguments looked
before expansion.
if ( _ASDF_${arg} STREQUAL _ASDF_TOTO)
Well I knew the technique, but thought it was mainly for protection
againts empty strings (which ${arg} should be equivalent). Not sure
it makes the thing safer though.
Well I guess I need to go and see cmake source code, as I cannot
understand cery well its evaluation rules.
Sorry for my mistake in the first mail. I wrote my response rather quick, not
pausing to think of better alternatives. Had I invested more time, I would've
given you the solution using MATCHES that I explained above. Sorry for the
inconvenience...
Cheers,
Johannes
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
Am 16.04.2014 11:39, schrieb Johannes Zarl:
Hi,
On Monday, 14. April 2014, 19:23:19, Theodore Papadopoulo wrote:
if (${arg} STREQUAL TOTO) - if (TOTO STREQUAL TOTO) - if
(B STREQUAL B)
What I do not follow is why there is an implicit evaluation of TOTO
into B (in both this case or the next I explicitely asked for a
string containing the content of the variable ${arg}, if I had
intended the content of the variable which name is in ${arg} I would
have written ${${arg}}.
If it is any consolence to you, this is one of the most-hated
(anti-)features
of cmake. The best you can do is to embrace this oddity (it's not going
to go
away soon), and use a different idiom:
Instead of ``${var} STREQUAL VALUE'', write:
IF ( var MATCHES ^VALUE$ )
NO, please don't! I try hard to kill all those as it requires
compiling a regular expression for a simple string match. Just change it
to something that is no valid variable name, i.e. will never get
expanded:
if ( ${arg} STREQUAL TOTO)
Eike
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
On Wednesday, 16. April 2014, 12:03:30, Rolf Eike Beer wrote:
Instead of ``${var} STREQUAL VALUE'', write:
IF ( var MATCHES ^VALUE$ )
NO, please don't! I try hard to kill all those as it requires
compiling a regular expression for a simple string match. Just change it
to something that is no valid variable name, i.e. will never get
expanded:
In principle, you are right. Not too sure, though, whether such a big NO
is warranted. A quick test shows the overhead to be existing, yet not too
severe:
foreach(arg RANGE 1)
#a) if ( ${foo} STREQUAL ${arg})
#b) if ( foo MATCHES ^${arg}$)
message(Found it!)
endif()
endforeach()
Method b) has to compile 10.000 regexes, yet the runtime is only 30% worse.
And that is even though this example does the opposite of the normal use-case
of the regex, i.e. keeping one fixed regex and matching the variables against
it. I doubt that the overhead is even measurable in the average build
system.
#a)
$ time cmake .
-- Configuring done
-- Generating done
-- Build files have been written to: /home/zing/scratch/foo
real0m0.210s
user0m0.136s
sys 0m0.012s
#b)
$ time cmake .
-- Configuring done
-- Generating done
-- Build files have been written to: /home/zing/scratch/foo
real0m0.278s
user0m0.220s
sys 0m0.004s
Or are you talking about memory overhead?
if ( ${arg} STREQUAL TOTO)
Kudos to you for presenting a (the only?) *safe* prefix.
Johannes
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
Hello Theo,
On Friday, 11. April 2014, 14:20:36, Theodore Papadopoulo wrote:
::-B-:: - This shows that B is indeed parsed as OPTIONAL
A
A- Fine I'm in the else part of the if
OPTIONAL
HERE - Fine.
... I guess OPTIONAL should read TOTO. You say it's fine, but it's
probably not what you expected.
Let's take this step by step:
if (${arg} STREQUAL TOTO)
- if (TOTO STREQUAL TOTO)
- if (B STREQUAL B)
So, the expression evaluates to true.
B
HERE - ???
Now this should not come as a surprise:
if (${arg} STREQUAL TOTO)
- if (B STREQUAL TOTO)
- if ( B STREQUAL B)
You could add a prefix to your if expression (I'm sure you have seen this
technique in configure scripts*g*):
if ( _ASDF_${arg} STREQUAL _ASDF_TOTO)
HTH,
Johannes
P.S.: To get better visibility on mailing lists, it's best if you start a new
thread instead of just replying to a message and changing the subject line.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
First thank's a lot for your answer
On 04/14/2014 12:03 PM, Johannes Zarl wrote: Hello Theo,
On Friday, 11. April 2014, 14:20:36, Theodore Papadopoulo wrote:
::-B-:: - This shows that B is indeed parsed as OPTIONAL
A A- Fine I'm in the else part of the if OPTIONAL HERE
- Fine.
... I guess OPTIONAL should read TOTO. You say it's fine, but
it's probably not what you expected.
Yes. The previous version was with OPTIONAL, but since the word might
have been used elsewhere in cmake I decided to put another name and
forgot to change the output.
But the Fine after the OPTIONAL was what I intended.
Let's take this step by step:
if (${arg} STREQUAL TOTO) - if (TOTO STREQUAL TOTO) - if
(B STREQUAL B)
What I do not follow is why there is an implicit evaluation of TOTO
into B (in both this case or the next I explicitely asked for a
string containing the content of the variable ${arg}, if I had
intended the content of the variable which name is in ${arg} I would
have written ${${arg}}.
Of course, you are right about what happened, it is just very unsafe.
That means that if I'm using as a variable name the name of a constant
used in some other module, there will be very unexpected failures
For example taking /usr/share/cmake/Modules/FeatureSummary.cmake as an
example, if I set a variable PROPERTIES with a value might (untested)
provoke quite unexpected results (if(NOT ${_props} STREQUAL
PROPERTIES)). Or if I do set(0 1) before calling
CheckLanguage.cmake (if(CMAKE_${lang}_COMPILER AND ${result}
STREQUAL 0)).
I realize now that this is what probably means the
if(variable|string STREQUAL variable|string)
in the cmake manual. But in my reading that was meaning some
overloading so that
TOTO is a variable so evaluated into ${TOTO}
but TOTO remains a string and is not evaluated any further.
At least that what I thought (basically at some type system
differentiating variables and strings)... I'm clearly wrong as:
set(TOTO B)
if (B STREQUAL TOTO)
message(AhAh)
endif()
The rule seems a little bit awkward as it seem to be sthg like: if
this is a variable name evaluate its value otherwise keep its name as
a string (otherwise the evaluation of strings that do not correspond
to variables would give empty strings...)
In any case, we have to play with the current rule whatever it is, but
I do not think this rule helps making cmake a safe language
You could add a prefix to your if expression (I'm sure you have
seen
this
technique in configure scripts*g*):
if ( _ASDF_${arg} STREQUAL _ASDF_TOTO)
Well I knew the technique, but thought it was mainly for protection
againts empty strings (which ${arg} should be equivalent). Not sure
it makes the thing safer though.
Well I guess I need to go and see cmake source code, as I cannot
understand cery well its evaluation rules.
But the manual could be made clearer here
P.S.: To get better visibility on mailing lists, it's best if you
start a new
thread instead of just replying to a message and changing the
subject line.
Sorry I did not realized that doing so was keeping the thread
information... Normally this message should be a new thread...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNMGYcACgkQEr8WrU8nPV3TqACgkWkgb1vT3ZQojBGaJq5cCw3X
2ZoAn3LOs/JDDR1PdkkgiTb3drSXvS9M
=MhIC
-END PGP SIGNATURE-
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Explanation....
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have run on behaviour of cmake that I really do not understand (even
if I have clues)... This is probably stupid, but I'm puzzled...
The attached CMakeLists.txt gives the following output:
::-B-:: - This shows that B is indeed parsed as OPTIONAL
A
A- Fine I'm in the else part of the if
OPTIONAL
HERE - Fine.
B
HERE - ???
Tested on cmake 2.3.4 and 2.8.12.2.
Of course this is related to the reuse of TOTO both as a variable name
and as a variable content but this seems really error prone.
Thank's for any clue.
Theo Papadopoulo.
PS: I'm clearly supporting the addition of a continue() command:
http://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=14013graph=relation
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEUEARECAAYFAlNH3hQACgkQEr8WrU8nPV2BZgCXbxsiijX9dQD0TlfIGQa5bIfj
0QCfZffqFn0WpoFEAv1oBrF6fVF62JY=
=ooMR
-END PGP SIGNATURE-
cmake_minimum_required(VERSION 2.8)
project(Test)
set(DEFAULT A)
set(TOTO B)
message(::-${TOTO}-::)
foreach(arg ${DEFAULT} TOTO ${TOTO})
message(${arg})
if (${arg} STREQUAL TOTO)
message(HERE)
else()
message(${arg})
endif()
endforeach()
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation of the CMake INSTALL and EXPORT Commands
Thanks for the very valuable info Matthew. If Project A is installed (to a standard location), then it is available system wide, yes. However you should still use find_package(A) rather than relying on e.g. target_link_libraries(B A) I tried to use find_package(A) but CMake would display a warning: By not providing FindA.cmake in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by A, but CMake did not find one Obviously I am not installing it correctly. When do I know my libraries/package is installed correctly (apart from the fact that find_package will be able to find it)? Is there a specific folder that I can check to make sure the installation took place properly and that CMake will be able to find the libraries/packages? Am I correct in assuming that if I do the install correctly, I do not have to write a package configuration file and that it will be provided by CMake automatically? Any tips that first time users like me should watch out for when installing their libraries would be great. Generally speaking, you should either have two separate builds of A in 32- and 64-bit mode that can be installed in parallel I will follow your advice here and split up the configurations. Thank you, Saad Message: 2 Date: Wed, 03 Apr 2013 17:12:43 -0400 From: Matthew Woehlke matthew.woeh...@kitware.com Subject: Re: [CMake] Explanation of the CMake INSTALL and EXPORT Commands To: cmake@cmake.org Message-ID: kji607$pe$1...@ger.gmane.org Content-Type: text/plain; charset=UTF-8; format=flowed On 2013-04-03 16:16, Saad Khattak wrote: I am having a hard time understanding some commands in CMake which by the looks of it are vital for proper project deployment. One of the commands is INSTALL and the other is EXPORT. There are two forms of EXPORT, and I am not certain which one you are referring to. There is the command EXPORT, and there is the EXPORT named argument to the INSTALL command. They are similar in that they both deal with generating target export files, but the command version is used to generate such for build trees, while the named argument version applies to install trees. If you never use your software downstream from a build directory, you can safely ignore the command version. 1) Why do I need to install my library/executable? When I build my libraries and they are put in their library output paths, what is the point of INSTALL? INSTALL is used to implement 'make install' (or equivalent), and also packaging. If you are only ever using your software from a source build, you can probably ignore it. If you ever want to deploy your software, however, I would strongly encourage having an install process. Installing makes a software package generally available to users of the system, by installing its components into a well-known prefix (e.g. /usr, /usr/local, /opt/MySoft). It is often much more convenient to use an installed software package rather than stuff in a build directory, as installed binaries tend to be in e.g. PATH, whereas build directories may not be readable by all users. Please don't teach your build to write its build objects directly into e.g. /usr/local/bin :-). 2) Once I do install targets and/or programs, are they available to other projects that are not in the same CMakeLists build? Yes. They are available just from build directories also, but you will need to manually tell CMake where to find build directories. (Per above, installed packages can be found automatically if they are installed to standard (well known) locations... keeping in mind that you can choose to install to any location you like, e.g. in your home directory.) (If you are using exported targets - and you should - then you will need to use the EXPORT command to create a build-directory exported targets file. Getting this right is a little more complicated than install exports, but saves needing to install the package every time your downstream needs an updated version.) 3) Suppose I have 2 completely separate projects (i.e. they have completely separate CMakeLists that are not 'talking' to each other) - Project A builds some libraries which Project B now needs to use. Does Project A 'install' the libraries and are now those libraries are available system wide? If Project A is installed (to a standard location), then it is available system wide, yes. However you should still use find_package(A) rather than relying on e.g. target_link_libraries(B A) so that your build will work for users that do not have A in a standard location. If A is built by CMake, your install should generate exports so that users of A do not need a find module. (Also, then you *can* - and should - do target_link_libraries(B A), because 'A' will be an imported target, i.e. will 'look like' it was build as part of B.) 4) Project A can build 32 bit and 64 bit libraries. How does INSTALL (or EXPORT? Like I said
[CMake] Explanation of the CMake INSTALL and EXPORT Commands
Hi, I am having a hard time understanding some commands in CMake which by the looks of it are vital for proper project deployment. One of the commands is INSTALL and the other is EXPORT. I have read the following page many times: http://www.cmake.org/Wiki/CMake:Install_Commands. The article states CMake has an elaborate install process that simplifies installation of programs, libraries, and other files. but does not go into any further detail on how it simplifies the process. But it seems like the article is meant for CMake veterans and not newcomers. It simply explains the usage of the command but not what it does, its end result and its usage. I have the following questions: 1) Why do I need to install my library/executable? When I build my libraries and they are put in their library output paths, what is the point of INSTALL? 2) Once I do install targets and/or programs, are they available to other projects that are not in the same CMakeLists build? 3) Suppose I have 2 completely separate projects (i.e. they have completely separate CMakeLists that are not 'talking' to each other) - Project A builds some libraries which Project B now needs to use. Does Project A 'install' the libraries and are now those libraries are available system wide? Or do I still have to give the path of Project A to Project B for linking? Perhaps I am not making any sense whatsoever. I apologize, but I have spent the past week trying to wrap my head around INSTALL and EXPORT but they make no sense to me because their end-usage is not described anywhere. 4) Project A can build 32 bit and 64 bit libraries. How does INSTALL (or EXPORT? Like I said earlier, I am very confused here...) know which library it is 'installing'? And then how does Project B 32 bit know to link with Project A 32 bit libraries and same with 64-bit? Thank you for any help, Saad -- 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] Explanation of the CMake INSTALL and EXPORT Commands
On 2013-04-03 16:16, Saad Khattak wrote: I am having a hard time understanding some commands in CMake which by the looks of it are vital for proper project deployment. One of the commands is INSTALL and the other is EXPORT. There are two forms of EXPORT, and I am not certain which one you are referring to. There is the command EXPORT, and there is the EXPORT named argument to the INSTALL command. They are similar in that they both deal with generating target export files, but the command version is used to generate such for build trees, while the named argument version applies to install trees. If you never use your software downstream from a build directory, you can safely ignore the command version. 1) Why do I need to install my library/executable? When I build my libraries and they are put in their library output paths, what is the point of INSTALL? INSTALL is used to implement 'make install' (or equivalent), and also packaging. If you are only ever using your software from a source build, you can probably ignore it. If you ever want to deploy your software, however, I would strongly encourage having an install process. Installing makes a software package generally available to users of the system, by installing its components into a well-known prefix (e.g. /usr, /usr/local, /opt/MySoft). It is often much more convenient to use an installed software package rather than stuff in a build directory, as installed binaries tend to be in e.g. PATH, whereas build directories may not be readable by all users. Please don't teach your build to write its build objects directly into e.g. /usr/local/bin :-). 2) Once I do install targets and/or programs, are they available to other projects that are not in the same CMakeLists build? Yes. They are available just from build directories also, but you will need to manually tell CMake where to find build directories. (Per above, installed packages can be found automatically if they are installed to standard (well known) locations... keeping in mind that you can choose to install to any location you like, e.g. in your home directory.) (If you are using exported targets - and you should - then you will need to use the EXPORT command to create a build-directory exported targets file. Getting this right is a little more complicated than install exports, but saves needing to install the package every time your downstream needs an updated version.) 3) Suppose I have 2 completely separate projects (i.e. they have completely separate CMakeLists that are not 'talking' to each other) - Project A builds some libraries which Project B now needs to use. Does Project A 'install' the libraries and are now those libraries are available system wide? If Project A is installed (to a standard location), then it is available system wide, yes. However you should still use find_package(A) rather than relying on e.g. target_link_libraries(B A) so that your build will work for users that do not have A in a standard location. If A is built by CMake, your install should generate exports so that users of A do not need a find module. (Also, then you *can* - and should - do target_link_libraries(B A), because 'A' will be an imported target, i.e. will 'look like' it was build as part of B.) 4) Project A can build 32 bit and 64 bit libraries. How does INSTALL (or EXPORT? Like I said earlier, I am very confused here...) know which library it is 'installing'? And then how does Project B 32 bit know to link with Project A 32 bit libraries and same with 64-bit? Hmm... I'm not all that familiar with multi-arch bits, but I *think* how this is supposed to work is that when B does find_package(A), it will look in either lib or lib64 depending on whether or not it is being built in 64-bit mode. So as long as your find_package picks the right AConfig.cmake, all will be well (it should by default if A is installed to a standard location, and/or if necessary you can force where to find its config). Generally speaking, you should either have two separate builds of A in 32- and 64-bit mode that can be installed in parallel, or else A should produce 32- and 64-bit libraries with different names. (I would recommend the former, since that is how most software works and is less likely to give you headaches getting it to work. Also because getting CMake to build both 32- and 64-bit binaries in the same build is going to be harder than just having separate 32- and 64-bit builds.) Hope that helps. -- Matthew -- 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
