Re: [CMake] CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH, but should it?
On Monday 10 January 2011, Bjørn Forsman wrote:
Hi all,
I just found out that CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH. The
documentation for CHECK_INCLUDE_FILES says:
...
The following variables may be set before calling this macro to
modify the way the check is run:
CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
So it seems intentional. But wouldn't it make sense to let
CHECK_INCLUDE_FILES look in CMAKE_FIND_ROOT_PATH? Or maybe more precise,
give the compiler include flags for
CMAKE_FIND_ROOT_PATH/{include/,usr/include}? It just seems wrong to me that
include files in CMAKE_FIND_ROOT_PATH can be ignored like that and it
destroys the meaning of CMAKE_FIND_ROOT_PATH. Comments?
Is maybe CHECK_INCLUDE_FILES deprecated and FIND_PATH/FIND_FILE is the way
to go?
check_include_files() is there to check whether header files in the compilers
system include path exist, i.e. which are found without any -I switches.
So, from that POV, the behaviour is ok.
Can I actually tell the compiler/gcc to ignore its standard include dirs ?
What header files are you testing ?
From libc or from some other library ?
I'm using CMake 2.8.2.
That behaviour didn't change recently.
Alex
___
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] CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH, but should it?
Hi Alexander,
Thanks for your reply.
2011/1/20 Alexander Neundorf a.neundorf-w...@gmx.net:
On Monday 10 January 2011, Bjørn Forsman wrote:
Hi all,
I just found out that CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH. The
documentation for CHECK_INCLUDE_FILES says:
...
The following variables may be set before calling this macro to
modify the way the check is run:
CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
So it seems intentional. But wouldn't it make sense to let
CHECK_INCLUDE_FILES look in CMAKE_FIND_ROOT_PATH? Or maybe more precise,
give the compiler include flags for
CMAKE_FIND_ROOT_PATH/{include/,usr/include}? It just seems wrong to me that
include files in CMAKE_FIND_ROOT_PATH can be ignored like that and it
destroys the meaning of CMAKE_FIND_ROOT_PATH. Comments?
Is maybe CHECK_INCLUDE_FILES deprecated and FIND_PATH/FIND_FILE is the way
to go?
check_include_files() is there to check whether header files in the compilers
system include path exist, i.e. which are found without any -I switches.
So, from that POV, the behaviour is ok.
Aha, so software using check_include_files() to look for *external*
packages/libraries _are doing it wrong_?
But I don't understand the use case for check_include_files(). When
would you want to limit yourself to only system include paths?
Can I actually tell the compiler/gcc to ignore its standard include dirs ?
AFAIK, GCC supports this. From 'man gcc':
--sysroot=dir
Use dir as the logical root directory for headers and
libraries. For example, if the
compiler would normally search for headers in /usr/include
and libraries in /usr/lib, it
will instead search dir/usr/include and dir/usr/lib.
What header files are you testing ?
From libc or from some other library ?
The cdrkit package uses check_include_files() on at least
sys/capability.h, from libcap. And libcap is an external library. So I
guess the right thing would be to patch cdrkit?
Best regards,
Bjørn Forsman
___
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] CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH, but should it?
2011/1/20 Alexander Neundorf a.neundorf-w...@gmx.net: check_include_files() is there to check whether header files in the compilers system include path exist, i.e. which are found without any -I switches. So, from that POV, the behaviour is ok. Aha, so software using check_include_files() to look for *external* packages/libraries _are doing it wrong_? But I don't understand the use case for check_include_files(). When would you want to limit yourself to only system include paths? E.g. to check if stdint.h, unistd.h or io.h exists when you are supporting platforms like Windows and Linux. Can I actually tell the compiler/gcc to ignore its standard include dirs ? AFAIK, GCC supports this. From 'man gcc': --sysroot=dir Use dir as the logical root directory for headers and libraries. For example, if the compiler would normally search for headers in /usr/include and libraries in /usr/lib, it will instead search dir/usr/include and dir/usr/lib. What header files are you testing ? From libc or from some other library ? The cdrkit package uses check_include_files() on at least sys/capability.h, from libcap. And libcap is an external library. So I guess the right thing would be to patch cdrkit? Uh, don't know. Maybe FIND_PATH or FIND_FILE? 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
Re: [CMake] CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH, but should it?
2011/1/10 Bjørn Forsman bjorn.fors...@gmail.com:
Hi all,
I just found out that CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH. The
documentation for CHECK_INCLUDE_FILES says:
...
The following variables may be set before calling this macro to
modify the way the check is run:
CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
So it seems intentional. But wouldn't it make sense to let CHECK_INCLUDE_FILES
look in CMAKE_FIND_ROOT_PATH? Or maybe more precise, give the compiler include
flags for CMAKE_FIND_ROOT_PATH/{include/,usr/include}? It just seems wrong to
me
that include files in CMAKE_FIND_ROOT_PATH can be ignored like that and it
destroys the meaning of CMAKE_FIND_ROOT_PATH. Comments?
Is maybe CHECK_INCLUDE_FILES deprecated and FIND_PATH/FIND_FILE is the way
to go?
I'm using CMake 2.8.2.
Anyone?
I'll try rephrasing my question.
I'm trying to build the cdrkit package using CMAKE_FIND_ROOT_PATH:
SET(CMAKE_FIND_ROOT_PATH $ENV{STAGING_DIR})
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
cdrkit attempts to find sys/capability.h using CHECK_INCLUDE_FILES.
This fails, even though the header is in
$STAGING_DIR/usr/include/sys/capability.h.
So what is the Right Thing to do here? Change CHECK_INCLUDE_FILES
to also look in CMAKE_FIND_ROOT_PATH or change the cdkit CMakeLists.txt
file to use FIND_PATH instead?
I guess the latter should be pretty easy, but I'd hate to give up on
the idea that
CMake packages can be truly re-rooted simply by using CMAKE_FIND_ROOT_PATH.
Best regards,
Bjørn Forsman
___
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
