Robert Dailey | 1 Mar 01:38 2012
Picon

Functions inherit parent variables?

I ran a quick test:



function( test )
message( "SOME_TEST: ${SOME_TEST}" )
endfunction()

function( start )
set( SOME_TEST "HELLO WORLD" )
test()
endfunction()

start()


Seems like a function has access to the calling scope's defined variables. I thought because functions created a new scope, that excluded access to variables defined in the outer scope (i.e. calling scope)

Can someone explain?

---------
Robert Dailey
--

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
Michael Hertling | 1 Mar 03:36 2012
Picon

Re: Code and API review request for Qt5 CMake files

On 02/28/2012 10:03 PM, Alexander Neundorf wrote:
> ...will reply later in detail.
> 
> Could you please go through the existing find-modules shipped with cmake which 
> support COMPONENTS and make a summary of how they handle them ?
> 
> At least FindQt4.cmake be default searches all components.
> 
> Thanks
> Alex

The following CMakeLists.txt can be used to systematically investigate
the results of the component-aware find modules currently shipped with
CMake, these are Find{Boost,GTK2,HDF5,ImageMagick,Java,OpenSceneGraph,
Qt4,wxWidgets,XMLRPC}:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(FINDRESULTVARIABLES C CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)

FUNCTION(FindResultVariables pkg)
    SET(prefix ${pkg})
    IF(DEFINED ARGV1)
        SET(prefix ${ARGV1})
    ENDIF()
    UNSET(REQUIRED)
    IF(${pkg}_REQUIRED)
        SET(REQUIRED REQUIRED)
    ENDIF()
    FIND_PACKAGE(${pkg} COMPONENTS ${${pkg}_COMPONENTS} ${REQUIRED})
    MESSAGE("Begin: ${pkg} result variables")
    GET_DIRECTORY_PROPERTY(v VARIABLES)
    FOREACH(i IN LISTS v)
        IF(i MATCHES "^${prefix}.*_FOUND$")
            MESSAGE("${i}=${${i}}")
        ENDIF()
    ENDFOREACH()
    MESSAGE("${prefix}_LIBRARIES: ${${prefix}_LIBRARIES}")
    MESSAGE("End: ${pkg} result variables")
ENDFUNCTION()

FindResultVariables(Boost)
FindResultVariables(GTK2)
FindResultVariables(HDF5)
FindResultVariables(ImageMagick)
FindResultVariables(Java)
FindResultVariables(OpenSceneGraph)
FindResultVariables(Qt4 QT)
FindResultVariables(wxWidgets)
FindResultVariables(XMLRPC)

HDF5, OpenSceneGraph and XMLRPC aren't installed on my system; my
preliminary findings for the remaining packages are as follows:

(1) Searching unrequested components:

Qt4: Yes.
GTK2,ImageMagick: Partially.
wxWidgets: All components if none are requested.

The remaining modules don't search unrequested components.

(2) Assigning *_*_FOUND variables:

Qt4: Only for modules which are known and found.
ImageMagick: Also for requested but unknown components.
wxWidgets: No *_*_FOUND variables at all but forwards unknown
           components to *_LIBRARIES variable without an error.

The remaining modules assign only to *_*_FOUND variables for
components which they know and which have been requested.

(3) Respecting the REQUIRED flag:

wxWidgets: REQUIRED ignored completely.
Boost: SEND_ERROR instead of FATAL_ERROR.
GTK2,Java: Bail out on unknown components even if not REQUIRED.

The remaining modules bail out on unavailable requested components.

(4) Assinging the package-related *_FOUND variable:

Java: No *_FOUND variable at all although it's documented.
wxWidgets: TRUE even if requested components aren't found, see above.

The remaining modules return FALSE if a requested component isn't found.

My comments on these, say, multifarious findings are:

Ad.(1): In general, automatically searching unrequested components
does not mean a harm, but it is also not beneficial at all events:

- No guarantee to catch all components - consider a component added
  later to the package - so no guarantee that all later *_*_FOUND
  variables have been assigned a definite value by FIND_PACKAGE().
- Complicates find modules / config files due to REQUIRED/QUIET.
- Potentially higher costs due to unneeded search operations.

For the latter loint, there is a not-so-uncommon use case: Suppose
a find module wants to check whether a library matches its header.
Putting away cross-compiling issues for the moment, this requires
building and running a test program. If it is to be performed for
each Qt4 module, e.g., a FIND_PACKAGE(Qt4) invocation would most
certainly be quite expensive. For these reasons, I usually advice
to search only requested components, request all components going
to be used and refer only to components having been requested.

