[CMake] QT AUTOMOC problems with latest versions
Hello, The cmake’s automoc functionality has stopped working in my codebase since version 3.8.2 and 3.9.1. My code base was compiling/building fine until I updated CMake. If I downgrade it to 3.7.9 or lower then it compiles fine again. The error code that I get is the following: Scanning dependencies of target analysis [ 65%] Building CXX object src/model/CMakeFiles/model.dir/GeneItemModel.cpp.o [ 66%] Building CXX object src/analysis/CMakeFiles/analysis.dir/AnalysisDEA.cpp.o [ 67%] Building CXX object src/viewRenderer/CMakeFiles/viewRenderer.dir/GraphicItemGL.cpp.o [ 68%] Built target viewPages [ 70%] Building CXX object src/model/CMakeFiles/model.dir/SpotItemModel.cpp.o [ 71%] Built target viewRenderer [ 72%] Building CXX object src/analysis/CMakeFiles/analysis.dir/AnalysisQC.cpp.o [ 73%] Building CXX object src/analysis/CMakeFiles/analysis.dir/AnalysisCorrelation.cpp.o [ 74%] Built target model [ 75%] Building CXX object src/analysis/CMakeFiles/analysis.dir/AnalysisClustering.cpp.o [ 76%] Building CXX object src/analysis/CMakeFiles/analysis.dir/ChartView.cpp.o [ 77%] Built target analysis Scanning dependencies of target STViewer make[2]: *** No rule to make target `src/dialogs/CMakeFiles/dialogs.dir/dialogs_autogen/moc_compilation.cpp.o', needed by `STViewer.app/Contents/MacOS/STViewer'. Stop. make[2]: *** Waiting for unfinished jobs [ 78%] Building CXX object src/CMakeFiles/STViewer.dir/main.cpp.o [ 81%] Building CXX object src/CMakeFiles/STViewer.dir/STViewer_autogen/moc_compilation.cpp.o [ 82%] Building CXX object src/CMakeFiles/STViewer.dir/mainWindow.cpp.o [ 82%] Building CXX object src/CMakeFiles/STViewer.dir/STViewer_autogen/AXPSB5LYZJ/qrc_application.cpp.o make[1]: *** [src/CMakeFiles/STViewer.dir/all] Error 2 make: *** [all] Error 2 The source is structured in different source folders and I use the cmake’s automoc set(CMAKE_AUTOMOC ON) Has anybody experienced similar issues? Has anything changed in the way cmake performs automoc since version 3.8.x? Thanks in advance! Best, Jose -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] Adding (external project) dependency to interface target
My project uses the external project functionality to download and install a headers-only library. I use an interface library to import that library dependency to my project. I'd like to add a dependency from the external project target to the interface library to trigger the library downloading and configuration process. But apparently this is not allowed and I get this error: add_dependencies Cannot add target-level dependencies to INTERFACE library target EigenExternal Is there any workaround for this or am I doing something wrong? Thanks a lot, Jose -- 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] Is it possible to show dependent files in Visual Studio folders for ADD_CUSTOM_TARGET?
Hello all,
I hope you can help me answering whether the following is possible with CMake:
We have a set of C++ libraries, some of which are header-only.
Obviously those ones don't really need to be built, but it's
interesting to define targets for them anyway to define dependencies
in other executables libraries that depend on them.
Right now, my approach to define header-only libs is like:
add_custom_target(LIB_NAME DEPENDS ${LIST_OF_HEADERS})
But then the Visual Studio (or CodeBlock) folders don't show any of
the header files, only the CMakeLists.txt file and the CMake rules
folder.
I've tried with explicit calls to SOURCE_GROUP() without results.
I would be great to have the headers shown in the project folder for
quickly opening them for editing, launching all solution files
searches, etc.
Any idea on how to achieve this? Is it possible without modifying CMake sources?
Cheers,
Jose Luis
--
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] Is it possible to show dependent files in Visual Studio folders for ADD_CUSTOM_TARGET?
That's exactly what I was looking for, thanks Fraser!
JL
On Sat, Jan 19, 2013 at 12:17 PM, Fraser Hutchison
fraser.hutchi...@gmail.com wrote:
I think this is what the SOURCES arg is for. You could just duplicate the
list of DEPENDS files as the SOURCES argument too:
add_custom_target(LIB_NAME DEPENDS ${LIST_OF_HEADERS} SOURCES
${LIST_OF_HEADERS})
Cheers,
Fraser.
--
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] Weird linking error while cross compiling
I give up. I solved the problem with the solution Michael gave me. Actually
this linking flag : -Bstatic
was the causant of the troubles.
Nevertheless now I get undefined references to functions defined in the
library portablexdr .
I have been trying to fix it for two days without success. The library is
being linked and I have checked the content of the library with
mingw32-nm and it has all the functions defined.
I have to say that I modified and rebuilt the library to include some
functions that were not present ( portableXDR does not follow the Sun XDR
standard). So I guess this is what it is
causing me the troubles but It should not since I rebuilt it without
problems and when I check the content of the library with nm the functions
are there.
Any help??
Thank you
Jose
2011/10/26 Michael Hertling mhertl...@online.de
On 10/26/2011 10:28 AM, Andreas Pakulat wrote:
On 26.10.11 03:54:02, Jose wrote:
Sorry for not being very specific.
This is the command that Cmake is running while linking :
/usr/bin/i686-pc-mingw32-g++ -O3 -O3-Wl,-Bstatic -static-libgcc
-Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a
-Wl,--no-whole-archive
-o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-L/home/fedora/percolator/percolator/src/converters/../../src
libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a
MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr
/home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a
-lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool
-lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
That is weird cos I load all the libraries in the same way and they
all
the variables content the right paths to the libraries : (for example)
Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a ,
XDR :
/usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a
This is how I link :
#COMPILING SQT2PIN
include_directories(. MSToolkit/RAMP MSToolkit )
add_executable(sqt2pin Sqt2Pin.cpp )
IF(STATIC AND MINGW)
set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)
set_target_properties(sqt2pin PROPERTIES LINK_FLAGS -Wl,-Bstatic
-static-libgcc)
ENDIF()
message(STATUS Xercesc : ${XERCESC_LIBRARIES} , XDR :
${PORTABLEXDR_LIBRARIES})
target_link_libraries(sqt2pin converters perclibrary_part MSToolkit
RAMP
${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES}
)
I might be missing something very stupid because I use the same
prodecure
to search for the librarysthe FindXXX.cmake macros that are tested
and
working with other programs.
Could it be the include_directories(library include dir) which is
messing
this up? it looks like the linker disregard the path of the library that
Im
pasinng and looks for -lxerces-c instead. Is that xerces-c defined
somehow
before?
This happens if the library is considered to be in a 'system path' since
in that case specifying the path is not necessary for the linker to find
it. However in your specific case it seems like cmake does this even for
static libraries, which is of course wrong. I'd suggest to file a
bugreport for this with a small self-contained example.
Andreas
The -l switch of ld is not related to the library's type, i.e.
shared or static; see ld's manpage and the following example:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(STATIC C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c int f(void){return 0;}\n)
EXECUTE_PROCESS(COMMAND ${CMAKE_C_COMPILER} -c f.c)
EXECUTE_PROCESS(COMMAND ${CMAKE_AR} cr libf.a f.o)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return f();}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main -L${CMAKE_BINARY_DIR} f /usr/lib/libz.a)
The executable main is linked against the static libf.a via the -l
switch. Usually, in particular on ELF systems, ld just prefers shared
libraries with -l unless it is told to not do so, e.g. using -Bstatic.
However, MinGW's ld behaves differently in this regard; IIRC, it even
prefers static and import libraries to shared ones with the -l switch.
BTW, /usr/lib/libz.a is converted into -Wl,-Bstatic -lz -Wl,-Bdynamic
due to /usr/lib being a system directory, i.e. CMake performs this -l
conversion of full paths in system directories for static libraries,
too; why should it be called wrong?
Jose, could you find out which directories CMake considers as system
directories and if these are actually
Re: [CMake] Weird linking error while cross compiling
Sorry for not being very specific.
This is the command that Cmake is running while linking :
/usr/bin/i686-pc-mingw32-g++ -O3 -O3-Wl,-Bstatic -static-libgcc
-Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a -Wl,--no-whole-archive
-o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-L/home/fedora/percolator/percolator/src/converters/../../src
libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a
MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr
/home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a
-lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
That is weird cos I load all the libraries in the same way and they all
the variables content the right paths to the libraries : (for example)
Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a , XDR :
/usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a
This is how I link :
#COMPILING SQT2PIN
include_directories(. MSToolkit/RAMP MSToolkit )
add_executable(sqt2pin Sqt2Pin.cpp )
IF(STATIC AND MINGW)
set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)
set_target_properties(sqt2pin PROPERTIES LINK_FLAGS -Wl,-Bstatic
-static-libgcc)
ENDIF()
message(STATUS Xercesc : ${XERCESC_LIBRARIES} , XDR :
${PORTABLEXDR_LIBRARIES})
target_link_libraries(sqt2pin converters perclibrary_part MSToolkit RAMP
${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES} )
I might be missing something very stupid because I use the same prodecure
to search for the librarysthe FindXXX.cmake macros that are tested and
working with other programs.
Could it be the include_directories(library include dir) which is messing
this up? it looks like the linker disregard the path of the library that Im
pasinng and looks for -lxerces-c instead. Is that xerces-c defined somehow
before?
Thank you so much
Jose
2011/10/25 Andreas Pakulat ap...@gmx.de
On 25.10.11 13:15:37, Jose wrote:
Hi all,
I'm cross compiling an app under Fedora. I get this linking errors while
building with cmake :
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
The thing is that the libraries have been found,included and linked with
target_link_libraries. I'm adding all the necessary flags to link
statically
and the libraries are the ones included in the mingw package. It shoud
work
because a different part of the application that uses almost the same
libraries is cross compiling perfectly. The cmake files are actually
pretty
much the same so I don't really know what I'm doing wrong. Cmake might be
missing the libraries or the path of the libraries
Hmm, -lfoo means the linker will search for a shared library. Linking
static libraries is done by specifying the absolute path to the library
file. How exactly are you calling target_link_libraries and assuming
that you're passing above libraries via cmake-variables whats the
content of those variables?
Andreas
--
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
[CMake] Weird linking error while cross compiling
Hi all, I'm cross compiling an app under Fedora. I get this linking errors while building with cmake : /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld: cannot find -lxerces-c /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld: cannot find -lportablexdr /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld: cannot find -lz /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld: cannot find -lsqlite3 The thing is that the libraries have been found,included and linked with target_link_libraries. I'm adding all the necessary flags to link statically and the libraries are the ones included in the mingw package. It shoud work because a different part of the application that uses almost the same libraries is cross compiling perfectly. The cmake files are actually pretty much the same so I don't really know what I'm doing wrong. Cmake might be missing the libraries or the path of the libraries Have you guys come across something like this before?? Best Regards Jose -- 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] Compiling and building using boost under Windows.
Hi everyone, I'm trying to compile in Windows an app that I have been working on in Ubuntu for a while. My problem is that FindBoost.cmake does not find my boost libraries even though they are in the system. I have them compiled with the compiler vc71, vc80.and so on I indicate in my cmake file to use : SET (BOOST_LIB_PREFIX lib) SET (BOOST_COMPILER -vc71) //tried the other compilers as well. FindBoost finds my boost directory but it does not find the libraries. The libraries look like this : libboost_filesystem-vcXX-mt-1_47 , boost_filesystem-vcXX-mt-1_47 and libboost_filesystem-vcXX-mt-1_47.dll It looks like it is a problem that can be fixed modifying some boost variables like prefixes or suffixes but I have tried some combinations and didn't come up with a solution that works Any kind of help would be appreciated. Thanks Regards Jose -- 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] Cross Compilation problem
Hello all,
I have been struggling with this problem for 2 days and I cannot really find
a solution.
I have a c++ application that I want to cross compile under Fedora 15 to
use it with Windows.
The packages that my app depends on are already pre-compiled in :
/usr/i686-mingw32./
I am using CMake. It compiles okay and I generate the .exe file without
problems.
When I try to run it under Windows it complains :
The program cant start because boost_filesystem-gcc45-mt-1_46_1.dll
ins missing...
I have boost 1.47 installed in the windows machine but the libraries have a
different suffix (...vc-xx-mt...)
When I cross compile I do it statically ( I am attaching my
toolchain-mingw32 file )
My question is, why is the exe program looking for the boost dll with
exactly the same name as it has in the linux
machine where the cross compiled exe has been built from??
In my fedora mingw32 lib folder the boost libraries look like this :
libboost_filesystem-gcc45-mt-1_46_1.dll·a
Is there any way to tell cmake to disregard those suffixes while running in
Windows?
Is there any way to tell cmake to copy the boost libraries needed for my
application into a local folder that will be included
inside the the windows installer??
Also while cross compiling I had gotten this error :
In file included
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash/detail/hash_float.hpp:17,
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash/hash.hpp:15,
from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash.hpp:6,
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/unordered/unordered_set.hpp:17,
from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/unordered_set.hpp:16,
from /mnt/VirtualBoxShare/percolator/src/ProteinProbEstimatorHelper.h:33,
from /mnt/VirtualBoxShare/percolator/src/ProteinProbEstimator.cpp:28:
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: expected unqualified-id before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: expected ';' before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: declaration does not declare anything
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: expected unqualified-id before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: expected ';' before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: declaration does not declare anything
It seemed boost defines a typedf in cstdint that is already defined in
somewhere else, I would guess it is because the windows flag is
activated
even though it is compiling under linux. I fixed it checking it the
definition has been made already but this is not a proper solution.
Is it maybe that definition in my code or another cross compiled library?
Tool chain file :
SET(CMAKE_SYSTEM_NAME Windows)
# specify the cross compiler
find_file(MINGWV NAMES i586-mingw32msvc-gcc i586-mingw32msvc-g++ PATHS
/usr/bin
/usr/local/bin)
if(NOT MINGWV)
set(MINGW_PREFIX /usr/bin/i686-pc-mingw32-)
SET(Boost_COMPILER -gcc45)
else(NOT MINGWV)
set(MINGW_PREFIX /usr/bin/i586-mingw32msvc-)
SET(Boost_COMPILER -mgw)
endif(NOT MINGWV)
# set(CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} -mwindows
-mthreads -static-libgcc)
# set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_DEBUG} -mwindows -mthreads
-static-libgcc)
# SET(CMAKE_SHARED_LINKER_FLAGS
-Wl,--no-undefined,--fix-cortex-a8,-lsupc++ -lstdc++
-L${CMAKE_INSTALL_PREFIX}/lib)
# SET(CMAKE_MODULE_LINKER_FLAGS
-Wl,--no-undefined,--fix-cortex-a8,-lsupc++ -lstdc++
-L${CMAKE_INSTALL_PREFIX}/lib)
set(CMAKE_C_COMPILER${MINGW_PREFIX}gcc)
set(CMAKE_CXX_COMPILER ${MINGW_PREFIX}g++)
set(CMAKE_RC_COMPILER ${MINGW_PREFIX}windres)
# set(CMAKE_AR ${MINGW_PREFIX}ar)
set(CMAKE_RANLIB${MINGW_PREFIX}ranlib)
set(CMAKE_LINKER${MINGW_PREFIX}ld)
set(CMAKE_STRIP ${MINGW_PREFIX}strip)
set(CMAKE_EXECUTABLE_SUFFIX .exe)
# Boost Configuration
SET(Boost_USE_STATIC_LIBS ON)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH
/usr/i686-pc-mingw32;/usr/i586-mingw32msvc;/usr/i686-pc-mingw32/sys-root/mingw;/usr/i586-mingw32msvc/sys-root/mingw;
/home/USERNAME/i586-mingw32msvc;/home/USERNAME/i686-pc-mingw32;${CMAKE_PREFIX_PATH};
${PROJECT_SOURCE_DIR}/../libs;${PROJECT_SOURCE_DIR}/libs;${PROJECT_SOURCE_DIR}/../../libs)
# 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)
Thank you so much
Jose
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages
[CMake] Cross Compilation problem
Hello all,
I have been struggling with this problem for 2 days and I cannot really find
a solution.
I have a c++ application that I want to cross compile under Fedora 15 to
use it with Windows.
The packages that my app depends on are already pre-compiled in :
/usr/i686-mingw32./
I am using CMake. It compiles okay and I generate the .exe file without
problems.
When I try to run it under Windows it complains :
The program cant start because boost_filesystem-gcc45-mt-1_
46_1.dll ins missing...
I have boost 1.47 installed in the windows machine but the libraries have a
different suffix (...vc-xx-mt...)
When I cross compile I do it statically ( I am attaching my
toolchain-mingw32 file )
My question is, why is the exe program looking for the boost dll with
exactly the same name as it has in the linux
machine where the cross compiled exe has been built from??
In my fedora mingw32 lib folder the boost libraries look like this :
libboost_filesystem-gcc45-mt-1_46_1.dll·a
Is there any way to tell cmake to disregard those suffixes while running in
Windows?
Is there any way to tell cmake to copy the boost libraries needed for my
application into a local folder that will be included
inside the the windows installer??
Also while cross compiling I had gotten this error :
In file included
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash/detail/hash_float.hpp:17,
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash/hash.hpp:15,
from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash.hpp:6,
from
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/unordered/unordered_set.hpp:17,
from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/unordered_set.hpp:16,
from /mnt/VirtualBoxShare/percolator/src/ProteinProbEstimatorHelper.h:33,
from /mnt/VirtualBoxShare/percolator/src/ProteinProbEstimator.cpp:28:
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: expected unqualified-id before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: expected ';' before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105:
error: declaration does not declare anything
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: expected unqualified-id before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: expected ';' before 'unsigned'
/usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114:
error: declaration does not declare anything
It seemed boost defines a typedf in cstdint that is already defined in
somewhere else, I would guess it is because the windows flag is
activated
even though it is compiling under linux. I fixed it checking it the
definition has been made already but this is not a proper solution.
Is it maybe that definition in my code or another cross compiled library?
Tool chain file :
SET(CMAKE_SYSTEM_NAME Windows)
# specify the cross compiler
find_file(MINGWV NAMES i586-mingw32msvc-gcc i586-mingw32msvc-g++ PATHS
/usr/bin
/usr/local/bin)
if(NOT MINGWV)
set(MINGW_PREFIX /usr/bin/i686-pc-mingw32-)
SET(Boost_COMPILER -gcc45)
else(NOT MINGWV)
set(MINGW_PREFIX /usr/bin/i586-mingw32msvc-)
SET(Boost_COMPILER -mgw)
endif(NOT MINGWV)
# set(CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} -mwindows
-mthreads -static-libgcc)
# set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_DEBUG} -mwindows -mthreads
-static-libgcc)
# SET(CMAKE_SHARED_LINKER_FLAGS
-Wl,--no-undefined,--fix-cortex-a8,-lsupc++ -lstdc++
-L${CMAKE_INSTALL_PREFIX}/lib)
# SET(CMAKE_MODULE_LINKER_FLAGS
-Wl,--no-undefined,--fix-cortex-a8,-lsupc++ -lstdc++
-L${CMAKE_INSTALL_PREFIX}/lib)
set(CMAKE_C_COMPILER${MINGW_PREFIX}gcc)
set(CMAKE_CXX_COMPILER ${MINGW_PREFIX}g++)
set(CMAKE_RC_COMPILER ${MINGW_PREFIX}windres)
# set(CMAKE_AR ${MINGW_PREFIX}ar)
set(CMAKE_RANLIB${MINGW_PREFIX}ranlib)
set(CMAKE_LINKER${MINGW_PREFIX}ld)
set(CMAKE_STRIP ${MINGW_PREFIX}strip)
set(CMAKE_EXECUTABLE_SUFFIX .exe)
# Boost Configuration
SET(Boost_USE_STATIC_LIBS ON)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH
/usr/i686-pc-mingw32;/usr/i586-mingw32msvc;/usr/i686-pc-mingw32/sys-root/mingw;/usr/i586-mingw32msvc/sys-root/mingw;
/home/USERNAME/i586-mingw32msvc;/home/USERNAME/i686-pc-mingw32;${CMAKE_PREFIX_PATH};
${PROJECT_SOURCE_DIR}/../libs;${PROJECT_SOURCE_DIR}/libs;${PROJECT_SOURCE_DIR}/../../libs)
# 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)
Thank you so much
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic
[CMake] Notes not showing up on CDash
I have been trying to upload files as notes for my builds using the ctest_submit(PARTS Notes) command. When i run the script it shows submissions successful but when i check the dashboard i cannot find any notes. What am i doing wrong ? Regards Johny ___ 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] Custom memory checking result processing
Dear all, I am using valgrind to debug a framework which depends on several other underlying frameworks to function properly. As a result my memory checking turns up thousands of errors. I only want to see errors that arise from my framework. This is figured can be done by simply looking for a few regular expressions in the stack trace. Right now i am planning on creating a custom perl script which i will use as the memchecker instead of valgrind and send its output to CDash. Suppression files don't seem feasible as they don't have any sort of RegEx support and i have too many errors to list in a file creating ridiculously large logs and suppression files. I was wondering is there any better way to tackle this problem ? Regards Johny ___ 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] Custom memory checking result processing
Thanks for the suggestions, but i already went down these paths. The problem is
my logs in xml format on an average go above 100 MB of output, with
gen-suppressions i get 300MB output files and the suppressions file generated
out of these is again way too big for my liking.
If only valgrind had more features in terms of expressing suppression rules
like some sort of pattern matcher which would suppress all errors except the
matching ones it would have been easier, because the errors i want to look at
match a contain a particular pattern. Right now the only workaround is manually
parsing the xml log file and selecting the errors i want to see. I used to have
problems viewing these results too on CDash because of the huge file sizes.
Using a generated suppression files even if i optimized it with wildcards is
not feasible since i have no way of knowing which errors i don't need but i do
know which errors i do need. It would be a really great feature to add to
valgrind.
Regards,
Johny
-Original Message-
From: cmake-boun...@cmake.org on behalf of Bill Hoffman
Sent: Fri 6/25/2010 4:17 PM
To: cmake@cmake.org
Subject: Re: [CMake] Custom memory checking result processing
On 6/25/2010 7:47 AM, David Cole wrote:
I can't really think of a better way to tackle the problem...
But I will make this one observation:
If these underlying frameworks you depend on produce *thousands* of
valgrind errors, do you really want to be depending on them?
(Serious question, not trying to be flippant... It would make me very
nervous to depend on a framework that has more than a handful of
valgrind issues: and each issue would have to be something that I was
convinced did not have a high likelihood of occurring in real world
usage scenarios.)
So, lots of things that you have to use like libX11 have tons and tons
of valgrind stuff in them. Some are not real, some are, but you still
have to use those libraries as they are. What you do is create a
valgrind suppression file. What I usally do is run valgrind with
--gen-suppressions=all. This makes valgrind spit out the exact text to
put in the suppression file. This output will show up on the dashboard.
You use that to create a suppression file that you pass to valgrind.
Then you set this in the cache:
MEMORYCHECK_SUPPRESSIONS_FILE:FILEPATH=${CTEST_MEMORYCHECK_SUPPRESSIONS_FILE}
CTEst will then use that as a suppression file. You keep adding to the
suppression file until you have it like you want. Many times it is the
same thing over and over, so a few suppressions go a long way.
-Bill
___
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
[CMake] Alternative IDL compiler, and adding non-present sources
Hi all! Issue 1: Porting an old project to CMake I realized there's no way to modify the predefined behavior when one adds an IDL file to a Visual Studio project, which is associating it to midl. In our project we'd rather need to execute a different IDL compiler (TAO_IDL), but declaring an add_custom_command i.e. in PREBUILD has no effect since the midl association is hard-coded in the generator. I am thinking on writing a patch for this, but prefer to have opinions about the preferred way to do it to be consistent with the rest of CMake commands and variables. Issue 2: Also related to the compilation of IDL files: If .cpp/.h files, which does not exist yet but will be built by the IDL compiler, are added to the project, CMake correctly complains about non-existing sources... Is there any way to force CMake to add them and trust us that those sources will exist someday? Thanks! Jose Luis -- ___ Jose-Luis Blanco-Claraco Phone: +34 952 132848 Dpto. Ingenieria de Sistemas y Automatica E.T.S.I. Telecomunicacion Fax: +34 952 133361 Universidad de Malaga Campus Universitario de Teatinos 29071 Malaga, Spain http://www.isa.uma.es/jlblanco ___ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Search paths for FooConfig.cmake files
Hello CMake developers!
I've been thinking it would be interesting that CMake could look for
FooConfig.cmake package files in some likely paths such as C:\Program
Files\Foo-XXX\ . This is for Windows, of course, but perhaps could be
extended to /opt/foo-XXX/ in Unix systems.
I've written a patch for this task:
http://public.kitware.com/Bug/view.php?id=8264
I know the order in which directories are searched IS an issue, and I
decided it's place seems to be between these two paths:
=
...
4. Search the standard system environment variables. This can be skipped
if NO_SYSTEM_ENVIRONMENT_PATH is passed. Path entries ending in /bin
or /sbin are automatically converted to their parent directories.
PATH
5. Typical instalation paths. For now this only applies to Windowsfor
the paths that match the following pattern (where name iscase
insensitive):
${ProgramFiles}/name* (W)
6. Search project build trees recently configured in a CMake GUI. This
can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for the
case when a user is building multiple dependent projects one after another.
...
=
I'd be glad of seeing this feature in future releases of CMake, so
please let me know if anyone see any compatibility problem in this patch
and how to deal with it.
Best,
JL
--
___
Jose-Luis Blanco-Claraco Phone: +34 952 132848
Dpto. Ingenieria de Sistemas y Automatica
E.T.S.I. Telecomunicacion Fax: +34 952 133361
Universidad de Malaga
Campus Universitario de Teatinos
29071 Malaga, Spain
http://www.isa.uma.es/jlblanco
___
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]
These are my results: All the details go below, but in two computers, both with cmake 2.6.0 (from the Ubuntu repositories), it takes ~ 50sec vs. 19sec to recompile when only one file changes... and the longest delay happens in the better PC, though the CPU's are very similar in speeds. Both cases are local file systems (through ntfs, but the same in both cases). In addition, I started with a fresh CMAKE_BINARY_DIR directory in both cases. Please, let me know if I can do any more logging. Regards, JL = PC #1 DESKTOP PC, QuadCore 2.4Ghz: = == touch'ing just one .cpp file in the project, the time make VERBOSE=1 gives: 49.882s cd /home/jlblanco/code/mrpt-release /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/jlblanco/code/mrpt-src /home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release /home/jlblanco/code/mrpt-release/src/core /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake --color= Most of the time goes in these 3 steps: Dependee /home/jlblanco/code/mrpt-src/src/core/math/CMatrix.cpp is newer than depender src/core/CMakeFiles/mrpt-core.dir/math/CMatrix.o. Clearing dependencies in /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make. Clearing dependencies in /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make. Scanning dependencies of target mrpt-core Longest task real0m49.882s user0m5.424s sys0m7.064s == without touching (just realizing there's nothing to do): 12.89s Most of the time goes in: cd /home/jlblanco/code/mrpt-release /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/jlblanco/code/mrpt-src /home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release /home/jlblanco/code/mrpt-release/src/core /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake --color= real0m12.896s user0m1.384s sys0m1.560s = PC # 2 LAPTOP PC, DualCore 2.0Ghz: = == touch'ing just one .cpp file in the project, the time make VERBOSE=1 gives: 18.78s Most of the tiime goes to: cd /home/jlblanco/code/mrpt-release /usr/bin/cmake -E cmake_depends Unix Makefiles /home/jlblanco/code/mrpt-src /home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release /home/jlblanco/code/mrpt-release/src/core /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake --color= Dependee /home/jlblanco/code/mrpt-src/src/core/utils/CMRPTImage.cpp is newer than depender src/core/CMakeFiles/mrpt-core.dir/utils/CMRPTImage.o. Clearing dependencies in /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make. Scanning dependencies of target mrpt-core real0m18.788s user0m7.456s sys0m4.552s == without touching (just realizing there's nothing to do): 2.23s real0m2.234s user0m1.468s sys0m0.528s On Thu, Dec 4, 2008 at 4:02 AM, Bill Hoffman [EMAIL PROTECTED]wrote: Jose Luis Blanco wrote: If this helps anyone, I'm working on a large project using CMake and in two different computers, both with the same version of Ubuntu and cmake, it is *REALLY SLOW* in only one of them while scanning dependencies, but it's not in the other laptop. (The slow dep. scanning is ~1 min. too) I'd be happy to help debugging this, because it's really annoying :-( I wonder if it is hitting a network mount disk or something like that... Are the same versions of cmake identical binaries? -Bill -- ___ Jose-Luis Blanco-Claraco Phone: +34 952 132848 Dpto. Ingenieria de Sistemas y Automatica E.T.S.I. Telecomunicacion Fax: +34 952 133361 Universidad de Malaga Campus Universitario de Teatinos 29071 Malaga, Spain http://www.isa.uma.es/jlblanco ___ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]
If this helps anyone, I'm working on a large project using CMake and in two different computers, both with the same version of Ubuntu and cmake, it is *REALLY SLOW* in only one of them while scanning dependencies, but it's not in the other laptop. (The slow dep. scanning is ~1 min. too) I'd be happy to help debugging this, because it's really annoying :-( Regards, Jose Luis On Thu, Dec 4, 2008 at 12:46 AM, Senanu Pearson [EMAIL PROTECTED]wrote: Hi folks, Is there a way to speed up the dependency scan in version 2.6? I recently installed a new Linux OS (Mandriva 2009) which included an upgrade to cmake 2.6 (I _think_ I had version 2.4 before). However, when I run make (after running cmake .) it takes a long time (1min) to do the dependency scan. (i.e. the time when the message Scanning dependencies of target foo is printed) whereas the rest of the build takes about 10 seconds. This happens every time I run make but it does successfully build (and the cmake . step is fast). I did not experienced such slow down when going from 2.4 to 2.6 would you be able to try a CMake 2.4 on the same system? You may 1) download a tarball http://www.cmake.org/files/v2.4/cmake-2.4.8-Linux-i386.tar.gz 2) untar it somewhere, 3) update you path 4) retry the build. The odd thing is that it was almost instantaneous (with essentially the same code) under version 2.4 and is almost instantaneous on a (faster) mac (again, with the same code). CMake is not the only thing which have changed then: - system - compiler -- this may be important. - disk speed, cpu, ..; -- Erk Erk, Yes, you are right - the 2.4 build doesn't seem to be any faster. All my hardware is the same but I'm using gcc 4.3.2 and KDE4. Still, it seems strange that it is so incredibly slow. Unless anyone can offer a better solution, I'm inclined to simply switch targets in the Makefile so that I can get a quick build without having to do quite as much typing every time (yeah, and break my habit, too). Thank you, Mark ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- ___ Jose-Luis Blanco-Claraco Phone: +34 952 132848 Dpto. Ingenieria de Sistemas y Automatica E.T.S.I. Telecomunicacion Fax: +34 952 133361 Universidad de Malaga Campus Universitario de Teatinos 29071 Malaga, Spain http://www.isa.uma.es/jlblanco ___ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
