Re: [CMake] Does find_library check that a found library does in fact link?
On 09/28/2011 07:47 AM, Clifford Yapp wrote: On Wed, Sep 28, 2011 at 12:13 AM, Michael Wild them...@gmail.com mailto:them...@gmail.com wrote: On 09/28/2011 02:44 AM, Clifford Yapp wrote: I've run into a situation where find_library is returning a symlink: /usr/lib/libblah.so - libblah.so.1 but libblah.so.1 does not actually exist (e.g. the symlink is bad). Is there an option I can set to have find_library ensure that a found library file is valid and links? Cheers, CY Yes, but you need to do it yourself, e.g. use the CheckFunctionExists module. Michael Urm. That's surprising, and not so hot in that it leads to false positives in find_library reports. Has anyone wrapped find_library with a generic linking test successfully? CY Only if your installation is broken ;-) If the symlink is broken, I consider this to be a user-error. Period. OTOH, CMake /could/ check whether the library is a symlink, and if it is, check that it is valid. But how do you test whether a library is linkable? Specifically, I'm thinking about static libraries. First, only referenced symbols are linked, so that's kind of difficult to handle as CMake would need to know at least one symbol name to force the library to be linked at all, secondly static libraries may have transitive dependencies which CMake doesn't know about, so it's not possible to link an executable. On Unix you could create a shared library for the link test, but that depends on the linker flags being used, and on Windows you can't, since DLL's may not contain unresolved symbols. I don't think that there is any good way to handle this in find_library(). 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
[CMake] Converting QMake project to CMake
Hi, i'm trying to convert a qmake project to CMake. How can i translate CONFIG to CMake or what is the CMake's way of using the CONFIG variable? e.g. CONFIG += mylib Is this the CMake equivalent: SET(mylib TRUE) Thanks in Advance Best Regards NoRulez -- 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] Does find_library check that a found library does in fact link?
2011/9/28 Michael Wild them...@gmail.com: On 09/28/2011 07:47 AM, Clifford Yapp wrote: On Wed, Sep 28, 2011 at 12:13 AM, Michael Wild them...@gmail.com mailto:them...@gmail.com wrote: On 09/28/2011 02:44 AM, Clifford Yapp wrote: I've run into a situation where find_library is returning a symlink: /usr/lib/libblah.so - libblah.so.1 but libblah.so.1 does not actually exist (e.g. the symlink is bad). Is there an option I can set to have find_library ensure that a found library file is valid and links? Cheers, CY Yes, but you need to do it yourself, e.g. use the CheckFunctionExists module. Michael Urm. That's surprising, and not so hot in that it leads to false positives in find_library reports. Has anyone wrapped find_library with a generic linking test successfully? CY Only if your installation is broken ;-) If the symlink is broken, I consider this to be a user-error. Period. OTOH, CMake /could/ check whether the library is a symlink, and if it is, check that it is valid. I agree that the breakage is on user side and not CMake. However CMake may just warn that the found symlink is broken, and nothing more. At least the user won't be puzzled by a non-working build. But how do you test whether a library is linkable? Specifically, I'm thinking about static libraries. First, only referenced symbols are linked, so that's kind of difficult to handle as CMake would need to know at least one symbol name to force the library to be linked at all, secondly static libraries may have transitive dependencies which CMake doesn't know about, so it's not possible to link an executable. On Unix you could create a shared library for the link test, but that depends on the linker flags being used, and on Windows you can't, since DLL's may not contain unresolved symbols. I don't think that there is any good way to handle this in find_library(). Agreed as well but this is another story. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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
[CMake] (no subject)
Hello,
I'm having trouble getting FIND_PATH to work in a certain case. I have it
working in other Find*.cmake files, but in one of my files I cannot seem to get
it to cooperate and cmake --trace/--debug-output don't seem to provide any
useful information for debugging FIND_PATH.
The problem is that cmake generates a NOTFOUND error when using the following
cmake file (DEV_ROOT is set to /home/jlk/dev):
FindTinyXML.cmake:
FIND_PATH( TinyXML_INCLUDE_DIRSNAMES tinyxml.hPATHS
$ENV{DEV_ROOT}/externals/tinyxml )
MESSAGE( STATUS ${TinyXML_INCLUDE_DIRS} )MESSAGE( STATUS
$ENV{DEV_ROOT}/externals/tinyxml )
FIND_LIBRARY( TinyXML_LIBRARY_DebugNAMES tinyxml
PATHS $ENV{DEV_ROOT}/externals/tinyxml/Debug )
FIND_LIBRARY( TinyXML_LIBRARY_ReleaseNAMES tinyxml
PATHS $ENV{DEV_ROOT}/externals/tinyxml/Release )
SET( TinyXML_FOUND FALSE )
IF( TinyXML_INCLUDE_DIRS )SET( TinyXML_FOUND TRUE )SET(
TinyXML_LIBRARIES ${TinyXML_LIBRARIES}debug
${TinyXML_LIBRARY_Debug}optimized ${TinyXML_LIBRARY_Release}
)ENDIF()
The two MESSAGE outputs from cmake are:
-- TinyXML_INCLUDE_DIRS-NOTFOUND-- /home/jlk/dev/externals/tinyxml
The part I do not understand is if I execute an ls command like so: ls -la
/home/jlk/dev/externals/tinyxml/tinyxml.h
The output I get is: -rw-r--r-- 1 jlk jlk 64574 2011-09-27 02:58
/home/jlk/dev/externals/tinyxml/tinyxml.h
Which, as far as I understand it, is the file that cmake should be looking for.
Does anyone know what could be wrong? As I said, I have other Find*.cmake files
that work and I just can't seem to spot the problem.
--
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] (no subject)
Hello,
I'm having trouble getting FIND_PATH to work in a certain case. I have it
working in other Find*.cmake files, but in one of my files I cannot seem
to get it to cooperate and cmake --trace/--debug-output don't seem to
provide any useful information for debugging FIND_PATH.
The problem is that cmake generates a NOTFOUND error when using the
following cmake file (DEV_ROOT is set to /home/jlk/dev):
FindTinyXML.cmake:
FIND_PATH( TinyXML_INCLUDE_DIRSNAMES tinyxml.h
PATHS $ENV{DEV_ROOT}/externals/tinyxml )
MESSAGE( STATUS ${TinyXML_INCLUDE_DIRS} )MESSAGE( STATUS
$ENV{DEV_ROOT}/externals/tinyxml )
FIND_LIBRARY( TinyXML_LIBRARY_DebugNAMES tinyxml
PATHS $ENV{DEV_ROOT}/externals/tinyxml/Debug )
FIND_LIBRARY( TinyXML_LIBRARY_ReleaseNAMES tinyxml
PATHS $ENV{DEV_ROOT}/externals/tinyxml/Release )
SET( TinyXML_FOUND FALSE )
IF( TinyXML_INCLUDE_DIRS )SET( TinyXML_FOUND TRUE )SET(
TinyXML_LIBRARIES ${TinyXML_LIBRARIES}debug
${TinyXML_LIBRARY_Debug}optimized ${TinyXML_LIBRARY_Release}
)ENDIF()
The two MESSAGE outputs from cmake are:
-- TinyXML_INCLUDE_DIRS-NOTFOUND-- /home/jlk/dev/externals/tinyxml
The part I do not understand is if I execute an ls command like so: ls -la
/home/jlk/dev/externals/tinyxml/tinyxml.h
The output I get is: -rw-r--r-- 1 jlk jlk 64574 2011-09-27 02:58
/home/jlk/dev/externals/tinyxml/tinyxml.h
Which, as far as I understand it, is the file that cmake should be looking
for. Does anyone know what could be wrong? As I said, I have other
Find*.cmake files that work and I just can't seem to spot the problem.
My first attempt would be to run the cmake process trough strace -f
-eopen,stat cmake ... and look which files it is actually looking at.
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] Converting QMake project to CMake
NoRulez wrote: Hi, i'm trying to convert a qmake project to CMake. How can i translate CONFIG to CMake or what is the CMake's way of using the CONFIG variable? e.g. CONFIG += mylib Is this the CMake equivalent: SET(mylib TRUE) No, probably not. What does CONFIG += mylib do for a third party lib? This link says CONFIG only accepts values with internal meaning to qmake: http://doc.qt.nokia.com/latest/qmake-variable-reference.html#config Thanks, Steve. -- 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] multiple source directories
Hi all,
I have a project with the following structure:
root/
CMakeLists.txt
prog1/
CMakeLists.txt
Src/
file1.f90
prog2/
CMakeLists.txt
Src/
file2.f90
where prog1, prog2 are individual projects.
I would like to add file1.90 to the build process of prog2. To do so, in
the CMakeLists.txt file of prog2 project, I put:
set(SOURCES ../../prog1/Src/file1.f90
Src/file2.f90)
and further
add_executable(prog2 ${SOURCES})
when compiling with CMake I get the following error:
##
CMake Error at CMakeLists.txt:35 (add_executable):
Cannot find source file:
../../prog1/Src/file1.f90
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx
###
It seems that CMake cna not deal with relative path when declaring the
sources for a project. I tried using the option CMAKE_USE_RELATIVE_PATHS
but it might not be defined for that purpose as it did not solve the
problem. Would you have any idea how to solve that problem ?
thanks a lot
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] How to use add_custom_command correctly
On 27.09.11 18:24, Michael Wild wrote:
On 09/27/2011 05:59 PM, Martin Kupke wrote:
Hi,
in my project there is a subfolder which SHALL contain sources to
generate a library. The problem is that at startup of the project there
are no source files existing, because they will be generated by a code
generator. This means within the build process the code generator needs
to be called first, then generates the output files in the subfolder and
then a library shall be generated from that source files (this are
standard .c and .h files). If I start the code generator by hand to
generate the source files and remove the custom command, then the
compilation is successful, but I want the code generator to be started
every time the configuration file for the code generator has changed.
In my sample below
* the driver.c would be one of the files which the code generator would
generate
* the variable CodeGen is the executable tool (the code generator himself)
* the variable CodeGenParam contains the parameters which are passed to
be able to generate without any user interaction
* the variable CodeGenConfig is the input file for the code generator
This subfolder contains its own CMakeLists.txt with the following settings:
# snip #
project(CANstack C)
add_custom_command( OUTPUT driver.c
COMMAND ${CodeGen}
${CodeGenParam}
DEPENDS ${CodeGenConfig} )
)
file(GLOB CANstack_srcs *.c)
file(GLOB CANstack_hdrs *.h)
set(lib_name CANstack)
add_library(${lib_name} STATIC ${CANstack_srcs} ${CANstack_hdrs})
# snap #
I don't get it work that the custom command is called and the source
files from the code generator are produced.
A few issues here:
- Never generate output in the source tree, only in the binary tree.
- Always use absolute paths with add_custom_command().
I use the absolute paths
- Always list *all* outputs after the OUTPUT argument, otherwise CMake
won't know that they are generated sources.
I added the list of *all* files which shall be generated
- Never use file(GLOB ...). It is evil. And breaks in your case. Just don't.
I don't use the file(GLOB ...) anymore in this CMakeLists.txt
Michael
In case the generated output files already exist and the dependency file
${CodeGenConfig} has been touched, then the output will be generated.
Typically there is from beginning of the project no source file
existing, because the generator needs to be run first. If the output
files are not existing, then I get an error message from CMake:
# snip #
CMake Error at Generated/CarIF_Appl/CANstack/CMakeLists.txt:31
(add_library):
Cannot find source file:
D:/project/Discovery/Generated/Driver/uart.c
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
# snap #
How do I have to instruct CMake to run the code generator first, so that
the library can be build of that sources?
Br,
Martin
--
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] multiple source directories
I have a same problem (even relative paths should not be used, as I
understood from documentation) and I fixed my problem by setting a
variable in the /root/CMakeLists.txt e.g.
set( MY_PROJECT_PROG1 ${CMAKE_CURRENT_SOURCE_DIR}/prog1 )
set( MY_PROJECT_PROG2 ${CMAKE_CURRENT_SOURCE_DIR}/prog2 )
The subprojects / subfolders always inherit the settings / variables, so
you can work with ${MY_PROJECT_PROG1} in your /root/prog1/CMakeLists.txt.
Martin
On 28.09.11 12:51, pellegrini wrote:
Hi all,
I have a project with the following structure:
root/
CMakeLists.txt
prog1/
CMakeLists.txt
Src/
file1.f90
prog2/
CMakeLists.txt
Src/
file2.f90
where prog1, prog2 are individual projects.
I would like to add file1.90 to the build process of prog2. To do so, in
the CMakeLists.txt file of prog2 project, I put:
set(SOURCES ../../prog1/Src/file1.f90
Src/file2.f90)
and further
add_executable(prog2 ${SOURCES})
when compiling with CMake I get the following error:
##
CMake Error at CMakeLists.txt:35 (add_executable):
Cannot find source file:
../../prog1/Src/file1.f90
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx
###
It seems that CMake cna not deal with relative path when declaring the
sources for a project. I tried using the option CMAKE_USE_RELATIVE_PATHS
but it might not be defined for that purpose as it did not solve the
problem. Would you have any idea how to solve that problem ?
thanks a lot
Eric
--
*martin kupke*
can diagnostics engineer | senior software developer
*m*:+49.151.5511.3632| *e*:martin.ku...@novero.com
mailto:martin.ku...@novero.com
skype:martin.kupke_novero | w:www.novero.com http://www.novero.com
novero GmbH
meesmannstr.103 | 44807 Bochum | germany
novero gmbh | parsevalstr. 7 a | 40468 düsseldorf | germany |
amtsgericht düsseldorf | hrb 58283 | umsatzsteueridentifikationsnummer:
de 814973142 | geschäftsführender gesellschafter: razvan olosu
--
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] multiple source directories
Hi all,
I have a project with the following structure:
root/
CMakeLists.txt
prog1/
CMakeLists.txt
Src/
file1.f90
prog2/
CMakeLists.txt
Src/
file2.f90
where prog1, prog2 are individual projects.
I would like to add file1.90 to the build process of prog2. To do so, in
the CMakeLists.txt file of prog2 project, I put:
set(SOURCES ../../prog1/Src/file1.f90
Try ${CMAKE_CURRENT_SOURCE_DIR}/../../prog1/Src/file1.f90 here.
Src/file2.f90)
and further
add_executable(prog2 ${SOURCES})
Then it should work.
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] How to use add_custom_command correctly
On 27.09.11 18:24, Michael Wild wrote:
On 09/27/2011 05:59 PM, Martin Kupke wrote:
Hi,
in my project there is a subfolder which SHALL contain sources to
generate a library. The problem is that at startup of the project there
are no source files existing, because they will be generated by a code
generator. This means within the build process the code generator needs
to be called first, then generates the output files in the subfolder
and
then a library shall be generated from that source files (this are
standard .c and .h files). If I start the code generator by hand to
generate the source files and remove the custom command, then the
compilation is successful, but I want the code generator to be started
every time the configuration file for the code generator has changed.
In my sample below
* the driver.c would be one of the files which the code generator would
generate
* the variable CodeGen is the executable tool (the code generator
himself)
* the variable CodeGenParam contains the parameters which are passed to
be able to generate without any user interaction
* the variable CodeGenConfig is the input file for the code generator
This subfolder contains its own CMakeLists.txt with the following
settings:
# snip #
project(CANstack C)
add_custom_command( OUTPUT driver.c
COMMAND ${CodeGen}
${CodeGenParam}
DEPENDS ${CodeGenConfig} )
)
file(GLOB CANstack_srcs *.c)
file(GLOB CANstack_hdrs *.h)
set(lib_name CANstack)
add_library(${lib_name} STATIC ${CANstack_srcs} ${CANstack_hdrs})
# snap #
I don't get it work that the custom command is called and the source
files from the code generator are produced.
A few issues here:
- Never generate output in the source tree, only in the binary tree.
- Always use absolute paths with add_custom_command().
I use the absolute paths
- Always list *all* outputs after the OUTPUT argument, otherwise CMake
won't know that they are generated sources.
I added the list of *all* files which shall be generated
- Never use file(GLOB ...). It is evil. And breaks in your case. Just
don't.
I don't use the file(GLOB ...) anymore in this CMakeLists.txt
Michael
In case the generated output files already exist and the dependency file
${CodeGenConfig} has been touched, then the output will be generated.
Typically there is from beginning of the project no source file
existing, because the generator needs to be run first. If the output
files are not existing, then I get an error message from CMake:
# snip #
CMake Error at Generated/CarIF_Appl/CANstack/CMakeLists.txt:31
(add_library):
Cannot find source file:
D:/project/Discovery/Generated/Driver/uart.c
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp
.hxx .in .txx
# snap #
How do I have to instruct CMake to run the code generator first, so that
the library can be build of that sources?
Can you paste the relevant snippet from your new CMakeLists.txt?
You can try this first and see if it helps:
add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/driver.c
COMMAND ${CodeGen} {CodeGenParam}
DEPENDS ${CodeGenConfig} )
add_executable(myexe ${CMAKE_CURRENT_BINARY_DIR}/driver.c)
Of course you must tell the CodeGen where to put the result, preferably by
passing ${CMAKE_CURRENT_BINARY_DIR}/driver.c as argument (with the
quotes, to make paths with spaces work right). If the generator can't
handle this you can try to set WORKING_DIRECTORY to
${CMAKE_CURRENT_BINARY_DIR}, passing all other file arguments with
absolute paths then.
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] multiple source directories
On 28.09.11 12:51:53, pellegrini wrote:
Hi all,
I have a project with the following structure:
root/
CMakeLists.txt
prog1/
CMakeLists.txt
Src/
file1.f90
prog2/
CMakeLists.txt
Src/
file2.f90
where prog1, prog2 are individual projects.
I would like to add file1.90 to the build process of prog2. To do
so, in the CMakeLists.txt file of prog2 project, I put:
set(SOURCES ../../prog1/Src/file1.f90
Src/file2.f90)
and further
add_executable(prog2 ${SOURCES})
when compiling with CMake I get the following error:
##
CMake Error at CMakeLists.txt:35 (add_executable):
Cannot find source file:
../../prog1/Src/file1.f90
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx
###
It seems that CMake cna not deal with relative path when declaring
the sources for a project.
Relative paths work just fine, but your expecting a different base-path
than cmake is. In the above example the current directory when
assembling the sources is root/prog2 not root/prog2/Src which you seem
to assume. Hence you have one .. too much in your set-line. This
should work:
set( SOURCES ../prog1/Src/file1.f90 Src/file2.f90 )
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
Re: [CMake] How to use add_custom_command correctly
Now it seems to be solved, the generator is called and the generated
sources / headers are then compiled and linked into a library.
My changes are in the
D:/project/Discovery/Generated/Driver/CMakeLists.txt
just adding a add_custom_target( MyGeneratedSources ALL DEPENDS
${all_generated_srcs} ${all_generated_hdrs} )
Additionally I added in the root CMakeLists.txt
add_dependencies( ${MY_PROJECT} MyGeneratedSources )
This works fine.
On 28.09.11 13:34, Rolf Eike Beer wrote:
On 27.09.11 18:24, Michael Wild wrote:
On 09/27/2011 05:59 PM, Martin Kupke wrote:
Hi,
in my project there is a subfolder which SHALL contain sources to
generate a library. The problem is that at startup of the project there
are no source files existing, because they will be generated by a code
generator. This means within the build process the code generator needs
to be called first, then generates the output files in the subfolder
and
then a library shall be generated from that source files (this are
standard .c and .h files). If I start the code generator by hand to
generate the source files and remove the custom command, then the
compilation is successful, but I want the code generator to be started
every time the configuration file for the code generator has changed.
In my sample below
* the driver.c would be one of the files which the code generator would
generate
* the variable CodeGen is the executable tool (the code generator
himself)
* the variable CodeGenParam contains the parameters which are passed to
be able to generate without any user interaction
* the variable CodeGenConfig is the input file for the code generator
This subfolder contains its own CMakeLists.txt with the following
settings:
# snip #
project(CANstack C)
add_custom_command( OUTPUT driver.c
COMMAND ${CodeGen}
${CodeGenParam}
DEPENDS ${CodeGenConfig} )
)
file(GLOB CANstack_srcs *.c)
file(GLOB CANstack_hdrs *.h)
set(lib_name CANstack)
add_library(${lib_name} STATIC ${CANstack_srcs} ${CANstack_hdrs})
# snap #
I don't get it work that the custom command is called and the source
files from the code generator are produced.
A few issues here:
- Never generate output in the source tree, only in the binary tree.
- Always use absolute paths with add_custom_command().
I use the absolute paths
- Always list *all* outputs after the OUTPUT argument, otherwise CMake
won't know that they are generated sources.
I added the list of *all* files which shall be generated
- Never use file(GLOB ...). It is evil. And breaks in your case. Just
don't.
I don't use the file(GLOB ...) anymore in this CMakeLists.txt
Michael
In case the generated output files already exist and the dependency file
${CodeGenConfig} has been touched, then the output will be generated.
Typically there is from beginning of the project no source file
existing, because the generator needs to be run first. If the output
files are not existing, then I get an error message from CMake:
# snip #
CMake Error at Generated/CarIF_Appl/CANstack/CMakeLists.txt:31
(add_library):
Cannot find source file:
D:/project/Discovery/Generated/Driver/uart.c
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp
.hxx .in .txx
# snap #
How do I have to instruct CMake to run the code generator first, so that
the library can be build of that sources?
Can you paste the relevant snippet from your new CMakeLists.txt?
You can try this first and see if it helps:
add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/driver.c
COMMAND ${CodeGen} {CodeGenParam}
DEPENDS ${CodeGenConfig} )
add_executable(myexe ${CMAKE_CURRENT_BINARY_DIR}/driver.c)
Of course you must tell the CodeGen where to put the result, preferably by
passing ${CMAKE_CURRENT_BINARY_DIR}/driver.c as argument (with the
quotes, to make paths with spaces work right). If the generator can't
handle this you can try to set WORKING_DIRECTORY to
${CMAKE_CURRENT_BINARY_DIR}, passing all other file arguments with
absolute paths then.
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
--
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] multiple source directories - solved
thanks for the hints and your help, guys. Indeed, There was one '..\'
too much in my source files path.
Eric
Andreas Pakulat a écrit :
On 28.09.11 12:51:53, pellegrini wrote:
Hi all,
I have a project with the following structure:
root/
CMakeLists.txt
prog1/
CMakeLists.txt
Src/
file1.f90
prog2/
CMakeLists.txt
Src/
file2.f90
where prog1, prog2 are individual projects.
I would like to add file1.90 to the build process of prog2. To do
so, in the CMakeLists.txt file of prog2 project, I put:
set(SOURCES ../../prog1/Src/file1.f90
Src/file2.f90)
and further
add_executable(prog2 ${SOURCES})
when compiling with CMake I get the following error:
##
CMake Error at CMakeLists.txt:35 (add_executable):
Cannot find source file:
../../prog1/Src/file1.f90
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx
###
It seems that CMake cna not deal with relative path when declaring
the sources for a project.
Relative paths work just fine, but your expecting a different base-path
than cmake is. In the above example the current directory when
assembling the sources is root/prog2 not root/prog2/Src which you seem
to assume. Hence you have one .. too much in your set-line. This
should work:
set( SOURCES ../prog1/Src/file1.f90 Src/file2.f90 )
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
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] overriding ${PROJECTNAME}_BINARY_DIR before call to project()
Hi there,
I have some serious trouble to get a makefile running, comprising of
MITK, VTK, ITK, CTK, Log4Qt, DCMTK, GDCM, etc...
Because most of the makefiles have some imperfections regarding being
built under windows and x64 with the project environment of Visual
Studio 2008, we use direct builds in the main makefile. This also helps
to see all source code of the involved projects. The project
requirements are also set in a way that we cannto use git or downloads,
so the technique called superbuild is not applicable here.
To get the involved projects to be built at the correct place, namely
all created binaries in the CMAKE_BINARY_DIR location of the main
makefile, i try to override e.g. CTK_BINARY_DIR before the inclusion of
the CTK makefile via add_subdirectory.
I have a hard time doing this, even with
SET(CTK_BINARY_DIR ${CMAKE_BINARY_DIR} CACHE INTERNAL FORCE PARENT_SCOPE)
the next call to project(CTK) overrides this and takes some other value.
This value corresponds to the layout of the source tree apparently, but
is of no use in this situation.
How can I influence the value of CTK_BINARY_DIR before the call to the
makefile?
i tried to use project(CTK) in the toplevel makefile one directory up,
but even then the values won't be taken.
so this situation in
mainmakefile:
project(CTK)
set(CTK_BINARY_DIR some other place CACHE INTERNAL FORCE PARENT_SCOPE )
add_subdirectory(CTK)
does not change a thing for CTK. Even when the CTK makefile (naturally)
sets project(CTK), cmake does not complain or state something about
double projects, but silently overwrites the CTK_BINARY_DIR with new
values! So it respects the second call to 'project()', which in my
opinion should be either
a) reported as an error
or
b) the first call to project(CTK) should have priority
Can someone help me?
Regards,
Thomas
--
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] overriding ${PROJECTNAME}_BINARY_DIR before call to project()
Hi Thomas,
You will find below few points that should help you to address your issues:
1) CTK build system can be build with the option CTK_SUPERBUILD set to OFF,
in that case the project will be built as a regular cmake project.
2) You could also build CTK normally (default option) providing VTK_DIR,
Log4Qt_DIR etc ... the CTK build system will understand these dependencies
are available and no project will be downloaded. This is somehow equivalent
to build CTK with CTK_SUPERBUILB OFF
3) If you want to make sure all binaries and libs are built in a custom
location, make sure you set:
CTK_CMAKE_ARCHIVE_OUTPUT_DIRECTORY
CTK_CMAKE_LIBRARY_OUTPUT_DIRECTORY
CTK_CMAKE_RUNTIME_OUTPUT_DIRECTORY
See https://github.com/commontk/CTK/blob/master/CMakeLists.txt#L91
Would be great if you could send request regarding CTK to
ctk-develop...@commontk.org
More info here: http://www.commontk.org and
http://www.commontk.org/index.php/Getting_Started
Thanks
Jc
On Wed, Sep 28, 2011 at 11:35 AM, Thomas Wolf thomas.w...@vision.ee.ethz.ch
wrote:
Hi there,
I have some serious trouble to get a makefile running, comprising of MITK,
VTK, ITK, CTK, Log4Qt, DCMTK, GDCM, etc...
Because most of the makefiles have some imperfections regarding being built
under windows and x64 with the project environment of Visual Studio 2008, we
use direct builds in the main makefile. This also helps to see all source
code of the involved projects. The project requirements are also set in a
way that we cannto use git or downloads, so the technique called
superbuild is not applicable here.
To get the involved projects to be built at the correct place, namely all
created binaries in the CMAKE_BINARY_DIR location of the main makefile, i
try to override e.g. CTK_BINARY_DIR before the inclusion of the CTK makefile
via add_subdirectory.
I have a hard time doing this, even with
SET(CTK_BINARY_DIR ${CMAKE_BINARY_DIR} CACHE INTERNAL FORCE
PARENT_SCOPE)
the next call to project(CTK) overrides this and takes some other value.
This value corresponds to the layout of the source tree apparently, but is
of no use in this situation.
How can I influence the value of CTK_BINARY_DIR before the call to the
makefile?
i tried to use project(CTK) in the toplevel makefile one directory up, but
even then the values won't be taken.
so this situation in
mainmakefile:
project(CTK)
set(CTK_BINARY_DIR some other place CACHE INTERNAL FORCE PARENT_SCOPE
)
add_subdirectory(CTK)
does not change a thing for CTK. Even when the CTK makefile (naturally)
sets project(CTK), cmake does not complain or state something about double
projects, but silently overwrites the CTK_BINARY_DIR with new values! So it
respects the second call to 'project()', which in my opinion should be
either
a) reported as an error
or
b) the first call to project(CTK) should have priority
Can someone help me?
Regards,
Thomas
--
Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/**
opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake
--
+1 919 869 8849
--
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] overriding ${PROJECTNAME}_BINARY_DIR before call to project()
On 28.09.2011 17:58, Jean-Christophe Fillion-Robin wrote:
Hi Thomas,
You will find below few points that should help you to address your issues:
1) CTK build system can be build with the option CTK_SUPERBUILD set to
OFF, in that case the project will be built as a regular cmake project.
2) You could also build CTK normally (default option) providing VTK_DIR,
Log4Qt_DIR etc ... the CTK build system will understand these
dependencies are available and no project will be downloaded. This is
somehow equivalent to build CTK with CTK_SUPERBUILB OFF
3) If you want to make sure all binaries and libs are built in a custom
location, make sure you set:
CTK_CMAKE_ARCHIVE_OUTPUT_DIRECTORY
CTK_CMAKE_LIBRARY_OUTPUT_DIRECTORY
CTK_CMAKE_RUNTIME_OUTPUT_DIRECTORY
Seehttps://github.com/commontk/CTK/blob/master/CMakeLists.txt#L91
Would be great if you could send request regarding CTK to
ctk-develop...@commontk.org mailto:ctk-develop...@commontk.org
More info here: http://www.commontk.org and
http://www.commontk.org/index.php/Getting_Started
Thanks
Jc
Hello Jean-Christophe,
thanks for your reply. Actually, i took CTK just as an example for the
problem, but i will also try what you suggested.
CTK_SUPERBUILD is already off.
Anyway I wonder why ${PROJ}_BINARY_DIR is not settable for me.
Regards,
Thomas
PS.: i posted also something on ctk-developers, but the posting didn't
appear.
--
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] overriding ${PROJECTNAME}_BINARY_DIR before call to project()
On 09/28/2011 06:36 PM, Thomas Wolf wrote:
On 28.09.2011 17:58, Jean-Christophe Fillion-Robin wrote:
Hi Thomas,
You will find below few points that should help you to address your issues:
1) CTK build system can be build with the option CTK_SUPERBUILD set to
OFF, in that case the project will be built as a regular cmake project.
2) You could also build CTK normally (default option) providing VTK_DIR,
Log4Qt_DIR etc ... the CTK build system will understand these
dependencies are available and no project will be downloaded. This is
somehow equivalent to build CTK with CTK_SUPERBUILB OFF
3) If you want to make sure all binaries and libs are built in a custom
location, make sure you set:
CTK_CMAKE_ARCHIVE_OUTPUT_DIRECTORY
CTK_CMAKE_LIBRARY_OUTPUT_DIRECTORY
CTK_CMAKE_RUNTIME_OUTPUT_DIRECTORY
Seehttps://github.com/commontk/CTK/blob/master/CMakeLists.txt#L91
Would be great if you could send request regarding CTK to
ctk-develop...@commontk.org mailto:ctk-develop...@commontk.org
More info here: http://www.commontk.org and
http://www.commontk.org/index.php/Getting_Started
Thanks
Jc
Hello Jean-Christophe,
thanks for your reply. Actually, i took CTK just as an example for the
problem, but i will also try what you suggested.
CTK_SUPERBUILD is already off.
Anyway I wonder why ${PROJ}_BINARY_DIR is not settable for me.
You *can* set a subproject's binary directory by using the binary_dir
parameter of ADD_SUBDIRECTORY(); see the following exemplary project:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BINDIR C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_SUBDIRECTORY(subdir1 ${CMAKE_BINARY_DIR}/bindir)
ADD_SUBDIRECTORY(subdir2)
# subdir1/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(SUBDIR1 C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f1.c void f1(void){}\n)
ADD_LIBRARY(f1 SHARED f1.c)
MESSAGE(${PROJECT_NAME}_BINARY_DIR: ${${PROJECT_NAME}_BINARY_DIR})
# subdir2/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(SUBDIR2 C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f2.c void f2(void){}\n)
ADD_LIBRARY(f2 SHARED f2.c)
MESSAGE(${PROJECT_NAME}_BINARY_DIR: ${${PROJECT_NAME}_BINARY_DIR})
As you can see during the configuration, the subproject in subdir1 will
be built in ${CMAKE_BINARY_DIR}/bindir while the essentially identical
subproject in subdir2 will be built in ${CMAKE_BINARY_DIR}/subdir2 as
usual. However, CMake doesn't allow two or more subprojects to share
a common build directory, i.e. you can't say
ADD_SUBDIRECTORY(subdir2 ${CMAKE_BINARY_DIR}/bindir)
too, and with regard to CMakeFiles, Makefile, cmake_install.cmake
etc., this would be anyway a recipe for desaster. Thus, each of your
subprojects must be provided with an individual build directory, and
to collect your targets' binaries in the top-level CMAKE_BINARY_DIR,
you may use the diverse *_OUTPUT_DIRECTORY[_CONFIG] properties and
the corresponding CMAKE_*_OUTPUT_DIRECTORY variables. Alternatively,
you might add a custom target in the top-level CMakeLists.txt file:
ADD_CUSTOM_TARGET(binaries ALL
COMMAND ${CMAKE_COMMAND} -E copy $TARGET_FILE:f1
${CMAKE_BINARY_DIR}
COMMAND ${CMAKE_COMMAND} -E copy $TARGET_FILE:f2
${CMAKE_BINARY_DIR}
COMMENT Copying binaries to ${CMAKE_BINARY_DIR}
)
ADD_DEPENDENCIES(binaries f1 f2)
'hope that helps.
Regards,
Michael
Regards,
Thomas
PS.: i posted also something on ctk-developers, but the posting didn't
appear.
--
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] Does find_library check that a found library does in fact link?
On Wed, Sep 28, 2011 at 2:47 AM, Michael Wild them...@gmail.com wrote: Only if your installation is broken ;-) If the symlink is broken, I consider this to be a user-error. Period. OTOH, CMake /could/ check whether the library is a symlink, and if it is, check that it is valid. Oh, no question the installation is broken. I'd just expect find_library to do whatever minimal validation it can easily do and not return invalid cases it can spot - checking for symlink and whether it's valid would catch one general class of error, and perhaps a quick check to see if the file is a binary or a text file would be another. Not perfect, but such tests should be relatively simple and would improve the utility of find_library. But how do you test whether a library is linkable? Not sure - autoconf has some sort of test that works in at least some cases in their AC_CHECK_LIB macro, but I'm not really clear on what it does. Even if such a test wouldn't catch all cases, mightn't it be useful to fail when available tests do detect a problem? Cheers, CY -- 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] How to use add_custom_command correctly
On 09/28/2011 01:45 PM, Martin Kupke wrote:
Now it seems to be solved, the generator is called and the generated
sources / headers are then compiled and linked into a library.
My changes are in the
D:/project/Discovery/Generated/Driver/CMakeLists.txt
just adding a add_custom_target( MyGeneratedSources ALL DEPENDS
${all_generated_srcs} ${all_generated_hdrs} )
Additionally I added in the root CMakeLists.txt
add_dependencies( ${MY_PROJECT} MyGeneratedSources )
This works fine.
Just two additional remarks:
- For ADD_CUSTOM_COMMAND(OUTPUT ...), it's documented explicitly
that relative paths after the OUTPUT clause will be interpreted
with respect to the current binary directory, so you may leave
out the leading ${CMAKE_CURRENT_BINARY_DIRECTORY} and specify
relative paths here. However, for the DEPENDS clause, there
is no such documentation.
- A custom command's OUTPUTs must be mentioned as other targets'
prerequisites, i.e. as source files in ADD_EXECUTABLE/LIBRARY()
or after the DEPENDS clause of ADD_CUSTOM_TARGET() in the same
CMakeLists.txt file. Otherwise, the rule for the then unused
OUTPUT is dropped, and it will never be generated. Thus, for
generated sources/headers, there should be no need for an
additional custom target as a custom command's anchor.
Regards,
Michael
On 28.09.11 13:34, Rolf Eike Beer wrote:
On 27.09.11 18:24, Michael Wild wrote:
On 09/27/2011 05:59 PM, Martin Kupke wrote:
Hi,
in my project there is a subfolder which SHALL contain sources to
generate a library. The problem is that at startup of the project there
are no source files existing, because they will be generated by a code
generator. This means within the build process the code generator needs
to be called first, then generates the output files in the subfolder
and
then a library shall be generated from that source files (this are
standard .c and .h files). If I start the code generator by hand to
generate the source files and remove the custom command, then the
compilation is successful, but I want the code generator to be started
every time the configuration file for the code generator has changed.
In my sample below
* the driver.c would be one of the files which the code generator would
generate
* the variable CodeGen is the executable tool (the code generator
himself)
* the variable CodeGenParam contains the parameters which are passed to
be able to generate without any user interaction
* the variable CodeGenConfig is the input file for the code generator
This subfolder contains its own CMakeLists.txt with the following
settings:
# snip #
project(CANstack C)
add_custom_command( OUTPUT driver.c
COMMAND ${CodeGen}
${CodeGenParam}
DEPENDS ${CodeGenConfig} )
)
file(GLOB CANstack_srcs *.c)
file(GLOB CANstack_hdrs *.h)
set(lib_name CANstack)
add_library(${lib_name} STATIC ${CANstack_srcs} ${CANstack_hdrs})
# snap #
I don't get it work that the custom command is called and the source
files from the code generator are produced.
A few issues here:
- Never generate output in the source tree, only in the binary tree.
- Always use absolute paths with add_custom_command().
I use the absolute paths
- Always list *all* outputs after the OUTPUT argument, otherwise CMake
won't know that they are generated sources.
I added the list of *all* files which shall be generated
- Never use file(GLOB ...). It is evil. And breaks in your case. Just
don't.
I don't use the file(GLOB ...) anymore in this CMakeLists.txt
Michael
In case the generated output files already exist and the dependency file
${CodeGenConfig} has been touched, then the output will be generated.
Typically there is from beginning of the project no source file
existing, because the generator needs to be run first. If the output
files are not existing, then I get an error message from CMake:
# snip #
CMake Error at Generated/CarIF_Appl/CANstack/CMakeLists.txt:31
(add_library):
Cannot find source file:
D:/project/Discovery/Generated/Driver/uart.c
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp
.hxx .in .txx
# snap #
How do I have to instruct CMake to run the code generator first, so that
the library can be build of that sources?
Can you paste the relevant snippet from your new CMakeLists.txt?
You can try this first and see if it helps:
add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/driver.c
COMMAND ${CodeGen} {CodeGenParam}
DEPENDS ${CodeGenConfig} )
add_executable(myexe ${CMAKE_CURRENT_BINARY_DIR}/driver.c)
Of course you must tell the CodeGen where to put the result, preferably by
passing ${CMAKE_CURRENT_BINARY_DIR}/driver.c as
Re: [CMake] Does find_library check that a found library does in fact link?
On 09/29/2011 01:30 AM, Clifford Yapp wrote: On Wed, Sep 28, 2011 at 2:47 AM, Michael Wild them...@gmail.com wrote: Only if your installation is broken ;-) If the symlink is broken, I consider this to be a user-error. Period. OTOH, CMake /could/ check whether the library is a symlink, and if it is, check that it is valid. Oh, no question the installation is broken. I'd just expect find_library to do whatever minimal validation it can easily do and not return invalid cases it can spot - checking for symlink and whether it's valid would catch one general class of error, and perhaps a quick check to see if the file is a binary or a text file would be another. Not perfect, but such tests should be relatively simple and would improve the utility of find_library. What do you do on systems which have no idea of symbolic links, e.g. previous Windows versions? Adding more platform-specific code to the sources of the FIND_LIBRARY() function? Furthermore, the kernels of *nix systems hardly distinguish between binary files and text files; usually, they know just files with the limited exception of being able to recognize the native executable formats and the #! shebang. The detection of the diverse file types is typically implemented in utility programs, notably the file(1) utility. But how do you test whether a library is linkable? Not sure - autoconf has some sort of test that works in at least some cases in their AC_CHECK_LIB macro, but I'm not really clear on what it does. Even if such a test wouldn't catch all cases, mightn't it be useful to fail when available tests do detect a problem? What do you do if the library found by FIND_LIBRARY() has a non-native binary format, e.g. for cross-compiling purposes? How do you select the right set of tools to check the library in question without the user's ado? IMO, FIND_LIBRARY()'s job is to find library files, and a general check whether these files are valid/usable/linkable and not dangling symlinks or whatever is beyond the scope of this function; ensuring that is rather the realm of system administration. Cheers, CY 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
Re: [CMake] Fwd: Save stripped debugging information
When I was investigating similar problem, I found alternative approach at
http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.
The thing is to change linker rules, to something like this:
set(CMAKE_C_CREATE_SHARED_LIBRARY
# standard rule
CMAKE_C_COMPILER CMAKE_SHARED_LIBRARY_C_FLAGS
LANGUAGE_COMPILE_FLAGS LINK_FLAGS CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS
CMAKE_SHARED_LIBRARY_SONAME_C_FLAGTARGET_SONAME -o TARGET OBJECTS
LINK_LIBRARIES
# now create a .debug copy
${CMAKE_OBJCOPY} --only-keep-debug TARGET TARGET.debug
# link original to point at .debug copy
# directory components are removed, so ../lib/ is fine
${CMAKE_OBJCOPY} --add-gnu-debuglink=TARGET.debug TARGET
# Strip all information from target binary.
${CMAKE_STRIP} --strip-debug --discard-all --preserve-dates
TARGET
)
I don't exactly remember benefits from this approach but it kind of works.
And I agree that functionality like installing debug symbols in install()
rules out of box would be quite handy.
Regards,
Yuri
On Sat, Sep 24, 2011 at 4:02 AM, Michael Hertling mhertl...@online.dewrote:
On 09/22/2011 01:24 PM, Rolf Eike Beer wrote:
Il 22/09/2011 10.13, Rolf Eike Beer ha scritto:
Yeah, that's exactly what I had in mind. Any chance that we will see
this in a future release?
This is usually find someone who does it and writes tests for it.
Which
then boils down to find someone who has enough knowledge and spare time
to
do or someone that needs it and is willing to pay Kitware for doing it.
Why don't you invoke ${CMAKE_OBJCOPY} as a post build command?
That would be a way to _get_ these debug symbol files, but not a clean
way
to _install_ them. And the other reason is that this variable doesn't
show
up in any CMake documentation.
Eike
In order to take up Andrea's suggestion for Lukas' concern:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(DEBUGINFO C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
FIND_PROGRAM(OBJCOPY objcopy)
ADD_CUSTOM_COMMAND(TARGET main POST_BUILD
COMMAND ${OBJCOPY} --only-keep-debug
$TARGET_FILE:main ${CMAKE_BINARY_DIR}/main.dbg
COMMAND ${OBJCOPY} --strip-debug
$TARGET_FILE:main
COMMAND ${OBJCOPY} --add-gnu-debuglink=main.dbg
$TARGET_FILE:main
)
INSTALL(TARGETS main RUNTIME DESTINATION bin)
INSTALL(FILES ${CMAKE_BINARY_DIR}/main.dbg DESTINATION bin)
This exemplary project simply follows objcopy's manpage
w.r.t. the --only-keep-debug switch and works on *nix.
Does it not work for you, or is it not clean enough?
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
--
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] Does find_library check that a found library does in fact link?
On 09/29/2011 02:52 AM, Michael Hertling wrote: On 09/29/2011 01:30 AM, Clifford Yapp wrote: On Wed, Sep 28, 2011 at 2:47 AM, Michael Wild them...@gmail.com wrote: Only if your installation is broken ;-) If the symlink is broken, I consider this to be a user-error. Period. OTOH, CMake /could/ check whether the library is a symlink, and if it is, check that it is valid. Oh, no question the installation is broken. I'd just expect find_library to do whatever minimal validation it can easily do and not return invalid cases it can spot - checking for symlink and whether it's valid would catch one general class of error, and perhaps a quick check to see if the file is a binary or a text file would be another. Not perfect, but such tests should be relatively simple and would improve the utility of find_library. What do you do on systems which have no idea of symbolic links, e.g. previous Windows versions? Adding more platform-specific code to the sources of the FIND_LIBRARY() function? Furthermore, the kernels of *nix systems hardly distinguish between binary files and text files; usually, they know just files with the limited exception of being able to recognize the native executable formats and the #! shebang. The detection of the diverse file types is typically implemented in utility programs, notably the file(1) utility. And to add to the confusion, GNU ld also accepts linker scripts which are text files, but are named like libraries. E.g. on my Ubuntu 11.04 box /usr/lib/x86_64-linux-gnu/libc.so is actually a linker script. file(1) uses magic numbers and heuristics to detect the file type, and it certainly isn't bulletproof... 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
Re: [CMake] Does find_library check that a found library does in fact link?
On Wed, Sep 28, 2011 at 8:52 PM, Michael Hertling mhertl...@online.dewrote: What do you do on systems which have no idea of symbolic links, e.g. previous Windows versions? Adding more platform-specific code to the sources of the FIND_LIBRARY() function? If the problem isn't solved (or readily solvable) on some platforms, we can just fall back to doing what we do now in those cases... we don't have to solve the problem on all possible platforms to improve the results on platforms that can be supported. The point wouldn't be to *guarantee* the result of find_library is a valid working library (it doesn't do that now), just improve the results by doing what can be done to avoid returning results that can be tagged as non-working (since a build trying to use such results is guaranteed to fail anyway.) Does cmake know (or can it tell) when it is cross compiling? If so, it could decide how much to test and not test in those cases. Furthermore, the kernels of *nix systems hardly distinguish between binary files and text files; usually, they know just files with the limited exception of being able to recognize the native executable formats and the #! shebang. The detection of the diverse file types is typically implemented in utility programs, notably the file(1) utility. A linker test when possible (non-cross-compilation scenarios) with a fallback testing option using file introspection would handle a lot of situations, if I'm understanding correctly how this works. To the best of my knowledge and that of one of our other devs (he knows a lot more than me) there aren't any platforms where actual library files (as opposed to linker scripts) consist solely of character values 128. Checking a found file for at least one character over 128 would avoid at least a few failure cases - empty files, plain text files, and dead links. Such a check would be reliable, consist, and would be useful in eliminating files we might find that are not actually library files. Such a test of course wouldn't pass linker scripts like ubuntu's libc.so, but such a script *would* pass the actual linker test and would never get to file introspection. Actually if the script failed the linker test, then there is a real problem that should be a failure case. This would also be helpful in spotting early on the hypothetical case of a linker being tested that doesn't understand the .so linker script. But how do you test whether a library is linkable? If not cross-compiling, wouldn't it be possible to have find_library try the link as part of its test? Even in the case where linking isn't viable, falling back on the check on file contents would still be helpful. What do you do if the library found by FIND_LIBRARY() has a non-native binary format, e.g. for cross-compiling purposes? How do you select the right set of tools to check the library in question without the user's ado? IMO, FIND_LIBRARY()'s job is to find library files, and a general check whether these files are valid/usable/linkable and not dangling symlinks or whatever is beyond the scope of this function; ensuring that is rather the realm of system administration. I guess the question revolves around the expectation of find_library being different from find_file - as a user, my expectation would be that find_library is doing something to distinguish libraries from files (when that's technically workable, of course - clearly solving that problem in general is hard.) If something tricky like cross-compiling is going on then the simpler testing behavior is in order, but couldn't CMake scrub the results looking for library validity as much as possible? Cheers, CY -- 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-commits] CMake branch, master, updated. v2.8.5-515-g8a3bca5
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 8a3bca50fa55b82f134c8a763bc837f0d5a17afa (commit) from ef8cc9997cab748098bab52caf1ca038f90ec826 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8a3bca50fa55b82f134c8a763bc837f0d5a17afa commit 8a3bca50fa55b82f134c8a763bc837f0d5a17afa Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Sep 29 00:01:06 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Sep 29 00:07:38 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 41709d6..7fbe5f3 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 09) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 28) +SET(KWSYS_DATE_STAMP_DAY 29) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