Ad.(2): Due to my guiding principle - refer only to FOUND variables
which have been assigned a definite value by FIND_PACKAGE() - I do
consider as important that a *_*_FOUND variable is assigned to for
each requested component. FindImageMagick.cmake does it right, but
the other modules - except for FindwxWidgets.cmake - have me check
*_*_FOUND variables without a definite value for requested but un-
known components. Again: The latters might become known one day.

Ad.(3): After FIND_PACKAGE(... REQUIRED), I definitely do not want
to check if all requested components including their prerequisites
are actually present. OTOH, the user must have the oppurtunity to
handle a package's or a component's absence by h(is|er)self. Thus,
FIND_PACKAGE() without REQUIRED should never bail out because of
something being not found, but with REQUIRED, it must bail out.

Ad.(4): None of the modules returning *_FOUND==FALSE just because
a component is missing could be turned into a config file at the
moment without changing its behavior. In order to address this
issue in the future, one has to decide if either

- a find module should behave like a config file in this regard and
  return *_FOUND==FALSE only if the package is totally unavailable;
  my favorite, or

- FIND_PACKAGE() should should allow config files to assign FALSE to
  *_FOUND if a requested component is unavailable; your favorite, I
  guess.

In the latter case, the components' *_*_FOUND variables would need
to be assigned to also, and if no config file has been found, this
must be done by FIND_PACKAGE() autonomously. Though, the *_*_FOUND
variables are just a convention of Modules/readme.txt whereas the
package's *_FOUND variable is documented for FIND_PACKAGE(); this
is a different quality. Finally, consider the following use case:

Suppose a package X with a non-(de)selectable core component and an
additionally selectable component Y; Qt's core module is a perfect
candidate for the former. If FIND_PACKAGE(X COMPONENTS Y) returns
with X_FOUND==FALSE and X_Y_FOUND!=TRUE, how do you determine the
core component's availability, following your favorite approach?
AFAICS, you can't: The results include "X totally unavailable" as
well as "X available without Y". Following my favorite approach,
by contrast, X_FOUND directly indicates the availability of the
core component. That's an example for the neccessity to reliably
detect a package's total presence/absence, and a multi-component
package needs not to be a pure additive entity made of its parts.

My main conclusion from the above-noted mess among CMake's current
component-aware find modules is that we urgently need a convention
how such modules and config files are intended to work. Hopefully,
we can take a step forward; Qt5's advent is a good opportunity.

Regards,

Michael
--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Michael Hertling | 1 Mar 04:54 2012
Picon

Re: Functions inherit parent variables?

On 03/01/2012 01:38 AM, Robert Dailey wrote:
> I ran a quick test:
> 
> 
> function( test )
> message( "SOME_TEST: ${SOME_TEST}" )
> endfunction()
> 
> function( start )
> set( SOME_TEST "HELLO WORLD" )
> test()
> endfunction()
> 
> start()
> 
> 
> Seems like a function has access to the calling scope's defined variables.
> I thought because functions created a new scope, that excluded access to
> variables defined in the outer scope (i.e. calling scope)
> 
> Can someone explain?

The line "SOME_TEST: HELLO WORLD" is missing, I guess?

As usual with scoping mechanisms, there is access to the outer scope
from within the inner scope: Read access via ordinary dereferencing
and write access via PARENT_SCOPE. It's quite the same as in C/C++
with the { and } tokens; see also the C++ "::" operator.

Regards,

Michael
--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Johannes Sasongko | 1 Mar 06:24 2012
Picon

Visual Studio 10 - GenerateDebugInformation always false

Is anyone having the problem where CMake creates VS10 project files with  
GenerateDebugInformation set to false for all (including Debug &  
RelWithDebInfo) targets? If I remember correctly, this did not happen when  
using the VS9 generator, but I don't have VS9 handy to test.

--

-- 
Johannes
--

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

