[cmake-developers] Merge IAR compiler support?
Hi, I'd like to get IAR compiler support merged in CMake. There is already a pretty long bug/ticket for this here: http://public.kitware.com/Bug/view.php?id=10176 I've successfully tested IAR ARM compiler with CMake from the AddIARSupport branch[1] on github. I tested it with MinGW and MSYS generators. (I have not tested the IAR AVR compiler.) What is missing for this (awesome!) feature to be merged? Best regards, Bjørn Forsman [1] https://github.com/neundorf/CMake/tree/AddIARSupport -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Merge IAR compiler support?
On 23 March 2013 17:18, Alexander Neundorf neund...@kde.org wrote: [...] For 2.8.11 I put work into the Texas Instruments compiler, for 2.8.12 I'll see to get the IAR compiler in (with your help). Sounds great! 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Fwd: How to setup toolchain correctly for C compiler only (no CXX present for target)
Forgot to CC list... -- Forwarded message -- From: Bjørn Forsman bjorn.fors...@gmail.com Date: 2011/9/19 Subject: Re: [CMake] How to setup toolchain correctly for C compiler only (no CXX present for target) To: Martin Kupke martin.ku...@novero.com On 19 September 2011 18:58, Martin Kupke martin.ku...@novero.com wrote: Is there a way to setup the toolchain file in a way to work only with a C compiler? Maybe (I don't know), but you can easily do it in the CMakeLists.txt file of your project: project(myproject C) Since the source code dictates what compiler it must be built with, I think you actually want to define it like above, and not in the toolchain file (which can be used with C *and* C++ projects). 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] cmake does not find modules when cross compiling
2011/8/17 Gonçalo Bernardo goncaloberna...@gmail.com: Dear all, I am using cmake and cmake-gui to cross-compile OpenCV. I wrote the following toolchain file: INCLUDE(CMakeForceCompiler) SET(CMAKE_CROSSCOMPILING TRUE) # this one is important SET(CMAKE_SYSTEM_NAME Linux) #this one not so much SET(CMAKE_SYSTEM_VERSION 1) # specify the cross compiler SET(CMAKE_C_COMPILER /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-gcc) SET(CMAKE_CXX_COMPILER /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-g++) # where is the target environment SET(CMAKE_FIND_ROOT_PATH /media/rootfs /media/rootfs/usr) # search for programs in the build host directories SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) # for libraries and headers in the target directories SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) When i load this in cmake-gui i face some problems. the cross-compilers seem to be correctly identified but not the packages installed in my rootfs. for instance cmake-gui prints: checking for module 'libavcodec' package 'libavcodec' not found when libavcodec.so.52 is present in rootfs/usr/lib. The problem also happens with gstreamer, ffmpeg,... how can i find out which specific files is cmake looking for? any other suggestion on this? Have you tried without this: INCLUDE(CMakeForceCompiler) SET(CMAKE_CROSSCOMPILING TRUE) 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] cmake does not find modules when cross compiling
On 17 August 2011 15:53, Gonçalo Bernardo goncaloberna...@gmail.com wrote: yes. any other ideas? No sorry. I don't see any other issues with your toolchainfile and I don't know where else to look (unless you want me to do *wild* guesses :-) ). 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] Buggy CPack generator behaviour?
2011/7/29 Eric Noulard eric.noul...@gmail.com: 2011/7/29 Bjørn Forsman bjorn.fors...@gmail.com: What do you mean with 'not relocatable'? I didn't see any difference in the archive layouts of RPM and DEB when changing CPACK_SET_DESTIR from 'not set' to ON. if you do: rpm -qpi your.rpm you'll see a line like: Relocations : (not relocatable) or Relocations : /usr When an rpm is relocatable you can do rpm -i --prefix=/your/relocation/prefix your.rpm if the rpm is not relocatable you can't. Aha, I see. Didn't you say that RPM and DEB generators sets CPACK_SET_DESTDIR=ON *itself*? Yes but not too soon (CPack internal step are indeed multiple) such that CPack can effectively collect files which are installed purposely with ABSOLUTE path and treat them as config file in RPM specification file. When DESTDIR is set to ON by the user CPack cannot do this work properly, and spit out a warning like: CPackRPM:Warning: CPACK_SET_DESTDIR is set (=ON) while requesting a relocatable package (CPACK_RPM_PACKAGE_RELOCATABLE is set): this is not supported, the package won't be relocatable. Aha, I see that now. I have never used CPACK_CONFIG_PROJECT_FILE, I just set(CPACK_SET_DESTDIR ON) in CMakeLists.txt and it fixed absolute DESTINATION paths for the archive generators. Just like you said in the first email. (Yay!) Because you wanted to go along the fast path and I cannot blame you but I did Indeed indicate in my firts e-mail: If you want to do some specific adjustment depending on the CPack generator used you may use a CPACK_PROJECT_CONFIG_FILE see doc here: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29; Now that the fast path works for you I thought you may be interested in your CPack config fine tuning. Read the link here: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 and you'll see that you can setup diferent value of CPACK_whateever var depending on the CPack Generator which is run. Obviously this is not mandatory in your case because you already get what you want, but may be you want to try. Thanks a lot for the pointers. 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] Buggy CPack generator behaviour?
2011/7/27 Eric Noulard eric.noul...@gmail.com:
2011/7/27 Bjørn Forsman bjorn.fors...@gmail.com:
Hi all,
I wonder if I've hit some bugs in the CPack generators, specifically
TGZ and DEB. They do not behave as I expect them to. What I expect
them to do is to generate an archive of files that look exactly like
what 'make install' puts in DESTDIR. If this is a wrong assumption
then please tell me.
This is a wrong assumption for several reasons but keep reading.
I'll try to answer inline, for the part I do have answer :-]
So based on that assumption, here are the issues:
1. TGZ doesn't populate the archive with all needed parent
directories. A binary that 'make install' puts in
DESTDIR/usr/local/bin is put in archive_root/bin with TGZ. I would
have expected the archive to contain archive_root/usr/local/bin
(like the DEB generator does). Is there maybe a configuration option
for this?
CPack does not use CMAKE_INSTALL_PREFIX but
CPACK_PACKAGING_INSTALL_PREFIX
if this variable is not defined, each CPack generator has
an historical builtin value which is used.
ArchiveGenerator (TGZ, ZIP, TBZ2 etc...) are using none
RPM has /usr
DEB has /usr
if you do
cpack -D CPACK_PACKAGING_INSTALL_PREFIX=/usr/local -G TGZ
then you may get the wanted prefix in TGZ.
2. TGZ fails on absolute DESTINATION paths:
CMake Error at /home/bjornfor/eraseme/build/cmake_install.cmake:44 (FILE):
file INSTALL cannot copy file /home/bjornfor/eraseme/build/hello to
/usr/bin/hello.
I see you point.
TGZ may handle absolute install path if you set(CPACK_SET_DESTDIR ON)
i.e.
cpack -D CPACK_SET_DESTDIR=ON -G TGZ will make TGZ tolerate absolute
install path.
(And no, I don't want to run as root just to create an archive. If DEB
can handle this so should TGZ.)
DEB (and RPM) internally set CPACK_SET_DESTDIR to ON (in fact I_ON)
This is not the default behavior for archive generators mainly for
backward-compatibility reason,
and other reason I cannot remember but you should find a lengthly
discussion about that
on some closed bug on the bug tracker.
I may dig this if you want the precise ref.
3. DEB won't generate a .deb with binaries in /usr/local/bin. Example:
set CMAKE_INSTALL_PREFIX=/usr/local and install(TARGETS hello
DESTINATION bin). 'make install' puts hello in /usr/local/bin but the
.deb contains /usr/bin/hello (missing 'local').
Same as 1)
use CPACK_PACKAGING_INSTALL_PREFIX, this is a feature not a bug.
Maybe the last issue is by design because no packaged software should
install to /usr/local. But wouldn't it be nicer if cpack either (1)
tell users that it changed some paths, (2) error out and die or (3) be
stupid and allow it?
Can anyone help me with this? Or better yet, fix it? :-)
I agree that some CPack generators behavior discrepancies are puzzling at
first
but making it more coherent is difficult without breaking backward
compatibility.
Unless I'm wrong there is nothing to fix here but the CPack documentation,
for which patches are welcome as well.
See the discussion here:
http://public.kitware.com/Bug/view.php?id=10067
And the may be sparse but existing doc on the Wiki:
http://www.cmake.org/Wiki/CMake#CPack
If you want to do some specific adjustment depending on the CPack generator
used
you may use a CPACK_PROJECT_CONFIG_FILE see doc here:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29
I hope this helps.
Thanks a lot! With three lines in CMakeLists.txt I now get the same
behaviour for 'make install' and the package generators:
set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 0) # don't prepend package name
etc. (for archive generators)
set(CPACK_PACKAGING_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
set(CPACK_SET_DESTDIR ON) # fixes absolute paths for archive generators
IMHO, it would be really sweet if cpack could default to
CPACK_SET_DESTDIR=ON and
CPACK_PACKAGING_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}. But I don't
know what that would mean in terms of backwards compatibility
breakage...
Well anyway, thanks for helping me out :-)
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] Buggy CPack generator behaviour?
2011/7/28 Eric Noulard eric.noul...@gmail.com:
2011/7/28 Bjørn Forsman bjorn.fors...@gmail.com:
Thanks a lot! With three lines in CMakeLists.txt I now get the same
behaviour for 'make install' and the package generators:
set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 0) # don't prepend package name
etc. (for archive generators)
set(CPACK_PACKAGING_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
set(CPACK_SET_DESTDIR ON) # fixes absolute paths for archive generators
IMHO, it would be really sweet if cpack could default to
CPACK_SET_DESTDIR=ON and
CPACK_PACKAGING_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}. But I don't
know what that would mean in terms of backwards compatibility
breakage...
As you guessed this is impossible without backward compat' breakage.
e.g. be aware that with CPACK_SET_DESTDIR set to ON RPM and DEB
behavior changes
namely RPM package built with that may not be relocatable.
What do you mean with 'not relocatable'? I didn't see any difference
in the archive layouts of RPM and DEB when changing CPACK_SET_DESTIR
from 'not set' to ON. Didn't you say that RPM and DEB generators sets
CPACK_SET_DESTDIR=ON *itself*?
You may set(CPACK_SET_DESTDIR ON) only for ArchiveGenerator if you
use CPACK_CONFIG_PROJECT_FILE.
Huh?
I have never used CPACK_CONFIG_PROJECT_FILE, I just
set(CPACK_SET_DESTDIR ON) in CMakeLists.txt and it fixed absolute
DESTINATION paths for the archive generators. Just like you said in
the first email. (Yay!)
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
[CMake] Buggy CPack generator behaviour?
Hi all,
I wonder if I've hit some bugs in the CPack generators, specifically
TGZ and DEB. They do not behave as I expect them to. What I expect
them to do is to generate an archive of files that look exactly like
what 'make install' puts in DESTDIR. If this is a wrong assumption
then please tell me.
So based on that assumption, here are the issues:
1. TGZ doesn't populate the archive with all needed parent
directories. A binary that 'make install' puts in
DESTDIR/usr/local/bin is put in archive_root/bin with TGZ. I would
have expected the archive to contain archive_root/usr/local/bin
(like the DEB generator does). Is there maybe a configuration option
for this?
2. TGZ fails on absolute DESTINATION paths:
CMake Error at /home/bjornfor/eraseme/build/cmake_install.cmake:44 (FILE):
file INSTALL cannot copy file /home/bjornfor/eraseme/build/hello to
/usr/bin/hello.
(And no, I don't want to run as root just to create an archive. If DEB
can handle this so should TGZ.)
3. DEB won't generate a .deb with binaries in /usr/local/bin. Example:
set CMAKE_INSTALL_PREFIX=/usr/local and install(TARGETS hello
DESTINATION bin). 'make install' puts hello in /usr/local/bin but the
.deb contains /usr/bin/hello (missing 'local').
Maybe the last issue is by design because no packaged software should
install to /usr/local. But wouldn't it be nicer if cpack either (1)
tell users that it changed some paths, (2) error out and die or (3) be
stupid and allow it?
Can anyone help me with this? Or better yet, fix it? :-)
Here is a script I've been using for playing with these issues:
### begin terminal session ###
topdir=$(pwd)
mkdir eraseme || { echo Directory exists, aborting.; exit 1; }
cd eraseme
cat EOF hello.c
#include stdio.h
int main()
{
printf(Hello world\n);
return 0;
}
EOF
mkdir etc
cat EOF etc/myconfigfile
# empty
EOF
cat EOF CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
add_executable(hello hello.c)
install(TARGETS hello DESTINATION bin)
set(SYSCONFDIR \${CMAKE_INSTALL_PREFIX}/etc CACHE PATH Location for
system configuration files)
set(CPACK_PACKAGE_CONTACT me@localhost.local)
set(CPACK_GENERATOR DEB;TGZ)
set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 0)
# TGZ generator crashes on absolute paths, DEB doesn't
#install(DIRECTORY etc/ DESTINATION \${SYSCONFDIR})
install(DIRECTORY etc/ DESTINATION .)
include(CPack)
EOF
mkdir build
cd build
cmake ..
make install DESTDIR=${topdir}/eraseme/destdir
make package
echo
echo Install tree:
#ls -lR $topdir/eraseme/destdir
tree $topdir/eraseme/destdir
echo
echo Contents of DEB:
ar -x Project-0.1.1-Linux.deb
tar tf data.tar.gz
echo
echo Contents of TGZ:
tar tf Project-0.1.1-Linux.tar.gz
cd $topdir
### end terminal session ###
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
[CMake] FindQt4.cmake to automatically include QT_USE_FILE?
Hi all, As far as I can tell, all Qt programs built with CMake must include QT_USE_FILE after find_package(). So why doesn't FindQt4.cmake simply include QT_USE_FILE itself? Is there maybe a use case where QT_USE_FILE is *not* wanted? 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] FindQt4.cmake to automatically include QT_USE_FILE?
Thanks for a quick reply! On 7 June 2011 14:52, Michael Wild them...@gmail.com wrote: On 06/07/2011 02:20 PM, Bjørn Forsman wrote: As far as I can tell, all Qt programs built with CMake must include QT_USE_FILE after find_package(). So why doesn't FindQt4.cmake simply include QT_USE_FILE itself? Is there maybe a use case where QT_USE_FILE is *not* wanted? If you don't care for the macros and want to set up the include-directories and defines yourself, no. Ok, guess I haven't had any use for that so far. Examples of when it may be useful are welcome. But, wait...isn't that the whole point of find_package()? To set up variables containing necessary includes and libs? It seems FindWt4.cmake is special in this case, needing one extra step. Also, it is common to find_package(Qt4) in the top-level CMakeLists.txt file, but then include QT_USE_FILE only in specific subdirectories, where Qt is actually used. Why not put find_package(Qt4) in the sub directories where it is actually used? 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] FindQt4.cmake to automatically include QT_USE_FILE?
On 7 June 2011 15:21, John Drescher dresche...@gmail.com wrote: If you don't care for the macros and want to set up the include-directories and defines yourself, no. Also, it is common to find_package(Qt4) in the top-level CMakeLists.txt file, but then include QT_USE_FILE only in specific subdirectories, where Qt is actually used. I have started doing that in my projects. It cuts down on the unnecessary includes for subprojects that do not need Qt. Isn't it be possible to call find_package(Qt4) only in sub-projects that use Qt? (Note to self: read up on cmake find_package() and scoping...) 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] FindQt4.cmake to automatically include QT_USE_FILE?
2011/6/7 Michael Wild them...@gmail.com: On 06/07/2011 03:38 PM, Bjørn Forsman wrote: Why not put find_package(Qt4) in the sub directories where it is actually used? And if it is used in multiple subdirectories? What's bad about that? (Sorry, I really don't know). FindXXX.cmake modules should only do the minimum, i.e. finding the required libraries and include-directories, setting XXX_FOUND, XXX_INCLUDE_DIRS and XXX_LIBRARIES. Anything more complex, e.g. calling add_definitions(), include_directories(), function(), macro() etc. should go into a UseXXX.cmake module. Ok, I didn't know about that policy. If you find a FindXXX.cmake module that calls add_definitions(), include_directories(), link_libraries() or some such, it is broken and needs to be fixed. Broken because of the above defined policy? Or of technical reasons? Sorry, but I still don't see the reason why the current find_package + use_file is better than a find_package that includes the use_file itself. What I see is that current usage goes something like this: 1) find_package(Qt4 REQUIRED) at the top level 2) subdirs that actually need Qt: set what modules to enable/disable and then include the use_file. How about doing it this way: 1) subdirs that actually need Qt: call find_package(Qt4 COMPONENTS QtCore [...] REQUIRED) with the modules it needs. Is there a problem with this approach? Other than breaking the policy ;-) 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] FindQt4.cmake to automatically include QT_USE_FILE?
On 7 June 2011 16:32, Rolf Eike Beer e...@sf-mail.de wrote:
Hi all,
As far as I can tell, all Qt programs built with CMake must include
QT_USE_FILE after find_package(). So why doesn't FindQt4.cmake simply
include QT_USE_FILE itself? Is there maybe a use case where
QT_USE_FILE is *not* wanted?
Besides the points already given here is another example:
CMakeLists.txt:
find_package(Qt4 REQUIRED)
add_subdirectory(a)
add_subdirectory(b)
a/CMakeLists.txt
SET(QT_DONT_USE_QTGUI TRUE)
INCLUDE(${QT_USE_FILE})
...
TARGET_LINK_LIBRARIES(foo ${QT_LIBRARIES})
b/CMakeLists.txt
INCLUDE(${QT_USE_FILE})
...
TARGET_LINK_LIBRARIES(bar ${QT_LIBRARIES})
So bar would get linked against QtGui, but foo not. And this all without
fiddling with all the single Qt libraries and their dependencies.
I see. I want to do the same, but slightly more readable (IMHO). If
find_package also includes the use file we could do this:
CMakeLists.txt:
add_subdirectory(a)
add_subdirectory(b)
a/CMakeLists.txt
find_package(Qt4 COMPONENTS QtCore REQUIRED)
...
TARGET_LINK_LIBRARIES(foo ${QT_LIBRARIES})
b/CMakeLists.txt
find_package(Qt4 COMPONENTS QtCore QtGui REQUIRED)
...
TARGET_LINK_LIBRARIES(bar ${QT_LIBRARIES})
foo will be linked to QtCore and bar will be linked to QtCore+QtGui.
What do you think?
___
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] FindQt4.cmake to automatically include QT_USE_FILE?
2011/6/7 Michael Wild them...@gmail.com: If the FindXXX.cmake file called add_definitions(), include_directories() et al., that could be potentially harmful. Some sources might required that some define is not set, or a wrong header file might be #include'ed (thing of all the different X.h that exist). FindXXX.cmake modules should just define a few variables, *not* change the build system. That's the caller's responsibility, either by calling the functions himself or by including the UseXXX.cmake (if provided). Ok, I see the point now. However, if find_package is called only in the subdirectories that actually need it the above problem is non-existent. No? (At least add_definitions only work on the current dir and below.) But if the policy is they way it is, then OK, I get the point and I'll leave it at that. However, according to Modules/readme.txt, FindXXX.cmake files should set XXX_LIBRARIES, XXX_INCLUDE_DIRS and XXX_DEFINITIONS. FindQt4.cmake sets neither. I can try to come up with a patch to fix this, but I won't complain if someone beats me to it ;-) 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?
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/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
[CMake] CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH, but should it?
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.
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] Cross-compiling a static library (CMake 2.8.3)
Hi, On 10 January 2011 17:00, Emmanuel Blot eblot...@gmail.com wrote: Hello, Using the ADD_LIBRARY command for a static library (.a), how to tell CMake to use the ranlib tool for the target, not the default one for the host? I'm getting the following warning message: cd watchdog /usr/local/Cellar/cmake/2.8.3/bin/cmake -E cmake_link_script CMakeFiles/nd_watchdog.dir/link.txt --verbose=1 /usr/bin/ar cr libnd_watchdog.a CMakeFiles/nd_watchdog.dir/src/nd_watchdog.c.o /usr/bin/ranlib libnd_watchdog.a /usr/bin/ranlib: warning for library: libnd_watchdog.a the table of contents is empty (no object file members in the library define global symbols) I'd like to use our dedicated arm-eabi-ranlib tool instead. When I cross compile I do set(CMAKE_C_COMPILER arm-linux-gcc) in a toolchain file and CMake automatically finds ranlib (and other toolchain utilities) using the prefix from the C compiler. How do you setup CMake for cross-compilation? Have you read http://cmake.org/Wiki/CMake_Cross_Compiling ? 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] Cross-compiling a static library (CMake 2.8.3)
Hi, (CCing the list.) 2011/1/10 Emmanuel Blot eblot...@gmail.com: When I cross compile I do set(CMAKE_C_COMPILER arm-linux-gcc) in a toolchain file and CMake automatically finds ranlib (and other toolchain utilities) using the prefix from the C compiler. How do you setup CMake for cross-compilation? INCLUDE (CMakeForceCompiler) CMAKE_FORCE_C_COMPILER (arm-eabi-gcc-4.5.2 GNU 4) I haven't used that one before. The docs say it should be used when CMake is not able to detect the compiler ID. Is that the case here? Have you tried set(CMAKE_C_COMPILER arm-linux-gcc)? Maybe the version number is the source of the trouble ? The docs say that the signature is CMAKE_FORCE_C_COMPILER(compiler compiler-id) so maybe something bad happens when you give it that extra argument 4? Try without 4? Best regards, Bjørn Forsman Have you read http://cmake.org/Wiki/CMake_Cross_Compiling ? Not for a while, however I've been using CMake for cross compiling since early releases (2.5.x), so maybe the syntax changed a bit since. ___ 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