Tan, Tom (Shanghai | 1 Mar 07:21 2012
Picon

How to include the generated header file?

According to the doc,  generate_export_header(somelib) generates a file
in the ${CMAKE_CURRENT_BUILD_DIR} called somelib_export.h.
What's the recommended way to include this   "somelib_export.h".
#include "somelib_export.h" does not work. And
${CMAKE_CURRENT_BUILD_DIR} is empty too.  I am using v2.8.7. The header
file does get generated, only the doc is not very helpful on how to
include it.
--

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

Michael Wild | 1 Mar 08:33 2012
Picon

Re: How to include the generated header file?

On 03/01/2012 07:21 AM, Tan, Tom (Shanghai) wrote:
> According to the doc,  generate_export_header(somelib) generates a file
> in the ${CMAKE_CURRENT_BUILD_DIR} called somelib_export.h.
> What's the recommended way to include this   "somelib_export.h".
> #include "somelib_export.h" does not work. And
> ${CMAKE_CURRENT_BUILD_DIR} is empty too.  I am using v2.8.7. The header
> file does get generated, only the doc is not very helpful on how to
> include it.

include_directories(${CMAKE_CURRENT_BINARY_DIR})

That's a bug in the documentation, the variable CMAKE_CURRENT_BUILD_DIR
does not exist (notice the difference is between BUILD and BINARY)...

Michael
--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Rolf Eike Beer | 1 Mar 08:47 2012
Picon

Re: Code and API review request for Qt5 CMake files

Michael Hertling wrote:

> My main conclusion from the above-noted mess among CMake's current
> component-aware find modules is that we urgently need a convention
> how such modules and config files are intended to work. Hopefully,
> we can take a step forward; Qt5's advent is a good opportunity.

Yes, please! And a good start would be cleaning up FindwxWidgets.cmake and 
porting it to use FPHSA so we get REQUIRED handling for free.

Eike
--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Tan, Tom (Shanghai | 1 Mar 09:55 2012
Picon

Re: How to include the generated header file?

Thanks. Speaking of bugs, there's one more in the generated header file:
#    ifdef machine_side-msvc-32bit_EXPORTS
        /* We are building this library */
#      define HostlinkPP_EXPORT __declspec(dllexport)
#    else
        /* We are using this library */
#      define HostlinkPP_EXPORT __declspec(dllimport)
#    endif

The inserted comments breaks the line and invokes a warning in VC++. A
better way is like this :

#    ifdef machine_side-msvc-32bit_EXPORTS 
#      define HostlinkPP_EXPORT __declspec(dllexport)        /* We are
building this library */
#    else
#      define HostlinkPP_EXPORT __declspec(dllimport)        /* We are
using this library */
#    endif

-----Original Message-----
From: cmake-bounces@...
[mailto:cmake-bounces@...] On Behalf
Of Michael Wild
Sent: Thursday, March 01, 2012 3:33 PM
To: cmake@...
Subject: Re: [CMake] How to include the generated header file?

On 03/01/2012 07:21 AM, Tan, Tom (Shanghai) wrote:
> According to the doc,  generate_export_header(somelib) generates a 
> file in the ${CMAKE_CURRENT_BUILD_DIR} called somelib_export.h.
> What's the recommended way to include this   "somelib_export.h".
> #include "somelib_export.h" does not work. And 
> ${CMAKE_CURRENT_BUILD_DIR} is empty too.  I am using v2.8.7. The 
> header file does get generated, only the doc is not very helpful on 
> how to include it.

include_directories(${CMAKE_CURRENT_BINARY_DIR})

That's a bug in the documentation, the variable CMAKE_CURRENT_BUILD_DIR
does not exist (notice the difference is between BUILD and BINARY)...

Michael
--

Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--

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

David Cole | 1 Mar 15:00 2012

Re: Visual Studio 10 - GenerateDebugInformation always false

Are you using CMake 2.8.7? If not, please upgrade and try with that version. If there's still a problem after
that, let us know.

On Mar 1, 2012, at 12:24 AM, "Johannes Sasongko" <sasongko@...> wrote:

> Is anyone having the problem where CMake creates VS10 project files with GenerateDebugInformation set
to false for all (including Debug & RelWithDebInfo) targets? If I remember correctly, this did not happen
when using the VS9 generator, but I don't have VS9 handy to test.
> 
> -- 
> Johannes
> --
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Eric Noulard | 1 Mar 15:01 2012
Picon

New platform which did not deserve upstream: how to avoid warning?

Hi,

I'm working on a research platform for which  I wrote a toolchain file.
Let's say this platform is called "Blah"

how do I avoid the

"System is unknown to cmake, create:
Platform/Blah to use this system, please send your config file to
cmake@... so it can be added to cmake"

Besides that all is OK (because the C compiler is GCC based).

So I wonder how I can do to avoid the warning.

There is no benefit to put this platform in upstream CMake so I can
write a dummy Blah.cmake platform?
Putting the file in a local (to my project) Platform/ directory seems
ok if I modify
the CMAKE_MODULE_PATH before project() command but is this the correct
way of work?

--

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

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


Gmane