[CMake] Can you add sources to a target library after add_library()?
Hi all, I've been searching the manuals, but couldn't find a way to add sources to a target library *after* the add_library() command, e.g., using set_target_properties()? Is this possible at all? Best regards, Marcel Loose. ___ 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] intercomponent link dependencies?
Hi Nico,
I think you should put the knowledge of the intercomponent link
dependencies in your FindXXX script. That way, you don't have to bother
the user of this third-party package with this knowledge.
BTW, if you're on Linux and your package contains shared libraries,
instead of static libraries, then, iff the package was properly built
(i.e. with the dependencies linked into the shared libs) you won't need
to specify these indirect dependencies.
Best regards,
Marcel Loose.
On Thu, 2010-01-07 at 21:20 +0100, Nico Schlömer wrote:
Hi Ryan,
thanks very much for your answer.
For clarification, the package I would like to link against has (say)
three components A, B, C, where A at link time needs symbols of B
needs symbols of C needs symbols of some external libs.
I would like to make sure that the user can say
FIND_PACKAGE( mypackage COMPONENTS A )
and then find in some variable *all* the dependencies that are
required for linking, e.g.,
MYPACKAGE_A_LIBRARY=a;b;c;/usr/local/lib/libblas.a.
Right now (and which I'm not happy with), if a user would like to link
against liba.a, he or she has to know that libb.a, libc.a, and
/usr/local/lib/libblas.a have to be pulled in as well, and do so
manually.
If on the other hand I have the same dependency situation with
libraries that I *built*, the TARGET_LINK_LIBRARIES mechanism works
very well. If I understand correctly, this cannot be applied to
components in a FINDmypackage.cmake
Cheers,
Nico
On Thu, Jan 7, 2010 at 8:43 PM, Ryan Pavlik rpav...@iastate.edu wrote:
Hello,
My apologies in advance if I'm completely mis-reading your question and if
this answer seems way off base: just addressing what seemed like the most
likely issue from the info you provided. (This link below [1] might help
you get better results out of mailing lists.)
A script called by find_package(whatever) only normally sets variables in
CMake - it doesn't include or link any targets against any libraries. (You
might have several targets in one CMake project, each that link against
different libraries) So, in addition to the find_package(Mypackage), in
your CMakeLists.txt, you'll also want to do, for example:
include_directories(${MYPACKAGE_INCLUDE_DIRS})
add_executable(myapp ${MYAPP_SOURCES})
target_link_libraries(myapp ${MYPACKAGE_FOOCOMP_LIBRARY}
${MYPACKAGE_BARCOMP_LIBRARY})
Note that according to the readme.txt in the modules directory of cmake (and
what seems to be convention), you'll note that your find module variables
should probably be named as above ( PACKAGEUPPER_COMPONENTUPPER_LIBRARY ).
Additionally, once you've run find_package_handle_standard_args,
if(PACKAGEUPPER_FOUND), you will probably want to do the following - this
example assumes you have some main library for the package that's always
needed to link against that package, and some additional optional libraries
specified as components (openscenegraph is an example of one of these types
of packages)
set(PACKAGEUPPER_LIBRARIES ${PACKAGEUPPER_LIBRARY})
foreach(COMPONENT ${list_of_requested_and_found_components})
list(APPEND PACKAGEUPPER_LIBRARIES ${PACKAGEUPPER_COMPONENT_LIBRARY})
endforeach()
I've attached a rather simple example of this kind of script - you'd of
course have your component search loop and the additional foreach loop
explained above added to this basic structure. (and if you're doing it by
creating imported targets, you'll obviously use that code instead of the
direct file path code)
Hope this helps!
Ryan
[1] http://catb.org/~esr/faqs/smart-questions.html
On 01/07/2010 09:19 AM, Nico Schlömer wrote:
Hi Michael,
I added to the FindMypackage.cmake in the FOREACH(COMPONENT) loop the
following snipped
ADD_LIBRARY(${COMPONENT} STATIC IMPORTED)
SET_TARGET_PROPERTIES( ${COMPONENT} PROPERTIES
IMPORTED_LOCATION
${${UPPERCOMPONENT}_LIBRARY}
LINK_INTERFACE_LIBRARIES
${${COMPONENT}_LINK_INTERFACE_LIBRARIES}
)
where ${${UPPERCOMPONENT}_LIBRARY} is the path of the respective
library in the filesystem, and
${${COMPONENT}_LINK_INTERFACE_LIBRARIES} a semicolon-separated list
of dependencies of ${COMPONENT} (being either another component, or
something of the form /path/to/libfancy.a). CMake does create all the
Makefiles -- good -- but the dependency information doesn't sit in
there (?).
I expected that I can go like
FIND_PACKAGE( Mypackage COMPONENTS foocomp barcomp )
and that all the necessary stuff would be included automatically. --
Well, now that I think about it this is probably a pipe dream. What
would I further have to include?
Cheers,
Nico
On Thu, Jan 7, 2010 at 12:47 PM, Michael Wildthem...@gmail.com wrote:
Hi Nico
In that case you need to do this:
add_library(${COMPONENT} IMPORTED
Re: [CMake] Overriding CMAKE_C_FLAGS on a per-directory basis
Hi Ingolf, If you've set the flags -foo -bar using add_definitions(), instead of manipulating CMAKE_C_FLAGS directly, you can use set_directory_properties(PROPERTIES COMPILE_DEFINITIONS -baz) to override the compile definitions for the current directory and its subdirectories. Hope this helps, Marcel Loose. On Fri, 2010-01-08 at 12:26 +0100, Ingolf Steinbach wrote: Hi, is it possible to override CMAKE_C_FLAGS on a per-directory basis? I have attempted to solve this by setting CMAKE_C_FLAGS to a different value than the default used in the project, but this modification is not reflected in the command line for compilation within the directory. Example global CMAKE_C_FLAGS are -foo -bar some_dir/CMakeLists.txt: [...] set(CMAKE_C_FLAGS -argl) [...] Still sources in some_dir are compiled with -foo -bar rather than with -argl. Also setting the COMPILE_FLAGS property via set_source_files_properties() applied to the sources in some_dir would only *append* the new flags to -foo -bar rather than replacing them. cmake 2.8 on Linux. Kind regards Ingolf ___ 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] [Q] LINK_INTERFACE_LIBRARIES and the like
On Tue, 2009-12-22 at 16:22 +0100, Michael Wild wrote:
On 22. Dec, 2009, at 15:52 , Marcel Loose wrote:
Hi all,
After reading, re-reading, and re-re-reading the manual, I still don't
really get the concept of LINK_INTERFACE_LIBRARIES,
IMPORTED_LINK_DEPENDENT_LIBRARIES, and
IMPORTED_LINK_INTERFACE_LIBRARIES. Is this mostly Windows-specific, or
does it also apply for Linux?
Best regards,
Marcel Loose.
LINK_INTERFACE_LIBRARIES is a property you can set if you want to override
the set of libraries that appear in the link-interface of one of your own
libraries.
IMPORTED_LINK_INTERFACE_LIBRARIES is the same for IMPORTED targets. E.g.
suppose you have this:
add_library(foo ${FOO_SRCS})
target_link_libraries(foo bar)
install(EXPORT ${PROJECT_NAME}Dependencies DESTINATION somewhere)
The created somewhere/${PROJECT_NAME}Dependencies.cmake file will list
bar in the LINK_INTERFACE_LIBRARIES of foo. This property is essentially
a copy of LINK_INTERFACE_LIBRARIES property of foo in the build tree (if it
is defined).
IMPORTED_LINK_DEPENDENT_LIBRARIES is AFAIK similar to
IMPORTED_LINK_INTERFACE_LIBRARIES but refers to dependencies that are
implementation details.
HTH
Michael
Hi Michael,
That clarifies things a bit. Maybe I'm just not familiar enough with
import/export of libraries. Could I compare this
somewhere/${PROJECT_NAME}Dependencies.cmake file with the package.pc
file that is generated by pkg-config as a means to record compile and
link flags?
Another question: is it common good practice for a CMake-project to
export its public libraries using install(EXPORT...), or would you do
that on a case-to-case basis?
Would there be a use case for LINK_INTERFACE_LIBRARIES within one
project, to relate several libraries within that project?
Best regards,
Marcel Loose.
___
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] [Q] LINK_INTERFACE_LIBRARIES and the like
On Wed, 2009-12-23 at 09:59 +0100, Michael Wild wrote:
On 23. Dec, 2009, at 9:52 , Marcel Loose wrote:
On Tue, 2009-12-22 at 16:22 +0100, Michael Wild wrote:
On 22. Dec, 2009, at 15:52 , Marcel Loose wrote:
Hi all,
After reading, re-reading, and re-re-reading the manual, I still don't
really get the concept of LINK_INTERFACE_LIBRARIES,
IMPORTED_LINK_DEPENDENT_LIBRARIES, and
IMPORTED_LINK_INTERFACE_LIBRARIES. Is this mostly Windows-specific, or
does it also apply for Linux?
Best regards,
Marcel Loose.
LINK_INTERFACE_LIBRARIES is a property you can set if you want to override
the set of libraries that appear in the link-interface of one of your own
libraries.
IMPORTED_LINK_INTERFACE_LIBRARIES is the same for IMPORTED targets. E.g.
suppose you have this:
add_library(foo ${FOO_SRCS})
target_link_libraries(foo bar)
install(EXPORT ${PROJECT_NAME}Dependencies DESTINATION somewhere)
The created somewhere/${PROJECT_NAME}Dependencies.cmake file will list
bar in the LINK_INTERFACE_LIBRARIES of foo. This property is
essentially a copy of LINK_INTERFACE_LIBRARIES property of foo in the
build tree (if it is defined).
IMPORTED_LINK_DEPENDENT_LIBRARIES is AFAIK similar to
IMPORTED_LINK_INTERFACE_LIBRARIES but refers to dependencies that are
implementation details.
HTH
Michael
Hi Michael,
That clarifies things a bit. Maybe I'm just not familiar enough with
import/export of libraries. Could I compare this
somewhere/${PROJECT_NAME}Dependencies.cmake file with the package.pc
file that is generated by pkg-config as a means to record compile and
link flags?
It is similar in that it creates IMPORTED targets and defines the
dependencies of them.
Another question: is it common good practice for a CMake-project to
export its public libraries using install(EXPORT...), or would you do
that on a case-to-case basis?
Mostly this is useful if you need people to link with their own project
against your installed libraries (think boost, VTK and similar). If you
create an application, this isn't that useful, except if that application has
a plugin-interface and you want people to be able to create plugins for the
installed application.
Would there be a use case for LINK_INTERFACE_LIBRARIES within one
project, to relate several libraries within that project?
I use it in my project to prevent static third-party libraries that I build
within my project to show up in the IMPORTED_LINK_INTERFACE_LIBRARIES of the
{PROJECT_NAME}Dependencies.cmake file. This requires however that I wrap the
TARGET_LINK_LIBRARIES command in a custom function which does all the dirty
work.
Best regards,
Marcel Loose.
Michael
OK, thanks for the explanation, Michael.
Seems I won't be needing this stuff in the near future, but I'll keep it
in the back of my head.
Best regards,
Marcel Loose.
___
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] Proposal: extra option PRIVATE for target_link_libraries
Hi all, I suggested this in the quite long thread third party library dependencies, but it may have been overlooked. Hence, I started a new thread. Upon (re)reading the Mandriva page http://wiki.mandriva.com/en/Overlinking, I was thinking: maybe the issue of overlinking can be solved more or less the same way as pkg-config does: i.e. by defining private dependencies. This could be an extra option to target_link_libraries. Something like: target_link_libraries(mylib public1 public2 PRIVATE private1 private2) This would tell CMake that mylib directly depends on public1 and public2 and should only link in these two libraries when these are shared object libraries; otherwise private1 and private2 would also need to be added on the link line. The big hurdle to take, of course, is to detect in a platform-independent way whether the given library is shared or static. However, a lot of this knowledge is already available in the diverse Modules/Platform macros, so my feeling is that this should be feasible. Best regards, Marcel Loose. ___ 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] Proposal: extra option PRIVATE for target_link_libraries
On Wed, 2009-12-23 at 13:09 +0100, Michael Wild wrote:
On 23. Dec, 2009, at 12:08 , Marcel Loose wrote:
Hi all,
I suggested this in the quite long thread third party library
dependencies, but it may have been overlooked. Hence, I started a new
thread.
Upon (re)reading the Mandriva page
http://wiki.mandriva.com/en/Overlinking, I was thinking: maybe the issue
of overlinking can be solved more or less the same way as pkg-config
does: i.e. by defining private dependencies. This could be an extra
option to target_link_libraries.
Something like:
target_link_libraries(mylib public1 public2 PRIVATE private1 private2)
This would tell CMake that mylib directly depends on public1 and public2
and should only link in these two libraries when these are shared
object libraries; otherwise private1 and private2 would also need to be
added on the link line.
The big hurdle to take, of course, is to detect in a
platform-independent way whether the given library is shared or static.
However, a lot of this knowledge is already available in the diverse
Modules/Platform macros, so my feeling is that this should be feasible.
Best regards,
Marcel Loose.
You would also need a PUBLIC keyword, and then require that all FindXXX.cmake
modules prefix their libraries with PUBLIC and PRIVATE. If only the PRIVATE
libraries where prefixed, the following would not work if A_LIBRARIES
contains PRIVATE:
find_package(A)
find_package(B)
add_library(C source.c)
target_link_libraries(C ${A_LIBRARIES} ${B_LIBRARIES})
Because then all the B_LIBRARIES would be considered to be private details
of the public A_LIBRARIES... Also, there's no way to tell CMake which of the
private libraries belongs to which of the public libraries.
I think it would be better if a FindXXX.cmake module marked the private
libraries as a property of the public libraries and then let CMake take it
from there (although as of now I wouldn't know on what to set the property,
except if the module created an IMPORTED target for each of the public
libraries, but that bears the possibility of target name collisions with the
importing project).
Michael
Hi Michael,
I don't think you'll need to prefix the library names with either
PRIVATE_ or PUBLIC_. CMake could figure out whether public1 and
public2 are shared or static libraries. If they are shared libraries,
then the libraries marked as private (private1 and private2) do not
have to be linked in as well. Otherwise they must also be linked in. I
assume that CMake keeps a list internally, of all dependent targets; the
private libs should only be added to that internal list if the public
libs are static libs.
I don't completely understand your example. Are you suggesting that
you'll run into trouble if you have a library named PRIVATE? I think
name clashes will currently occur as well if I name my library debug,
optimized, or general.
Maybe, it would be better if the FindXXX modules would handle this. On
the other hand, you then depend on third parties to properly update
their FindXXX modules, or have to rewrite them yourselves :-(
Best regards,
Marcel Loose.
___
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] Proposal: extra option PRIVATE for target_link_libraries
On Wed, 2009-12-23 at 14:36 +0100, Alexander Neundorf wrote: On Wednesday 23 December 2009, Marcel Loose wrote: Hi all, I suggested this in the quite long thread third party library dependencies, but it may have been overlooked. Hence, I started a new thread. Upon (re)reading the Mandriva page http://wiki.mandriva.com/en/Overlinking, I was thinking: maybe the issue of overlinking can be solved more or less the same way as pkg-config does: i.e. by defining private dependencies. This could be an extra option to target_link_libraries. Something like: target_link_libraries(mylib public1 public2 PRIVATE private1 private2) Assuming that public1 and public2 are libraries also built with cmake, that can be done already today: add_library(public1 ...) target_link_libraries(public1 private1) target_link_libraries(public1 LINK_INTERFACE_LIBRARIES ) add_library(public2 ...) target_link_libraries(public2 private2) target_link_libraries(public2 LINK_INTERFACE_LIBRARIES ) install(TARGETS public1 public2 ... EXPORT MyPublicLibs) install(EXPORT ...) Then later on, when loading these exported targets, you will get what you want. If public1/2 are shared libs, their link interface will be empty. If they are static, you will link against everything they have been linked against, independent of the LINK_INTERFACE_LIBRARIES (which is used only for shared libs). Alex Hi Alex, Seems I must unconciously have felt that LINK_INTERFACE_LIBRARIES had something to do with the problem of overlinking I'm trying to solve right now. Funny, this morning I came to the conclusion that I probably wouldn't need LINK_INTERFACE_LIBRARIES (see thread: [Q] LINK_INTERFACE_LIBRARIES and the like), and now it seems I will. Guess I'll have to study carefully how this whole import/export and interface libs stuff works. Could you point me to some examples? Best regards, Marcel Loose. ___ 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] Proposal: extra option PRIVATE for target_link_libraries
On Wed, 2009-12-23 at 14:12 +0100, Michael Wild wrote:
On 23. Dec, 2009, at 13:28 , Marcel Loose wrote:
On Wed, 2009-12-23 at 13:09 +0100, Michael Wild wrote:
On 23. Dec, 2009, at 12:08 , Marcel Loose wrote:
Hi all,
I suggested this in the quite long thread third party library
dependencies, but it may have been overlooked. Hence, I started a new
thread.
Upon (re)reading the Mandriva page
http://wiki.mandriva.com/en/Overlinking, I was thinking: maybe the issue
of overlinking can be solved more or less the same way as pkg-config
does: i.e. by defining private dependencies. This could be an extra
option to target_link_libraries.
Something like:
target_link_libraries(mylib public1 public2 PRIVATE private1 private2)
This would tell CMake that mylib directly depends on public1 and public2
and should only link in these two libraries when these are shared
object libraries; otherwise private1 and private2 would also need to be
added on the link line.
The big hurdle to take, of course, is to detect in a
platform-independent way whether the given library is shared or static.
However, a lot of this knowledge is already available in the diverse
Modules/Platform macros, so my feeling is that this should be feasible.
Best regards,
Marcel Loose.
You would also need a PUBLIC keyword, and then require that all
FindXXX.cmake modules prefix their libraries with PUBLIC and PRIVATE. If
only the PRIVATE libraries where prefixed, the following would not work if
A_LIBRARIES contains PRIVATE:
find_package(A)
find_package(B)
add_library(C source.c)
target_link_libraries(C ${A_LIBRARIES} ${B_LIBRARIES})
Because then all the B_LIBRARIES would be considered to be private
details of the public A_LIBRARIES... Also, there's no way to tell CMake
which of the private libraries belongs to which of the public libraries.
I think it would be better if a FindXXX.cmake module marked the private
libraries as a property of the public libraries and then let CMake take it
from there (although as of now I wouldn't know on what to set the
property, except if the module created an IMPORTED target for each of the
public libraries, but that bears the possibility of target name collisions
with the importing project).
Michael
Hi Michael,
I don't think you'll need to prefix the library names with either
PRIVATE_ or PUBLIC_. CMake could figure out whether public1 and
public2 are shared or static libraries. If they are shared libraries,
then the libraries marked as private (private1 and private2) do not
have to be linked in as well. Otherwise they must also be linked in. I
assume that CMake keeps a list internally, of all dependent targets; the
private libs should only be added to that internal list if the public
libs are static libs.
I don't completely understand your example. Are you suggesting that
you'll run into trouble if you have a library named PRIVATE? I think
name clashes will currently occur as well if I name my library debug,
optimized, or general.
Maybe, it would be better if the FindXXX modules would handle this. On
the other hand, you then depend on third parties to properly update
their FindXXX modules, or have to rewrite them yourselves :-(
Best regards,
Marcel Loose.
No, it won't work. For example, if FindA.cmake does
set(A_LIBRARIES /some/path/libA.so
PRIVATE /some/other/path/libX.a /some/other/path/libY.a)
and FindB.cmake contains
# notice that this is a static library!
set(B_LIBRARIES /some/path/libB.a)
then the call
target_link_libraries(C ${A_LIBRARIES} ${B_LIBRARIES})
expands to (wrapped for legibility
target_link_libraries(C
/some/path/libA.so
PRIVATE /some/other/path/libX.a
/some/other/path/libY.a
/some/path/libB.a)
which is different in meaning from
target_link_libraries(C ${B_LIBRARIES} ${A_LIBRARIES})
which becomes
target_link_libraries(C
/some/path/libB.a
/some/path/libA.so
PRIVATE
/some/other/path/libX.a
/some/other/path/libY.a)
In the first case libB.a becomes marked as PRIVATE of libA.so! Not very nice
if you ask me ;-)
Michael
Hi Michael,
I never suggested that A_LIBRARIES should be set to contain PRIVATE. I
suggested to add a keyword PRIVATE to the target_link_libraries
command.
Of course, if you want to abuse CMake, it's always possible. For
example, the following CMakeLists.txt file will not be processed by
CMake, because I decided in my eternal wisdom (sic) to name one of my
libraries optimized. My OS doesn't bother that I use that names; it's
just a limitation of CMake.
cmake_minimum_required(VERSION 2.6)
project(Dummy)
add_library(debug debug.cc)
add_library(optimized optimized.cc)
target_link_libraries(debug optimized)
CMake Error at CMakeLists.txt:5 (target_link_libraries):
The optimized
Re: [CMake] Proposal: extra option PRIVATE for target_link_libraries
On Wed, 2009-12-23 at 15:06 +0100, Alexander Neundorf wrote: On Wednesday 23 December 2009, Marcel Loose wrote: ... Seems I must unconciously have felt that LINK_INTERFACE_LIBRARIES had something to do with the problem of overlinking I'm trying to solve right now. Funny, this morning I came to the conclusion that I probably wouldn't need LINK_INTERFACE_LIBRARIES (see thread: [Q] LINK_INTERFACE_LIBRARIES and the like), and now it seems I will. Guess I'll have to study carefully how this whole import/export and interface libs stuff works. Could you point me to some examples? It's probably also somewhere in the cmake wiki, but does this help ? http://techbase.kde.org/Development/CMake_KDE_4_2#How_to_install_libraries_correctly_now Alex Thanks Alex, I think I start the grasp the concepts now. It's just like skating; slowly making progress ;-) Best regards, Marcel Loose. ___ 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] [Q] LINK_INTERFACE_LIBRARIES and the like
Hi all, After reading, re-reading, and re-re-reading the manual, I still don't really get the concept of LINK_INTERFACE_LIBRARIES, IMPORTED_LINK_DEPENDENT_LIBRARIES, and IMPORTED_LINK_INTERFACE_LIBRARIES. Is this mostly Windows-specific, or does it also apply for Linux? Best regards, Marcel Loose. ___ 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] Tiny FindJNI patch to set JNI_FOUND
Hi all,
Here's a tiny patch for FindJNI, which also sets JNI_FOUND, as dictated
by the CMake Find macros standard.
Best regards,
Marcel Loose.
Index: FindJNI.cmake
===
RCS file: /cvsroot/CMake/CMake/Modules/FindJNI.cmake,v
retrieving revision 1.47
diff -u -r1.47 FindJNI.cmake
--- FindJNI.cmake 2 Nov 2009 09:03:06 - 1.47
+++ FindJNI.cmake 21 Dec 2009 10:46:42 -
@@ -10,6 +10,7 @@
# JAVA_INCLUDE_PATH = the include path to jni.h
# JAVA_INCLUDE_PATH2= the include path to jni_md.h
# JAVA_AWT_INCLUDE_PATH = the include path to jawt.h
+# JNI_FOUND = TRUE if JNI headers and libraries were
found.
#
#=
@@ -225,3 +226,6 @@
${JAVA_AWT_INCLUDE_PATH}
)
+INCLUDE(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(JNI DEFAULT_MSG
+ JNI_LIBRARIES JNI_INCLUDE_DIRS)
___
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 calls to find_package(Boost) with different components
Hi Adolfo,
I think you already answered your question yourself, though maybe you
didn't realize it. Fortunately you wrote the key phrase
... Now if I clear all non-internal Boost_* cache variables ...
The thing is, FindBoost keeps track of the components it has already
found in internal variables named Boost_component_FOUND. So, if you
don't remove these variables from the cache, you're entering the realm
of undefined behaviour.
I don't know if the author(s) of FindBoost are to blame, e.g., for
possible abuse of internal variables; or that you should never do what
you did. I'm more of a command-line person, so I have no experience with
groups in the cmake-gui.
Best regards,
Marcel Loose.
On Mon, 2009-12-21 at 10:37 +0100, Adolfo Rodríguez Tsouroukdissian
wrote:
Hi all,
I have a use case where find_package(Boost COMPONENTS xxx) is called
more than once, and each time with a different set of components, as
in the following example:
cmake_minimum_required(VERSION 2.6)
project(MyBoost)
find_package(Boost REQUIRED COMPONENTS date_time)
message(STATUS 1st call: Boost_LIBRARIES=${Boost_LIBRARIES})
find_package(Boost REQUIRED COMPONENTS regex)
message(STATUS 2nd call: Boost_LIBRARIES=${Boost_LIBRARIES})
Upon configuring the project for the first time, everything works as
expected, and the relevant output I get is:
-- 1st call: Boost_LIBRARIES=/opt/boost/lib/libboost_date_time-mt.so
-- 2nd call:
Boost_LIBRARIES=/opt/boost/lib/libboost_date_time-mt.so;/opt/boost/lib/libboost_regex-mt.so
Now if I clear all non-internal Boost_* cache variables, such as by
removing the Boost group in cmake-gui and reconfigure my project, I
get
-- 1st call: Boost_LIBRARIES=/opt/boost/lib/libboost_date_time-mt.so
-- 2nd call: Boost_LIBRARIES=/opt/boost/lib/libboost_date_time-mt.so
Which is unexpected. Should the above example work for the two
described scenarios, or am I entering some state that yields undefined
behavior?
Thanks in advance,
Adolfo
--
Adolfo Rodríguez Tsouroukdissian, Ph. D.
Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos,
pueden contener información privilegiada y/o confidencial que está
dirigida exclusivamente a su destinatario. Si usted recibe este
mensaje y no es el destinatario indicado, o el empleado encargado de
su entrega a dicha persona, por favor, notifíquelo inmediatamente y
remita el mensaje original a la dirección de correo electrónico
indicada. Cualquier copia, uso o distribución no autorizados de esta
comunicación queda estrictamente prohibida.
CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s)
may contain confidential information which is privileged and intended
only for the individual or entity to whom they are addressed. If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or use of this e-mail and/or
accompanying document(s) is strictly prohibited. If you have received
this e-mail in error, please immediately notify the sender at the
above e-mail address.
___
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] third party library dependencies
On Fri, 2009-12-18 at 08:54 -0800, Jed Brown wrote: On Fri, 18 Dec 2009 10:19:05 +0100, Marcel Loose lo...@astron.nl wrote: Hi Roman, Not in a portable way. I'm not too familiar with Windows, but on Linux you can do this when libA is a shared library that has its dependency on libB linked in (e.g. ldd libA.so will tell you this). When linking in static libraries you're out of luck. With shared libraries, you need not and *should not* explicitly link recursive dependencies. If you have both static and shared libraries, the output of ldd could be used to find the recursive deps needed to link statically. This sucks and the logic to determine whether to put recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is insane. FWIW, pkg-config has Libs.private for this purpose. Finally, it would be nice to easily associate a symbol with a call to find_library. That is, suppose libA links to libB and libC, but libA never exposes libB or libC to users. To do the right thing (without abusing ldd), FindA.cmake needs to try linking with just -lA (which will work with all shared libs), then try with -lA -lB and -lA -lC before falling back to -lA -lB -lC (which is required when all libs are static). A better way which does not have exponential complexity would be to declare that the symbol B_Foo belongs with a libB and C_Bar belongs with a libC. So when linking with -lA fails, libB would be added exactly when B_Foo is undefined. Jed Hi Jed, Why do you consider explicit linking of recursive dependencies a bad thing? It's superfluous, I agree, but there's no harm in it, right? Best regards, Marcel Loose. ___ 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] third party library dependencies
On Mon, 2009-12-21 at 13:32 +0100, Michael Wild wrote: On 21. Dec, 2009, at 12:17 , Marcel Loose wrote: On Fri, 2009-12-18 at 08:54 -0800, Jed Brown wrote: On Fri, 18 Dec 2009 10:19:05 +0100, Marcel Loose lo...@astron.nl wrote: Hi Roman, Not in a portable way. I'm not too familiar with Windows, but on Linux you can do this when libA is a shared library that has its dependency on libB linked in (e.g. ldd libA.so will tell you this). When linking in static libraries you're out of luck. With shared libraries, you need not and *should not* explicitly link recursive dependencies. If you have both static and shared libraries, the output of ldd could be used to find the recursive deps needed to link statically. This sucks and the logic to determine whether to put recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is insane. FWIW, pkg-config has Libs.private for this purpose. Finally, it would be nice to easily associate a symbol with a call to find_library. That is, suppose libA links to libB and libC, but libA never exposes libB or libC to users. To do the right thing (without abusing ldd), FindA.cmake needs to try linking with just -lA (which will work with all shared libs), then try with -lA -lB and -lA -lC before falling back to -lA -lB -lC (which is required when all libs are static). A better way which does not have exponential complexity would be to declare that the symbol B_Foo belongs with a libB and C_Bar belongs with a libC. So when linking with -lA fails, libB would be added exactly when B_Foo is undefined. Jed Hi Jed, Why do you consider explicit linking of recursive dependencies a bad thing? It's superfluous, I agree, but there's no harm in it, right? Best regards, Marcel Loose. It's called overlinking and can be a real problem for package maintainers. See e.g. here for an explanation: http://wiki.mandriva.com/en/Overlinking Michael OK, I see. This raises another question, which was already alluded to in this thread, and may have been asked before on this list: Is there a way to write FindXXX.cmake macros in such a way that they will always return the correct list of libraries to link against? I.e., a short list of direct dependencies when linking against shared libraries, and a long complete list of recursive dependencies when linking against static libraries. Best regards, Marcel Loose. ___ 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] third party library dependencies
On Mon, 2009-12-21 at 14:43 +0100, Michael Wild wrote: On 21. Dec, 2009, at 14:16 , Marcel Loose wrote: On Mon, 2009-12-21 at 13:32 +0100, Michael Wild wrote: On 21. Dec, 2009, at 12:17 , Marcel Loose wrote: On Fri, 2009-12-18 at 08:54 -0800, Jed Brown wrote: On Fri, 18 Dec 2009 10:19:05 +0100, Marcel Loose lo...@astron.nl wrote: Hi Roman, Not in a portable way. I'm not too familiar with Windows, but on Linux you can do this when libA is a shared library that has its dependency on libB linked in (e.g. ldd libA.so will tell you this). When linking in static libraries you're out of luck. With shared libraries, you need not and *should not* explicitly link recursive dependencies. If you have both static and shared libraries, the output of ldd could be used to find the recursive deps needed to link statically. This sucks and the logic to determine whether to put recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is insane. FWIW, pkg-config has Libs.private for this purpose. Finally, it would be nice to easily associate a symbol with a call to find_library. That is, suppose libA links to libB and libC, but libA never exposes libB or libC to users. To do the right thing (without abusing ldd), FindA.cmake needs to try linking with just -lA (which will work with all shared libs), then try with -lA -lB and -lA -lC before falling back to -lA -lB -lC (which is required when all libs are static). A better way which does not have exponential complexity would be to declare that the symbol B_Foo belongs with a libB and C_Bar belongs with a libC. So when linking with -lA fails, libB would be added exactly when B_Foo is undefined. Jed Hi Jed, Why do you consider explicit linking of recursive dependencies a bad thing? It's superfluous, I agree, but there's no harm in it, right? Best regards, Marcel Loose. It's called overlinking and can be a real problem for package maintainers. See e.g. here for an explanation: http://wiki.mandriva.com/en/Overlinking Michael OK, I see. This raises another question, which was already alluded to in this thread, and may have been asked before on this list: Is there a way to write FindXXX.cmake macros in such a way that they will always return the correct list of libraries to link against? I.e., a short list of direct dependencies when linking against shared libraries, and a long complete list of recursive dependencies when linking against static libraries. Best regards, Marcel Loose. I honestly don't know. I wouldn't even know how to reliably differentiate between static and dynamic libraries. AFAIK some platforms use the same naming scheme, e.g. Windows uses .lib for both, static libraries and import libraries. AIX distinguishes between shared objects (really, only an object file with shared code) and shared libraries. The former either uses .o or .so (who had THIS great idea), while shared libraries use .a as do static libraries. Very confusing: http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=/com.ibm.vacpp7a.doc/getstart/overview/port_aix_obj_lib.htm Perhaps we need some new IF(STATIC_LIBRARY filename) command? But then that would probably require a database with file detection magic (such as Unix file(1) command uses) Michael Hi Michael, and others, Upon (re)reading the Mandriva page you were referring to, I was thinking: maybe this issue can be solved more or less the same way as pkg-config does: i.e. by defining private dependencies. This could be an extra option to target_link_libraries. Something like: target_link_libraries(mylib public1 public2 PRIVATE private1 private2) This would tell CMake that mylib directly depends on public1 and public2 and should *only* link in these two libraries when these are shared object libraries; otherwise private1 and private2 would also need to be added on the link line. The big hurdle to take, of course, is to detect in a platform-independent way whether the given library is shared or static. However, a lot of this knowledge is already available in the diverse Modules/Platform macros, so my feeling is that this should be feasible. Best regards, Marcel Loose. ___ 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] third party library dependencies
Hi Roman,
Not in a portable way. I'm not too familiar with Windows, but on Linux
you can do this when libA is a shared library that has its dependency on
libB linked in (e.g. ldd libA.so will tell you this). When linking in
static libraries you're out of luck.
I would write a FindA.cmake file for this and let that macro set the
variable A_LIBRARIES to contain both libA and libB. You can then use:
find_package(A)
target_link_libraries(${A_LIBRARIES})
Hope this helps,
Marcel Loose.
On Thu, 2009-12-17 at 12:18 -0500, Roman Shtylman wrote:
Is there an easy way to setup link dependencies between libraries not
build using cmake?
Lets say I have a system library A which depends on system library B.
I then make an executable that uses code from A. I need to link
against A and B, but as a user of just library A, I don't want to
worry about that. Does cmake have a facility to define such a
hierarchy/dependency chain so that I can just do
target_link_libraries(target A)
and have it figure out that it needs to link against B as well?
Note that neither A nor B are built using cmake, they already exist.
~Roman
___
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] third party library dependencies
Hi Adolfo,
I cannot reproduce the problem you mention. I made the following
CMakeLists.txt file:
cmake_minimum_required(VERSION 2.6)
project(MyBoost)
find_package(Boost REQUIRED COMPONENTS date_time)
message(STATUS Boost_FOUND=${Boost_FOUND})
message(STATUS Boost_LIBRARIES=${Boost_LIBRARIES})
find_package(Boost REQUIRED COMPONENTS regex)
message(STATUS Boost_FOUND=${Boost_FOUND})
message(STATUS Boost_LIBRARIES=${Boost_LIBRARIES})
Running cmake (2.6.2) produces:
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Boost version: 1.36.0
-- Found the following Boost libraries:
-- date_time
-- Boost_FOUND=TRUE
-- Boost_LIBRARIES=/usr/lib64/libboost_date_time-mt.so
-- Boost version: 1.36.0
-- Found the following Boost libraries:
-- regex
-- Boost_FOUND=TRUE
--
Boost_LIBRARIES=/usr/lib64/libboost_date_time-mt.so;/usr/lib64/libboost_regex-mt.so
-- Configuring done
-- Generating done
So, in my case boost_regex is nicely added to boost_date_time.
Best regards,
Marcel Loose.
On Fri, 2009-12-18 at 10:48 +0100, Adolfo Rodríguez Tsouroukdissian
wrote:
On Fri, Dec 18, 2009 at 10:19 AM, Marcel Loose lo...@astron.nl
wrote:
Hi Roman,
Not in a portable way. I'm not too familiar with Windows, but
on Linux
you can do this when libA is a shared library that has its
dependency on
libB linked in (e.g. ldd libA.so will tell you this). When
linking in
static libraries you're out of luck.
I would write a FindA.cmake file for this and let that macro
set the
variable A_LIBRARIES to contain both libA and libB. You can
then use:
find_package(A)
target_link_libraries(${A_LIBRARIES})
I've had to deal with this issue and Marcel's proposal is what I do.
There is one slight gotcha that I haven't resolved cleanly yet.
Suppose that A_LIBRARIES depends on certain Boost components, so
inside FindA.cmake I perform a
find_package(Boost REQUIRED COMPONENTS xxx yyy)
and append Boost_LIBRARIES to A_LIBRARIES. Note: I use find_package
instead of hardcoding the library names so that libraries appear as
fully qualified paths, and nonstandard installation paths can be used.
Everything OK for now.
Now, in my project, which depends on A and some other Boost component
I do
find_package(A)
find_package(Boost REQUIRED COMPONENTS zzz)
What happens is that since Boost was already found in A, the zzz
component is not included in Boost_LIBRARIES. Has anybody found a
successful way of dealing with this?
TIA,
Adolfo
Hope this helps,
Marcel Loose.
On Thu, 2009-12-17 at 12:18 -0500, Roman Shtylman wrote:
Is there an easy way to setup link dependencies between
libraries not
build using cmake?
Lets say I have a system library A which depends on system
library B.
I then make an executable that uses code from A. I need to
link
against A and B, but as a user of just library A, I don't
want to
worry about that. Does cmake have a facility to define such
a
hierarchy/dependency chain so that I can just do
target_link_libraries(target A)
and have it figure out that it needs to link against B as
well?
Note that neither A nor B are built using cmake, they
already exist.
~Roman
___
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
--
Adolfo Rodríguez Tsouroukdissian, Ph. D.
Robotics engineer
PAL ROBOTICS S.L
http://www.pal
Re: [CMake] Acces macro/functions to subfolders
On Wed, 2009-12-16 at 09:28 -0800, Tyler Roscoe wrote: On Wed, Dec 16, 2009 at 05:55:54PM +0100, Olivier Pierard wrote: In order to be able to use a macro/function from several sub-folders, I would like to define it only once in the main CMakeLists.txt. However, after some basic tests, It seems impossible to call this macro/function from subfolders. Is is possible to do it ? It works for me. By the way, what's the basic difference between macro/function in cmake ? Related to preprocessing like in C/C++ ? What's the advantage of distinguish them here ? The details are in the docs, though you have to read carefully to notice. I think the biggest difference is that the contents of a macro are dropped in, as though with #define. Functions are an actual function call and functions have their own scope. tyler Another important difference is that, for functions, ARGV and ARGN and ARGVn (n=1..) are real variables that have local scope. Best regards, Marcel Loose. ___ 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 can I add gprof profiler to my CMakeLists.txt?
On Tue, 2009-12-15 at 12:08 +0800, Water Lin wrote: I want to use gprof to analyze my code. So I try to embed the -pg paramter for g++ in my CMakeLists.txt file. But after I embeded the -pg to my CMakeLists.txt like this: - add_definitions(-pg -march=pentium4 -msse3 -g) - and I recompile my code. There is no gprof output file. But when I use command like: $ g++ -pg to compile my code, gprof will generate a output file gmon.out. So, how can I enable gprof profiler in my CMakeLists.txt? Thanks Water Lin Hi Water Lin, From the g++ info files: `-pg' Generate extra code to write profile information suitable for the analysis program `gprof'. You must use this option when compiling the source files you want data about, and you must also use it when linking. So, you should use `-pg' both when compiling and linking. The command add_definitions() will only add this option during compilation. You should also add `-pg' to CMAKE_EXE_LINKER_FLAGS or to CMAKE_EXE_LINKER_FLAGS_[CMAKE_BUILD_TYPE], where CMAKE_BUILD_TYPE could be, e.g., `DEBUG'. HTH, Marcel Loose. ___ 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] Building tests only for make test
Hi Stefan, You found a typo. I'll fix that right away. Thanks. I've never tried to use the 'check' target with ctest, so I'm not sure whether it should work or not. Maybe someone else can comment on this. Best regards, Marcel Loose. On Mon, 2009-12-14 at 12:49 +0100, Dr. Stefan Sablatnög wrote: Hi Marcel, Thanks for the hint, the wiki states it should be CMAKE_TEST_COMMAND, I think this should be CMAKE_CTEST_COMMMAND? By the way is there a way to make ctest use this new check target instead of the default all in a continous testing configuration? (I tried ctest.exe --build-target check -D ContinuousStart -D ContinuousUpdate -D ContinuousConfigure -D ContinuousBuild -D ContinuousTest -D ContinuousSubmit And it didn't work as expected, but maybe I made a mistake) Thanks Stefan -Original Message- From: Marcel Loose [mailto:lo...@astron.nl] Sent: Freitag, 11. Dezember 2009 18:17 To: stefan.sablatn...@svox.com Cc: cmake@cmake.org Subject: Re: [CMake] Building tests only for make test Hi Stefan, I once dug into this issue, because I wanted to (more or less) emulate the GNU Autotools 'make check' feature. Have a look at http://www.cmake.org/Wiki/CMakeEmulateMakeCheck and see if that answers you question. Best regards, Marcel Loose. On Fri, 2009-12-11 at 15:53 +0100, Dr. Stefan Sablatnög wrote: Hi all, I face a (probably simple) problem: I want to build a project, that includes tests, but these should not be build on default, so I added EXCLUDE_FROM_ALL to the add_executable command. How can I force them to be built when testing ? (we test through make test and continuously via a ctest script) Is there a simple solution? Thanks in advance Stefan -- best regards Dr. Stefan Sablatnög email: stefan.sablatn...@svox.com phone: ++49 731 15239474 address: SVOX Ulm Magirus Deutz-Straße 16 89077 Ulm ___ 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] cmake -E create_symlink for Windows
On Sat, 2009-12-12 at 12:02 -0500, Bill Hoffman wrote: Alan W. Irwin wrote: On 2009-12-12 09:44-0500 David Cole wrote: On Fri, Dec 11, 2009 at 10:04 AM, Michael Wild them...@gmail.com wrote: Bummer. What where they THINKING??? (if at all...). It seems to me that M$ just CAN'T get it right. No matter how many times they try, how many good examples are out there, they always manage to seriously screw something up... Come to think of it, they probably were thinking about symlink-attacks... Come on. Let's make a deal: you don't bash Microsoft, Apple or Google here on the CMake mailing list and I won't bash Unix or Linux in any forum, anywhere, ever. OK? Does that sound cool? Absolutely. There used to be another poster here (before he got so-over-the-top that he was removed) that kept making gratuitous attacks on Linux and free software, and that was extremely annoying. So as a Linux developer I support Dave's call to be aware of other's strong feelings and stay on topic so we don't waste a lot of time here. Back on topic I am one of the lead developers of the PLplot CMake-based build system. However, my development experience is Linux only so I must rely on my Windows developer colleagues to catch any Linux-only or Unix-only mistakes I put into our build system. Up to this thread, I had no idea that there wasn't some reliable way to create symlinks on Windows, and it's only by chance that I haven't used create_symlink in any part of our build other than the Linux-only documentation build. Before this thread, I always assumed cmake -E commands gave you an excellent way to do common tasks in a cross-platform way. I appeal to the CMake developers to avoid from now on implementing any more CMake -E commands that have no hope of ever fulfilling that mandate, Also, please deprecate and document the cmake -E commands with obvious cross-platform limitations because otherwise your users are going to assume (like I did) that those commands are the recommended way to help make their project cross-platform. Is create_symlink an isolated case, or are there other cmake -E commands to worry about? Also, is create_symlink really a lost cross-platform cause? Reading later in Dave's post, it appears that the symlink concept does work on some Windows platform (he mentioned something about shortcuts). If there are intentions to make it work on a number of Windows platforms eventually, but that just hasn't happened yet, then _warn_ about that issue (e.g., something like Unix-only for now in the documentation). Also, if the CMake -E command is run on a platform that doesn't support it something better than a silent failure should be the result. Some things just can not be done cross platform. For example reading/ writing the windows registry, creating an OSX application bundle, and sym-links. Also, some computers don't even have shared libraries. Should we disable those features from CMake? That said, the symlink command is the only -E that does not work cross platform. The -E create_symlink does return failure from main when called on windows. So, if you used it in a custom command which is the idea for -E stuff, it would fail in a noticeable way (the build would fail). If you call it from execute_process, you should be checking the return value as well. -Bill Just out of curiosity: how does Cygwin handle this whole symbolic link business? Marcel Loose. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake -E create_symlink for Windows
On Mon, 2009-12-14 at 08:23 -0500, Bill Lorensen wrote: http://en.wikipedia.org/wiki/Symbolic_link#Cygwin_symbolic_links OK, that puts us back at square one. Why is it that CMake cannot use Windows shortcuts as an alternative to Unix symbolic links, whereas Cygwin can? Best regards, Marcel Loose. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake -E create_symlink for Windows
On Sat, 2009-12-12 at 14:35 -0800, Alan W. Irwin wrote: On 2009-12-12 12:02-0500 Bill Hoffman wrote: Some things just can not be done cross platform. For example reading/ writing the windows registry, creating an OSX application bundle, and sym-links. Also, some computers don't even have shared libraries. Should we disable those features from CMake? That said, the symlink command is the only -E that does not work cross platform. The -E create_symlink does return failure from main when called on windows. So, if you used it in a custom command which is the idea for -E stuff, it would fail in a noticeable way (the build would fail). If you call it from execute_process, you should be checking the return value as well. I guess I am the victim of the assumption that all cmake -E commands are supposed to work cross-platform since all of them do so (which I was glad to hear) other than create_symlink. Right now, here is what cmake -E help says about that command. create_symlink old new- create a symbolic link new - old If you simply added (UNIX ONLY) to that documentation string, then users like me wouldn't make unwarranted assumptions. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ I second that. I was also under the impression that 'cmake -E' provided a nice abstraction for a number of commands that could be used cross-platform, but with different syntaxes. Seems that create_symlink is the odd one out here. Bummer! The thing is: it's too late when the build fails (on Windows), because long before then, I, as a developer of the build environment, decided to use the presumed cross-platform command create_symlink, only to find out much later that it doesn't work on Windows. Best regards, Marcel Loose. ___ 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] cmake -E create_symlink for Windows
Hi all, I was browsing the CMake sources for a problem I was facing with the creation of symlinks (on Unix that is) and I noticed that the SystemTools::CreateSymlink function simply returns false when building on a Windows platform. Does that mean that I cannot use 'cmake -E create_symlink' on Windows. If that's the case I consider it a bug, because the documentation suggests that 'cmake -E create_symlink' provides a platform independent way of creating symbolic links. So, if the OS and/or filesystem does not support symbolic links, IMHO, it should just copy the file. Best regards, Marcel Loose. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake -E create_symlink for Windows
On Fri, 2009-12-11 at 14:51 +0100, Michael Wild wrote: On 11. Dec, 2009, at 14:27 , Marcel Loose wrote: Hi all, I was browsing the CMake sources for a problem I was facing with the creation of symlinks (on Unix that is) and I noticed that the SystemTools::CreateSymlink function simply returns false when building on a Windows platform. Does that mean that I cannot use 'cmake -E create_symlink' on Windows. If that's the case I consider it a bug, because the documentation suggests that 'cmake -E create_symlink' provides a platform independent way of creating symbolic links. So, if the OS and/or filesystem does not support symbolic links, IMHO, it should just copy the file. Best regards, Marcel Loose. Simply copying the file might be just as bad if people assume it really IS a symlink... IMHO, if the OS can't create a symlink, cmake -E create_symlink should fail loudly, not just silently ignore it. And somebody should implement this function for Windows = Vista/2008 (i.e. WINVER = 0x0600): http://msdn.microsoft.com/en-us/library/aa363866(VS.85).aspx Michael Hi Michael, I think it depends. Failing loudly may not always be desirable, just as failing silently. In my particular case, I was just creating a bunch of symlinks to directories; no need to discern these symlinks from the actual directories, but I need to be able to access the directory contents. When it comes to symlinks to files, there may be situations where you would really like it to be a link, e.g. when editing the file. Would that be a CMake usage scenario?? I don't know what's the best way to deal with this issue. What do the CMake developers think of this? Best regards, Marcel Loose. ___ 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] Building tests only for make test
Hi Stefan, I once dug into this issue, because I wanted to (more or less) emulate the GNU Autotools 'make check' feature. Have a look at http://www.cmake.org/Wiki/CMakeEmulateMakeCheck and see if that answers you question. Best regards, Marcel Loose. On Fri, 2009-12-11 at 15:53 +0100, Dr. Stefan Sablatnög wrote: Hi all, I face a (probably simple) problem: I want to build a project, that includes tests, but these should not be build on default, so I added EXCLUDE_FROM_ALL to the add_executable command. How can I force them to be built when testing ? (we test through make test and continuously via a ctest script) Is there a simple solution? Thanks in advance Stefan -- best regards Dr. Stefan Sablatnög email: stefan.sablatn...@svox.com phone: ++49 731 15239474 address: SVOX Ulm Magirus Deutz-Straße 16 89077 Ulm ___ 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] get_target_property CONFIG_LOCATION for custom target?
Hi all, I was trying to see whether I could retrieve the target location of a custom target using the CONFIG_LOCATION property of the given target, but to no avail. Is it possible to do this? Best regards, Marcel Loose. ___ 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] get_target_property CONFIG_LOCATION for custom target?
Hi all, Found it in the manual, but not under get_target_property(). It's not possible. Sorry for the noise. Best regards, Marcel Loose. On Wed, 2009-12-09 at 15:09 +0100, Marcel Loose wrote: Hi all, I was trying to see whether I could retrieve the target location of a custom target using the CONFIG_LOCATION property of the given target, but to no avail. Is it possible to do this? Best regards, Marcel Loose. ___ 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] Is it safe to add properties to custom target?
Hi all,
In fact the subject title says it all. Is it safe to do, for example:
add_custom_target(myTarget)
set_target_properties(myTarget PROPERTIES
LOCATION ${CMAKE_CURRENT_BINARY_DIR})
It seems to work fine, but I'm not sure this is the right way to do it.
Best regards,
Marcel Loose.
___
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] 32 bits compilation on x64 platform - how to find system libraries
Hi Olivier, I think you need to set the global property FIND_LIBRARY_USE_LIB64_PATHS to OFF. BTW, I disagree with Mathieu that building 32-bit libraries/executables on a 64-bit system is cross-compilation. These binaries can be run without a problem on the host system. So, IMHO, you don't need a toolchain file. The only thing you have to do is instruct gcc/g++ to generate 32-bit objects/binaries, using the -m32 option, and tell CMake to look in lib instead of lib64 by setting the aforementioned property. Hope this helps. Best regards, Marcel Loose. On Mon, 2009-12-07 at 10:09 +0100, Olivier Pierard wrote: Mathieu Malaterre wrote: On Fri, Dec 4, 2009 at 4:39 PM, Olivier Pierard olivier.pier...@cenaero.be wrote: Dear all, In order to perform 32 bits compilation on 64 bits platform, how can I tell that all find_libraries for which no path is specified to look in /usr/lib instead of /usr/lib64 ? Is there a configuration variable for cmake platform or a default searching directories variable ? This is called CMAKE_FIND_ROOT_PATH See for example: http://gdcm.svn.sf.net/viewvc/gdcm/trunk/CMake/Toolchain-gcc-m32.cmake?view=markup Thank you Mathieu. Problem is that cmake appends '(/usr)/lib64' automatically to the CMAKE_FIND_ROOT_PATH. And since I want to switch between '/usr/lib' and '/usr/lib64', setting the ROOT_PATH to '/usr' or '/' always ends up with libraries found in /usr/lib64. Setting it to '/usr/lib' seems to be ignored because there is nothing in /usr/lib/lib64. Olivier You man need to read: http://www.cmake.org/Wiki/CMake_Cross_Compiling Cheers ___ 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] 32 bits compilation on x64 platform - how to find system libraries
On Mon, 2009-12-07 at 13:19 +0100, Mathieu Malaterre wrote: On Mon, Dec 7, 2009 at 11:43 AM, Marcel Loose lo...@astron.nl wrote: Hi Olivier, I think you need to set the global property FIND_LIBRARY_USE_LIB64_PATHS to OFF. BTW, I disagree with Mathieu that building 32-bit libraries/executables on a 64-bit system is cross-compilation. These binaries can be run without a problem on the host system. So, IMHO, you don't need a toolchain file. The only thing you have to do is instruct gcc/g++ to generate 32-bit objects/binaries, using the -m32 option, and tell CMake to look in lib instead of lib64 by setting the aforementioned property. There is two things from the top of my head: 1. ia64 which is not x86 compatible 2. You still need a libz/libpng/libjpeg compiled as 32bits on your amd64 system... I think the project needs to be self contained (convenient libs) otherwise to get it compiled using the -m32 trick 2cts Hi Mathieu Indeed, ia64 is not x86 compatible. I thought that Olivier was using a x86_64 processor. Most 64-bit distros (for x86_64 that is) also provide 32-bit libs/binaries. Best regards, Marcel Loose. ___ 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] FindHDF5 bug: HDF5_FOUND is not set
Hi all, I noticed that FindHDF5.cmake does not set HDF5_FOUND, although it says in the documentation of the file that it does. This is both with CMake 2.8 and with the CVS HEAD. Should I open an issue for this in the bug tracker, or is this bug too trivial for that. Best regards, Marcel Loose. ___ 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] [Fwd: FindHDF5 bug: HDF5_FOUND is not set]
Hi all, Sorry for the noise. Must be the Monday morning blues. HDF5_FOUND is of course set by FPHSA. Don't know exactly what's going wrong in my script, but it certainly has nothing to do with FindHDF5.cmake. Best regards, Marcel Loose. ---BeginMessage--- Hi all, I noticed that FindHDF5.cmake does not set HDF5_FOUND, although it says in the documentation of the file that it does. This is both with CMake 2.8 and with the CVS HEAD. Should I open an issue for this in the bug tracker, or is this bug too trivial for that. Best regards, Marcel Loose. ---End Message--- ___ 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] 32 bits compilation on x64 platform - how to find system libraries
On Mon, 2009-12-07 at 14:18 +0100, Olivier Pierard wrote:
Marcel Loose wrote:
On Mon, 2009-12-07 at 13:19 +0100, Mathieu Malaterre wrote:
On Mon, Dec 7, 2009 at 11:43 AM, Marcel Loose lo...@astron.nl wrote:
Hi Olivier,
I think you need to set the global property FIND_LIBRARY_USE_LIB64_PATHS
to OFF.
BTW, I disagree with Mathieu that building 32-bit libraries/executables
on a 64-bit system is cross-compilation. These binaries can be run
without a problem on the host system. So, IMHO, you don't need a
toolchain file. The only thing you have to do is instruct gcc/g++ to
generate 32-bit objects/binaries, using the -m32 option, and tell CMake
to look in lib instead of lib64 by setting the aforementioned property.
There is two things from the top of my head:
1. ia64 which is not x86 compatible
2. You still need a libz/libpng/libjpeg compiled as 32bits on your
amd64 system...
I think the project needs to be self contained (convenient libs)
otherwise to get it compiled using the -m32 trick
2cts
Hi Mathieu
Indeed, ia64 is not x86 compatible. I thought that Olivier was using a
x86_64 processor. Most 64-bit distros (for x86_64 that is) also provide
32-bit libs/binaries.
Thanks guys for your insights. I'm effectively working on a x86_64 with
32-bits pre-compiled libs provided by Suse in folder /usr/lib/ while
64-bits libraries are in /usr/lib64/.
Solution proposed by Marcel seemed perfectly suitable for me. So I tried:
set(FIND_LIBRARY_USE_LIB64_PATHS OFF)
...
find_library(FLTK_LIB_TEST NAMES fltk)
message(FIND_LIBRARY_USE_LIB64_PATHS: ${FIND_LIBRARY_USE_LIB64_PATHS})
message(FLTK_LIB_TEST: ${FLTK_LIB_TEST})
And with 'cmake -U *LIB* ..', I get:
FIND_LIBRARY_USE_LIB64_PATHS:OFF
FLTK_LIB_TEST:/usr/lib64/libfltk.a
Of course, libfltk.a is well in both folders /usr/lib/ and /usr/lib64/.
Olivier
Best regards,
Marcel Loose.
Hi Olivier,
FIND_LIBRARY_USE_LIB64_PATHS is a property. Set it like this:
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)
If you do, you'll see that CMake will find /usr/lib/libfltk.a.
Best regards,
Marcel Loose.
___
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] Conditional subdirectory build
Hi David,
Why not use OPTION(...) for this, or if you really want to the
equivalent: set(MYVAR ON CACHE BOOL My variable). Don't use FORCE, or
you will overwrite any changes the user made.
Best regards,
Marcel Loose.
On Sun, 2009-11-29 at 10:12 -0500, David Cole wrote:
if(BUILD_PARAVIEW_PLUGIN==ON)
should just be
if(BUILD_PARAVIEW_PLUGIN)
cmake --help-command IF
will explain...
There is no == but there are EQUAL and STREQUAL operators. In the
case of a boolean option variable, the syntax if(variable) if
preferred.
HTH,
David
On Sun, Nov 29, 2009 at 9:10 AM, David Doria daviddo...@gmail.com
wrote:
I am packaging a VTK filter. I am trying to give the user the
option
of additionally compiling the Paraview plugin for the filter
(in the
.../plugin directory). I wanted to make a
BUILD_PARAVIEW_PLUGIN
variable that they could set to ON or OFF. If it is set to
ON,
CMake should proceed with processing the plugin subdirectory.
Else,
just ignore it. However, when I generate the makefiles in both
cases,
they seem to be the same and neither includes the plugin
subdirectory.
Can anyone see where I have gone wrong?
My main CMakeLists.txt file is:
--
cmake_minimum_required(VERSION 2.6)
if(COMMAND cmake_policy)
cmake_policy(SET CMP0003 NEW)
endif(COMMAND cmake_policy)
PROJECT(vtkPointSetOutlierRemoval)
FIND_PACKAGE(VTK REQUIRED)
INCLUDE(${VTK_USE_FILE})
SET(BUILD_PARAVIEW_PLUGIN ON CACHE STRING Build Paraview
plugin? FORCE)
if(BUILD_PARAVIEW_PLUGIN==ON)
ADD_SUBDIRECTORY(plugin)
endif(BUILD_PARAVIEW_PLUGIN==ON)
ADD_EXECUTABLE(vtkPointSetOutlierRemoval Example.cxx
vtkPointSetOutlierRemoval.cxx)
TARGET_LINK_LIBRARIES(vtkPointSetOutlierRemoval vtkHybrid )
---
And the plugin subdirectory CMakeLists.txt file is:
FIND_PACKAGE(ParaView REQUIRED)
INCLUDE(${PARAVIEW_USE_FILE})
ADD_PARAVIEW_PLUGIN(PointSetOutlierRemoval 1.0
SERVER_MANAGER_XML PointSetOutlierRemoval.xml
SERVER_MANAGER_SOURCES ../vtkPointSetOutlierRemoval.cxx
)
Thanks,
David
___
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
___
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] enable_language( ... OPTIONAL) causes error on second cmake run
Hi Alex,
I've written a very small work-around for my problem.
I noted that 'enable_language(Fortran)' sets the compiler to
CMAKE_Fortran_COMPILER-NOTFOUND, whereas 'enable_language(Fortran
OPTIONAL) sets it to the empty string. So what I do now is check whether
CMAKE_Fortran_COMPILER is defined and matches the empty string, and if
so, I set it to CMAKE_Fortran_COMPILER-NOTFOUND. I had expected that I
should set it as a cache variable, but it only seems to work if I set it
as a normal variable.
# Work-around for CMake issue #9220
if(DEFINED CMAKE_Fortran_COMPILER AND CMAKE_Fortran_COMPILER MATCHES ^
$)
set(CMAKE_Fortran_COMPILER CMAKE_Fortran_COMPILER-NOTFOUND)
endif(DEFINED CMAKE_Fortran_COMPILER AND CMAKE_Fortran_COMPILER MATCHES
^$)
I'll add this work-around to the notes for issue #9220.
Best regards,
Marcel Loose.
On Thu, 2009-11-26 at 16:12 +0100, Marcel Loose wrote:
Hi Alex,
On second thought: the problem I encountered is somewhat different than
the one described in issue #9220. The problem there is that the compiler
name gcc whatever is interpreted as compiler gcc with an argument
whatever.
In my case I do not set a compiler from the command line. I use
'enable_language(Fortran OPTIONAL)' and let CMake search for the Fortran
compiler. Since there's no Fortran compiler installed, CMake will not
find it. So far, so good. But, when I run CMake a second time, I get the
error I reported.
What's your thought on this?
Best regards,
Marcel Loose.
On Wed, 2009-11-25 at 19:16 +0100, Alexander Neundorf wrote:
On Wednesday 25 November 2009, Marcel Loose wrote:
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
${CMAKE_Fortran_COMPILER} is empty. If I simply put quotes around
${CMAKE_Fortran_COMPILER} the problem is solved. Or so it seems. Right,
or wrong?
I think there's more to it IIRC, the rest of the enable-language process
has
to be canceled correctly, which is probably not the case with your fix.
But please put this comment in the bugtracker, so it doesn't get lost.
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
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] enable_language( ... OPTIONAL) causes error or second cmake run
Hi Alan, Thanks for your elaborate reply. I had taken a look at the work-around scripts that were upload for issue #9220 by you and Greg. They look quite rigorous. I've come up with a much simplier but probably less robust work-around. # Work-around for CMake issue 0009220 if(DEFINED CMAKE_Fortran_COMPILER AND CMAKE_Fortran_COMPILER MATCHES ^ $) set(CMAKE_Fortran_COMPILER CMAKE_Fortran_COMPILER-NOTFOUND) endif(DEFINED CMAKE_Fortran_COMPILER AND CMAKE_Fortran_COMPILER MATCHES ^$) It seems to work OK, at least for me. Best regards, Marcel Loose. On Thu, 2009-11-26 at 12:01 -0800, Alan W. Irwin wrote: On 2009-11-26 16:12+0100 Marcel Loose wrote: Hi Alex, On second thought: the problem I encountered is somewhat different than the one described in issue #9220. The problem there is that the compiler name gcc whatever is interpreted as compiler gcc with an argument whatever. In my case I do not set a compiler from the command line. I use 'enable_language(Fortran OPTIONAL)' and let CMake search for the Fortran compiler. Since there's no Fortran compiler installed, CMake will not find it. So far, so good. But, when I run CMake a second time, I get the error I reported. What's your thought on this? Sorry to enter the conversation late, but 9220 is the bug I reported, and gcc whatever was simply a test of how CMake responded to a non-working compiler, and the OPTIONAL signature fails in many other ways as well. Basically, I suggest you do not use the OPTIONAL signature until bug 9220 has been fixed. One way to avoid OPTIONAL is to use the workaround for bug 9220 that I implemented. (The bug report discussion in mantis has an early version of the workaround. The latest can be seen at http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support.cmake?view=log There are some PLplot-specific things in this workaround (for example, dealing with D and Ada as special cases) which you won't need for your own project's language needs. The workaround uses execute_process to run cmake with enable_language (without the OPTIONAL signature) for the appropriate language, and if the return code shows an error occurred, then you know the appropriate compiler for the language is missing/broken. Thus, with this method you can give users a soft landing for missing/broken compilers with appropriate warning messages, drop support for that language (for example, in PLplot we have a number of compiled languages we optionally support including Ada and D), and move on with the rest of the build. Except for potential inconsistency issues (see further discussion below), the workaround should be robust since whenever the compiler is missing/broken, execute_process should always give a return code that shows something wrong with the compiler. So I suggest you give a variant of my workaround that is suitable for your own project's language needs a try. The one known case where the workaround is not robust is when there is some inconsistency between the language enviroment for the execute_process version of cmake and the master cmake. In fact, for the PLplot version of the workaround we only pass on to the execute_process version of cmake the compiler flags set with environment variables. So if a user sets a compiler flag incorrectly by some other method, the PLplot version of the workaround cannot warn you about that situation, and the PLplot user gets a hard landing (Cmake Error) from the master cmake session. Because of this potential inconsistency issue, fixing bug 9220 is preferable to the workaround. However, the workaround should be a useful temporary measure (famous last words!) to deal with missing/broken compilers until that bug gets fixed. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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] enable_language( ... OPTIONAL) causes error or second cmake run
Hi Alex,
On second thought: the problem I encountered is somewhat different than
the one described in issue #9220. The problem there is that the compiler
name gcc whatever is interpreted as compiler gcc with an argument
whatever.
In my case I do not set a compiler from the command line. I use
'enable_language(Fortran OPTIONAL)' and let CMake search for the Fortran
compiler. Since there's no Fortran compiler installed, CMake will not
find it. So far, so good. But, when I run CMake a second time, I get the
error I reported.
What's your thought on this?
Best regards,
Marcel Loose.
On Wed, 2009-11-25 at 19:16 +0100, Alexander Neundorf wrote:
On Wednesday 25 November 2009, Marcel Loose wrote:
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
${CMAKE_Fortran_COMPILER} is empty. If I simply put quotes around
${CMAKE_Fortran_COMPILER} the problem is solved. Or so it seems. Right,
or wrong?
I think there's more to it IIRC, the rest of the enable-language process has
to be canceled correctly, which is probably not the case with your fix.
But please put this comment in the bugtracker, so it doesn't get lost.
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] enable_language( ... OPTIONAL) causes error or second cmake run
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
${CMAKE_Fortran_COMPILER} is empty. If I simply put quotes around
${CMAKE_Fortran_COMPILER} the problem is solved. Or so it seems. Right,
or wrong?
Best regards,
Marcel Loose.
On Tue, 2009-11-24 at 19:48 +0100, Alexander Neundorf wrote:
On Tuesday 24 November 2009, Marcel Loose wrote:
Hi all,
I've been experimenting a bit with enable_language() and stumbled upon
what I think is a bug.
Yes: http://public.kitware.com/Bug/view.php?id=9220
It's not trivial to make it work.
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] enable_language( ... OPTIONAL) causes error or second cmake run
Done, see Note 0018597
Best regards,
Marcel Loose.
On Wed, 2009-11-25 at 19:16 +0100, Alexander Neundorf wrote:
On Wednesday 25 November 2009, Marcel Loose wrote:
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
${CMAKE_Fortran_COMPILER} is empty. If I simply put quotes around
${CMAKE_Fortran_COMPILER} the problem is solved. Or so it seems. Right,
or wrong?
I think there's more to it IIRC, the rest of the enable-language process has
to be canceled correctly, which is probably not the case with your fix.
But please put this comment in the bugtracker, so it doesn't get lost.
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] enable_language( ... OPTIONAL) causes error or second cmake run
Hi all, I've been experimenting a bit with enable_language() and stumbled upon what I think is a bug. I have wanted to know how to properly handle a missing Fortran compiler. So, on a system without a working Fortran compiler I ran cmake twice. In the first cmake run, the Fortran compiler is searched and not found. However, the second run of cmake then causes an error, which IMHO should not happen. This happens with CMake 2.6.2 and 2.8.0 $ cat ../CMakeLists.txt project(Dummy) cmake_minimum_required(VERSION 2.6) enable_language(Fortran OPTIONAL) $ cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- The Fortran compiler identification is unknown -- Configuring done -- Generating done -- Build files have been written to: /tmp/loose/cmake/build $ cmake .. -- The Fortran compiler identification is unknown CMake Error at /dop131_0/loose/x86_64-linux/usr/share/cmake-2.8/Modules/CMakeFortranInformation.cmake:25 (GET_FILENAME_COMPONENT): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): CMakeLists.txt:3 (enable_language) -- Configuring incomplete, errors occurred! Best regards, Marcel Loose. ___ 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] Double Substitution in IF Statement
Hi Aaron,
If I run your script (using CMake 2.6.2) I get
-- CONTAINS_LIB = TRUE
as output. Isn't that what you expected? If not, then I'm missing the
point of your macro LIST_CONTAINS. What version of CMake are you using?
Best regards,
Marcel Loose.
On Wed, 2009-11-18 at 09:54 -0800, aaron_wri...@selinc.com wrote:
I have a little question about how to prevent double substitution in
an IF statement.
Consider this macro that looks through a list for a string, and sets a
variable to TRUE if it is found. The problem I have is that the IF
statement substitutes ${VALUE2} with LIB, and then substitutes LIB
with HELLO, and finds what it's looking for, even though it wasn't
really there. I want it to stop at the first substitution to prevent
this weird behavior. Ideas?
MACRO(LIST_CONTAINS VAR VALUE)
SET(${VAR})
FOREACH(VALUE2 ${ARGN})
IF(${VALUE} STREQUAL ${VALUE2})
SET(${VAR} TRUE)
ENDIF()
ENDFOREACH()
ENDMACRO()
SET(LIB HELLO)
SET(LIBS LIB IS GREAT)
LIST_CONTAINS(CONTAINS_LIB ${LIB} ${LIBS})
MESSAGE(STATUS CONTAINS_LIB = ${CONTAINS_LIB})
-
Aaron Wright
Software Engineer - DCS Group
Schweitzer Engineering Laboratories, Inc.
Pullman, WA 99163
509-334-8087
___
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] How to get ADD_DEFINITIONS variable?
Hi SirAnn,
COMPILE_DEFINITIONS is a directory property, not a variable.
You can retrieve that value using get_directory_property(). For example:
get_directory_property(defs COMPILE_DEFINITIONS)
message(STATUS Compile definitions: ${defs})
Note that the value of COMPILE_DEFINITIONS is scope dependent, as each
add_subdirectory() creates a new scope.
Hope this helps,
Marcel Loose.
On Tue, 2009-11-17 at 10:40 +0100, Sören Freudiger wrote:
Hi @all
In our project we are several times adding preprocessor defines via
ADD_DEFINITIONS.
Now I need to get these defines to add them for a ADD_CUSTOM_COMMAND (pre
build via swig ).
The documentations says that these defines are stored in
COMPILE_DEFINITIONS
but this variable is empty!!!
Is there any way to obtain the preprocessor defines?
Best,
SirAnn
___
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] Shouldn't FindHDF5 also set HDF5_INCLUDE_DIRS?
Hi all, According to the guidelines in the Modules/readme.txt file, each FindXXX.cmake file should define a non-cached XXX_INCLUDE_DIRS variable. I noticed that FindHDF5.cmake doesn't. Maybe this can be fixed before CMake 2.8.0? Best regards, Marcel Loose. ___ 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] ARGVn madness?!
Hi Brad, Michael, Your explanation makes sense. I hadn't run into this problem before, and assumed I could safely access ARGVn, whether or not n = ARGC. Turns out I was just lucky. I'll use ARGN instead. Thanks, Marcel Loose. On Fri, 2009-11-13 at 07:52 -0500, Brad King wrote: Michael Wild wrote: Looks like the scoping algorithm only overwrites these automatic variables only if they are associated with actual arguments, otherwise it just inherits them. Same thing happens if my_macro is a function. Smells like bug to me ;-) It's behaving exactly as documented. Functions make their arguments available as local variables using dynamic scoping. Macros have their arguments substituted into the implementation and then executed in the invoking context (the function's scope in this case). This probably means, always check ARGC and only use ARGN to retrieve optional arguments... Or, check ARGC and don't index ARGVx for x = ARGC. This is the same as is needed for argc and argv[] in C. No one blindly indexes argv[x] for x = argc. -Brad ___ 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] Modification of a variable in a CMakeLists called with add_subdirectory
Hi Oliver, Use the option PARENT_SCOPE when setting the variable. HTH, Marcel Loose. On Mon, 2009-11-09 at 11:11 +0100, Olivier Pierard wrote: Hi, I'm facing another rather simple problem. I try to modify a variable defined in the main CMakeLists.txt within another one called by the add_subdirectory command. Modification is well taken into account in the subfolder but once back in the main one, variable is set back to its previous value. Is there a way to avoid this behavior ? Thanks for your help, Olivier ___ 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] CMake Error: RPATH_CHANGE
Hi all,
I encountered the following problem when trying to 'make install' a
statically linked executable on a ppc64 platform.
CMake Error at cmake_install.cmake:47 (FILE):
file RPATH_CHANGE could not write new RPATH:
/tmp/loose/cmake/cmake-rpath/install/lib
to the file:
/tmp/loose/cmake/cmake-rpath/install/bin/greetings
No valid ELF RPATH or RUNPATH entry exists in the file;
I could not reproduce this on a x86_64 platform. It seems that the
generated file cmake_install.cmake is the culprit. Diff-ing the file
generated on the ppc64 system with that generated on the x86_64 system
yields:
@@ -37,8 +37,17 @@
ENDIF(NOT CMAKE_INSTALL_COMPONENT OR ${CMAKE_INSTALL_COMPONENT}
MATCHES ^(Unspecified)$)
IF(NOT CMAKE_INSTALL_COMPONENT OR ${CMAKE_INSTALL_COMPONENT} MATCHES
^(Unspecified)$)
- FILE(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/bin TYPE
EXECUTABLE FILES
/tmp/loose/cmake/cmake-rpath/build/CMakeFiles/CMakeRelink.dir/greetings)
IF(EXISTS $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/greetings)
+FILE(RPATH_CHECK
+ FILE $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/greetings
+ RPATH /tmp/loose/cmake/cmake-rpath/install/lib)
+ ENDIF(EXISTS $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/greetings)
+ FILE(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/bin TYPE
EXECUTABLE FILES /tmp/loose/cmake/cmake-rpath/build/greetings)
+ IF(EXISTS $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/greetings)
+FILE(RPATH_CHANGE
+ FILE $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/greetings
+ OLD_RPATH
+ NEW_RPATH /tmp/loose/cmake/cmake-rpath/install/lib)
IF(CMAKE_INSTALL_DO_STRIP)
EXECUTE_PROCESS(COMMAND /usr/bin/strip
$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/greetings)
ENDIF(CMAKE_INSTALL_DO_STRIP)
Both cmake 2.6.4 and 2.8.0-rc5 show this behaviour, which looks like a
bug to me.
Best regards,
Marcel Loose.
___
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] string(RANDOM) bug?
Hi David,
I submitted a bug report: http://www.cmake.org/Bug/view.php?id=9851
Best regards,
Marcel Loose.
On Thu, 2009-11-05 at 11:14 -0500, David Cole wrote:
The problem is that srand is called *each* time that STRING(RANDOM is
invoked... And it is based on the current time stamp to the nearest
second. (Not exactly random if it's exactly correlated to what second
it currently is...)
I agree, this is a bug.
Would you submit a bug report in the bug tracker?
Would anyone object to changing this to call srand only on the very
first call to STRING(RANDOM in a given invocation of cmake? (Or does
somebody have a better suggestion? Perhaps passing the seed value in
as an optional parameter...?)
Thx,
David
On Thu, Nov 5, 2009 at 8:41 AM, Marcel Loose lo...@astron.nl wrote:
Hi all,
I expected that string(RANDOM...) would produce a different
string each
time it is invoked. Turns out that this string is only
different between
different cmake runs. This is not what I expected. IMHO this
is a bug,
either in the code, or in the documentation.
$ cat ../CMakeLists.txt
project(Dummy NONE)
cmake_minimum_required(VERSION 2.6)
string(RANDOM a)
string(RANDOM b)
message(STATUS a=${a})
message(STATUS b=${b})
$ cmake ..
-- a=PgDGb
-- b=PgDGb
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/loose/cmake/build
___
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] infinite loop when trying to change the compiler in CMakeLists.txt
Another way to deal with this is to set CMAKE_C_COMPILER and
CMAKE_CXX_COMPILER *before* the first project() command. You could do
this in the main CMakeLists.txt file or in a separate CMake script file
that you include before the project() command.
In fact, this is what also happens when you do cross-compilation using a
tool-chain file. The tool-chain file is being read as the very first
file, before any CMakeLists.txt file is processed.
I don't know if doing things this way is considered good practice, but
I'm using it for our project to build with different compilers depending
on the name of the build directory.
Hope this helps,
Marcel Loose.
On Thu, 2009-11-05 at 11:36 -0700, Will Dicharry wrote:
I think the best way to do that is with an initial cache via the -C
flag to cmake. Then you can set the initial CMAKE_LANG_COMPILER
option in a CMake file and start with that file.
I currently don't do this, but I should. At the moment I am doing
this wrong by using the CMAKE_TOOLCHAIN_FILE variable and setting up
the MPI wrapper compilers in there. This is currently working for me,
but it is the wrong way of doing it since the toolchain files should
really only be used for cross compiling.
-- Will
On 11/05/2009 11:07 AM, btho...@nexus.hu wrote:
Dear All,
I am managing a CFD code where wish to set the CMAKE_C_COMPILER and
CMAKE_CXX_COMPILER to openmpi
wrappers.
So far i was using cmake 2.4.7 and in the CMakeLists.txt the following
lines were working perfectly:
SET(CMAKE_C_COMPILER ${MPI_INSTALL_ROOT}/bin/mpicc )
SET(CMAKE_CXX_COMPILER ${MPI_INSTALL_ROOT}/bin/mpic++ )
Now that I changed to CMake 2.8.0 there is an infinite loop when trying to
configure:
n...@machine: ./deps/bin/cmake ../
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_C_COMPILER= /usr/bin/gcc
CMAKE_CXX_COMPILER= /usr/bin/c++
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_C_COMPILER= /usr/bin/gcc
CMAKE_CXX_COMPILER= /usr/bin/c++
... and enters an infinite loop.
If I set the compilers via command line arguments, its fine.
But for easy-to-compile-by-the-users reason, I would like to set them in
the CMakeLists.txt if
possible.
Can somebody help me out how to do this right?
The machine: Ubuntu, openmpi 1.3.3 with system gcc 4.4.1 behind
Thx:
Th
P.S.: I noted a bugfix in CMake 2.6.2 RC 2, may be connected:
Fix infinite recursion bug with try-compile and change of compilers
___
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
___
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] [CTest] Access test data from c++ code
Hi Thomas, It depends. I would prefer to keep a clean source tree and put any generated file in the build tree. That way you could (in principle) run cmake from a read-only source tree. But it's not wrong the way you do it. Regards, Marcel Loose. On Tue, 2009-11-03 at 17:38 +0100, Thomas wrote: Yes it works. My questions was if this is the way it should be done. ___ 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] Is it safe to use add_definitions() before the first project() command?
Hi all, Well the title says it all. Is it safe to use add_definitions() before the first project() command, or am I entering the realm of undefined behaviour then? Best regards, Marcel Loose. ___ 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] Are variable names guaranteed to be case-sensitive?
Hi all, Title says it all (again). I noticed, simply by trying out, that on Linux variable names are case sensitive. I.e. 'foo' and 'FOO' are two different variables. Is it safe to assume that this is, and will always be, the case on any platform? Best regards, Marcel Loose. ___ 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] Building statically linked executables
Hi all, I would like to be able to build statically linked executables. I currently have the following statements in one of my initialization macros: if(BUILD_STATIC_EXECUTABLES) set(CMAKE_EXE_LINKER_FLAGS -static) set(CMAKE_FIND_LIBRARY_SUFFIXES .a) set(CMAKE_EXE_LINK_DYNAMIC_C_FLAGS) # remove -Wl,-Bdynamic set(CMAKE_EXE_LINK_DYNAMIC_CXX_FLAGS) set(CMAKE_SHARED_LIBRARY_C_FLAGS) # remove -fPIC set(CMAKE_SHARED_LIBRARY_CXX_FLAGS) set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS)# remove -rdynamic set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS) # Maybe this works as well, haven't tried yet. # set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE) endif(BUILD_STATIC_EXECUTABLES) Does this cover all affected CMake variables, or am I still missing some. Note that this question is partly related to an earlier question of mine, Static linking and find_library(), which can be found at http://www.mail-archive.com/cmake@cmake.org/msg21106.html Best regards, Marcel Loose. ___ 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] FindBoost: FIND_PACKAGE ( Boost COMPONENTS filesystem )
Hi Philip,
I've been following this thread with interest. Your solution puts the
burden on the (ignorant) end-user's shoulders. How is that poor
developer going to solve the pre/post version 1.34 issue, which is a
Boost-internal issue? In an ideal world, Boost would provide the
FindBoost.cmake file, or would generate the BoostConfig.cmake file.
Anyway, IMHO this really should be solved in FindBoost.cmake. One
possible way to make maintenance less of a burden is to define Boost's
(version-dependent) inter-dependencies once in FindBoost.cmake and let
the macro resolve these dependencies. Something like:
set(Boost_filesystem_DEPENDENCIES)
set(Boost_wave_DEPENDENCIES)
set(Boost_serialization_DEPENDENCIES filesystem) # Just assuming
# Assume filesystem depends on system for Boost 1.34
if(${_boost_maj}.${_boost_min} VERSION_GREATER 1.34)
list(APPEND Boost_filesystem_DEPENDENCIES system)
endif()
# Assume wave depends on system for Boost 1.36
if(${_boost_maj}.${_boost_min} VERSION_GREATER 1.36)
list(APPEND Boost_wave_DEPENDENCIES system)
endif()
Does that make any sense?
Best regards,
Marcel Loose.
On Wed, 2009-11-04 at 11:14 -0500, Philip Lowman wrote:
Mathieu,
It's a nice idea, but given that Boost could make any one of its
libraries dependent on system at any time they want in the future
(and for all I know there are others already dependent on it, besides
wave and filesystem), I'd rather the user be responsible for adding
system manually. It's not too hard to figure this out from the link
errors.
On Nov 4, 2009 9:40 AM, Mathieu Malaterre
mathieu.malate...@gmail.com wrote:
Philip,
I guess I was not very clear in my previous email. But here is my
proposed change:
@@ -322,8 +322,14 @@
if(Boost_VERSION AND Boost_FIND_COMPONENTS)
math(EXPR _boost_maj ${Boost_VERSION} / 10)
math(EXPR _boost_min ${Boost_VERSION} / 100 % 1000)
- if(${_boost_maj}.${_boost_min} VERSION_LESS 1.35)
- list(REMOVE_ITEM Boost_FIND_COMPONENTS system)
+ if(${_boost_maj}.${_boost_min} VERSION_GREATER 1.34)
+ # when use asked for filesystem or wave, automatically add
+ # system to the list of components
+ list(FIND Boost_FIND_COMPONENTS filesystem v1)
+ list(FIND Boost_FIND_COMPONENTS wave v2)
+ if(v1 OR v2)
+ list(APPEND Boost_FIND_COMPONENTS system)
+ endif(v1 OR v2)
endif()
endif()
Therefore calling
FIND_PACKAGE ( Boost COMPONENTS filesystem REQUIRED)
will work on boost 1.34 and boost 1.34
Comments ?
On Tue, Nov 3, 2009 at 3:20 PM, Mathieu Malaterre
mathieu.malate...@gmail.com wrote: The way I see it to address
is that 'system' is an internal d...
--
Mathieu
___
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] Regular Expression weirdness (2.6 2.8RC3)
Hi Luis,
The way I'm reading the globbing expression -- which is not identical to
a regex, BTW -- the output makes perfect sense.
In HDR1 you collect all filenames that start with 'Spatial/csp'; then
contain zero or more wildcard characters; then the last character before
the dot should *not* be any of the characters 'c', 'o', 'n', 'f', 'i',
or 'g'; finally the name should end in '.h'.
So, HDR1 does not contain cspacedef.h because the last character before
the '.h' is an 'f', which is one of the forbidden characters in the
glob expression.
HTH,
Marcel Loose.
On Tue, 2009-10-27 at 23:55 +0100, L.M. de Vries wrote:
Hi,
In the folder Spatial there are multiple files. Among them are the
following:
cspacedefconfig.h
cspacedef.h
cspacediscr.h
cspacediscrconfig.h
Executing the following commands:
FILE(GLOB SPATIAL_HDR1 Spatial/csp*[^config].h)
FILE(GLOB SPATIAL_HDR2 Spatial/csp*.h)
MESSAGE(STATUS ${SPATIAL_HDR1})
MESSAGE(STATUS ${SPATIAL_HDR2})
The first Message only outputs cspacediscr.h (and NOT cspacedef.h).
The second Message does output cspacedef.h (and also the rest of the files).
Why does the first message not output cspacedef.h?
The problem occured with CMake 2.6, but I just tried out 2.8RC3 and I
get the same results
Regards,
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
___
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] Depending on all and custom targets
Hi Jens, It's not a bug. Quoting from the docs for add_custom_target: Dependencies listed with the DEPENDS argument may reference files and outputs of custom commands created with ADD_CUSTOM_COMMAND. The problem is that your target 'extras' doesn't create any files. By saying add_custom_target(complete DEPENDS extras) you're telling CMake that target 'complete' depends on the _file_ 'extras'. The correct way to do this is to use add_dependencies: add_custom_target(complete) add_dependencies(complete extras) HTH, Marcel Loose. On Fri, 2009-10-09 at 12:47 +0200, jens persson wrote: 2009/10/9 Eric Noulard eric.noul...@gmail.com: 2009/10/9 jens persson j...@persson.cx: I get the impression that I have two problems: depending on a custom_target and depending on all. Dependency from builtin target is currently unsupported. see: http://public.kitware.com/Bug/view.php?id=8438 OK, that settled then, I'll create my on taget my_all or something like that then :-) I think dependency from extras should work did you try with only extras and not all? Yes I get the following error: $ make complete [100%] Built target bar [100%] Built target extras make[3]: *** No rule to make target `extras', needed by `CMakeFiles/complete'. Stop. make[2]: *** [CMakeFiles/complete.dir/all] Error 2 make[1]: *** [CMakeFiles/complete.dir/rule] Error 2 make: *** [complete] Error 2 With this CMakeLists.txt file: PROJECT (tester) CMAKE_MINIMUM_REQUIRED (VERSION 2.6) CMAKE_POLICY (VERSION 2.6) add_executable(bar bar.c ) add_custom_target(extras DEPENDS bar ) add_custom_target(complete DEPENDS extras ) I've tried to look into the makefiles but could not find the solution. I have included the verbose output of make at the end of this mail It seems that the file CMakeFiles/complete.dir/build.make references the extras target that is defined in CMakeFiles/extras.dir/build.make Probably a bug. Will report it later. /jp $ VERBOSE=1 make complete /usr/bin/cmake -H/home/sejenpe/tmp/cmake-tester/complete -B/home/sejenpe/tmp/cmake-tester/complete --check-build-system CMakeFiles/Makefile.cmake 0 make -f CMakeFiles/Makefile2 complete make[1]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete' /usr/bin/cmake -H/home/sejenpe/tmp/cmake-tester/complete -B/home/sejenpe/tmp/cmake-tester/complete --check-build-system CMakeFiles/Makefile.cmake 0 /usr/bin/cmake -E cmake_progress_start /home/sejenpe/tmp/cmake-tester/complete/CMakeFiles 1 make -f CMakeFiles/Makefile2 CMakeFiles/complete.dir/all make[2]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete' make -f CMakeFiles/bar.dir/build.make CMakeFiles/bar.dir/depend make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete' cd /home/sejenpe/tmp/cmake-tester/complete /usr/bin/cmake -E cmake_depends Unix Makefiles /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete/CMakeFiles/bar.dir/DependInfo.cmake --color= make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete' make -f CMakeFiles/bar.dir/build.make CMakeFiles/bar.dir/build make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete' make[3]: Nothing to be done for `CMakeFiles/bar.dir/build'. make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete' /usr/bin/cmake -E cmake_progress_report /home/sejenpe/tmp/cmake-tester/complete/CMakeFiles 1 [100%] Built target bar make -f CMakeFiles/extras.dir/build.make CMakeFiles/extras.dir/depend make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete' cd /home/sejenpe/tmp/cmake-tester/complete /usr/bin/cmake -E cmake_depends Unix Makefiles /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete/CMakeFiles/extras.dir/DependInfo.cmake --color= make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete' make -f CMakeFiles/extras.dir/build.make CMakeFiles/extras.dir/build make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete' make[3]: Nothing to be done for `CMakeFiles/extras.dir/build'. make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete' /usr/bin/cmake -E cmake_progress_report /home/sejenpe/tmp/cmake-tester/complete/CMakeFiles [100%] Built target extras make -f CMakeFiles/complete.dir/build.make CMakeFiles/complete.dir/depend make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete' cd /home/sejenpe/tmp/cmake-tester/complete /usr/bin/cmake -E cmake_depends Unix Makefiles /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe/tmp/cmake-tester/complete /home/sejenpe
[CMake] Extra blank lines with SEND_ERROR and FATAL_ERROR ?!
Hi all, When using SEND_ERROR and FATAL_ERROR, extra blank lines are added between newline-separated strings. I don't really like this. Is it intentional, or is this a formatting bug? For example, the CMakeLists.txt file: cmake_minimum_required(VERSION 2.6) project(Dummy NONE) message(STATUS Line one\nLine two\nLine three) message(SEND_ERROR Line one\nLine two\nLine three) message(FATAL_ERROR Line one\nLine two\nLine three) produces the following output on console: -- Line one Line two Line three CMake Error at CMakeLists.txt:4 (message): Line one Line two Line three CMake Error at CMakeLists.txt:5 (message): Line one Line two Line three -- Configuring incomplete, errors occurred! As can be seen, SEND_ERROR and FATAL_ERROR add extra blank lines. Best regards, Marcel Loose. ___ 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] Trouble with parallel builds for targets created by add_executable, target_link_libraries, and add_library
On Tue, 2009-09-29 at 19:46 -0400, Bill Hoffman wrote: Alan W. Irwin wrote: On 2009-09-29 16:36-0400 Bill Hoffman wrote: make -j N is only supported with the all target. How difficult would it be to implement parallel build support for more than just the all target? Note, if there is some limitation that makes it impractical or inefficient to implement this current all target capability for every target, you could instead implement this capability just for the targets where this capability is wanted (as designated, say, by a PARALLEL_BUILD=ON target property). It is very hard to implement on top of make. Let me restate what I mean, it is not the all target that is special. You can do make -j N target. You just can't do make -jN target1 target2 if target1 and target2 have a common target that they depend on. You can only specify one target at a time for make -j N. The /fast targets could be used to avoid the issue you are having maybe... Hi Alan, I don't think this is a limitation of CMake. It's rather a limitation of make. An (in)famous example of doing a parallel build with 'make' that will likely cause a broken build is: $ make -j4 all install In this example, it's possible that 'make' will try to install, e.g., a library that has yet to be built. The only safe way to run a parallel 'make' with multiple targets is to serialize them (sounds contradictory, doesn't it?): $ make -j4 all make -j4 install Or better: $ export MAKEFLAGS=-j4 $ make all make install Best regards, Marcel Loose. ___ 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 not evaluate variable names ?
On Wed, 2009-09-30 at 09:28 +0200, fred.anta...@free.fr wrote:
Quoting Jeroen Dierckx jeroen.dier...@gmail.com:
On Wed, Sep 30, 2009 at 8:32 AM, fred.anta...@free.fr wrote:
Hi,
I've seen a previous discussion on this subject, but unfortunately, none
of
the
given solutions (as described on
http://www.cmake.org/Wiki/CMake:VariablesListsStrings) seem to work in my
case.
I'm using CMake to generate an XML config file, and one of the tags must
have an
argument as follows: args=${serverConfigChanged}. The XML is used by
CruiseControl, and unfortunately, it uses the same variable syntax as
CMake. I
tried almost every combination of escaping, double dollars, but couldn't
get the
correct output.
Is there some way to achieve that directly from the CMakeList.txt, or
should I
do that in the generator code ?
Hi Jeroen,
What about:
file(WRITE /tmp/dummy.xml args=\\${serverConfigChanged}\\n)
That works for me. You must escape the double quotes () and the dollar
sign ($).
Best regards,
Marcel Loose.
___
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] Trouble with parallel builds for targets c reated by add_executable, target_link_libraries , and add_library
On Wednesday 30 September 2009 21:16:10 Alexander Neundorf wrote: On Wednesday 30 September 2009, Marcel Loose wrote: On Tue, 2009-09-29 at 19:46 -0400, Bill Hoffman wrote: Alan W. Irwin wrote: On 2009-09-29 16:36-0400 Bill Hoffman wrote: make -j N is only supported with the all target. How difficult would it be to implement parallel build support for more than just the all target? Note, if there is some limitation that makes it impractical or inefficient to implement this current all target capability for every target, you could instead implement this capability just for the targets where this capability is wanted (as designated, say, by a PARALLEL_BUILD=ON target property). It is very hard to implement on top of make. Let me restate what I mean, it is not the all target that is special. You can do make -j N target. You just can't do make -jN target1 target2 if target1 and target2 have a common target that they depend on. You can only specify one target at a time for make -j N. The /fast targets could be used to avoid the issue you are having maybe... Hi Alan, I don't think this is a limitation of CMake. It's rather a limitation of make. An (in)famous example of doing a parallel build with 'make' that will likely cause a broken build is: $ make -j4 all install In this example, it's possible that 'make' will try to install, e.g., a library that has yet to be built. The only safe way to run a parallel 'make' with multiple targets is to serialize them (sounds contradictory, doesn't it?): $ make -j4 all make -j4 install Or better: $ export MAKEFLAGS=-j4 $ make all make install I never had a problem with make -j4 install (which builds all first) Alex ___ Hmm, bad example. What I wanted to point out is that doing a parallel 'make' may result in unexpected or incorrect behavior when specifying more than one target. In your case target 'install' implicitly depends on 'all', so you may not run into this issue. In general, you should do $ make target1 make target2, instead of $ make target1 target2 when doing a parallel 'make'. On second thought, I realize that this 'unexpected' or 'incorrect' behavior is usually caused by wrong or missing dependencies, which don't show up when doing a serial build. So maybe the original problem is a limitation of CMake after all. Best regards, Marcel Loose. ___ 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] INTERNAL vs. STATIC cache variables
On Fri, 2009-09-25 at 21:12 +0200, Alexander Neundorf wrote: On Friday 25 September 2009, Marcel Loose wrote: Hi all, Is there a difference in precedence between INTERNAL and STATIC cache variables? For example, what happens if I (accidentally) define an INTERNAL cache variable that is already or will be defined by CMake? Will the STATIC variable always have precedence? Or am I entering the realm of undefined behavior? I think this matters only for the GUI, i.e. ccmake and cmake-gui. INTERNAL variables are hidden there. Alex Hi Alex, I think both INTERNAL and STATIC cache variables are hidden by the GUI. From the documentation on set(), I tend to conclude that STATIC cache variables are use by CMake for storing values it uses internally, because you cannot set variables of type STATIC. This conclusion is backed by looking at the CMake source code. E.g., cmProjectCommand.cxx writes out the comment Value Computed by CMake for a.o. the cache variables CMAKE_PROJECT_NAME; and cmTarget.cxx writes out Dependencies for target for target dependency information. My question is: do I risk clobbering these STATIC cache variables when (accidentally) setting such a variable as INTERNAL? Or does a STATIC variable always take precedence? Of course I could just try this out and see what happens. But I don't want to run the risk that the behavior I find is CMake version-specific. Best regards, Marcel Loose. ___ 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] INTERNAL vs. STATIC cache variables
Hi all, Is there a difference in precedence between INTERNAL and STATIC cache variables? For example, what happens if I (accidentally) define an INTERNAL cache variable that is already or will be defined by CMake? Will the STATIC variable always have precedence? Or am I entering the realm of undefined behavior? Best regards, Marcel Loose. ___ 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] What changes to the cache file, if any, will trigger a rerun of CMake?
Hi all, I tried to figure this out by browsing the docs and the mailing lists, but failed. What changes to the cache file (CMakeCache.txt) will trigger a rerun of CMake. AFAIK changes to CMAKE_LANG_COMPILER will do this, but are there other situations? My reason for asking this is that I was wondering whether it is possible to force a re-run of CMake when one or more OPTION variables are changed in the cache *during* a CMake run. Best regards, Marcel Loose. ___ 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] What changes to the cache file, if any , will trigger a rerun of CMake?
On Wednesday 23 September 2009 17:45:39 Tyler Roscoe wrote: On Wed, Sep 23, 2009 at 03:02:31PM +0200, Marcel Loose wrote: What changes to the cache file (CMakeCache.txt) will trigger a rerun of CMake. AFAIK changes to CMAKE_LANG_COMPILER will do this, but are there other situations? Don't all changes to the cache trigger a CMake rebuild? My reason for asking this is that I was wondering whether it is possible to force a re-run of CMake when one or more OPTION variables are changed in the cache *during* a CMake run. This sounds a little scary but I think I've seen CMake do this when I edit a CMakeLists in the middle of a build on Linux. Other build systems might have different ideas about when to check whether the CMake-generated files are out of date, so this might only work on some platforms. tyler Well, I created a macro (inspired by the KDE macro in kdelibs, macro_optional_add_subdirectory) that will only do add_subdirectory() if the directory actually exists (useful to do partial builds of large projects). Inside the conditional part of that macro is the option() command to define a new build option. So, in that case, a new option is added to the cache *during* a CMake run. I wasn't sure if these changes would always trigger a re-run of CMake, cause my (few) experiments were a bit inconclusive. But, if each change to CMakeCache.txt triggers a CMake re-run, then I should be safe. Best regards, Marcel Loose. ___ 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] Updated FindThreads.cmake in tracker
On Mon, 2009-09-21 at 23:25 -0400, Philip Lowman wrote:
On Mon, Sep 21, 2009 at 6:07 AM, Marcel Loose lo...@astron.nl wrote:
On Sun, 2009-09-20 at 19:32 -0400, Philip Lowman wrote:
On Sun, Sep 20, 2009 at 3:02 PM, Hendrik Sattler
I'm hesitant to rewrite anything that works, especially if
it works on
platforms I don't have access too. :)
Include library variables probably could be added if it
can be done
in a safe way with the compile checks already in place.
Not sure on -pthread, we've never added it to our gcc
command lines
before. Looking at the man page, it's only a compile flag
under
IA-64, RS-6000, PPC, and SPARC. Would recommending people
add it to
their compiler flags and only rely on the output of
${CMAKE_THREAD_LIBS_INIT} for linking be the right thing to
do?
Hmm, don't know if the documentation is correct.
I tested this on Linux x86_64 (gcc 4.3) and on an old i686
(gcc 3.2). On
both systems, when I diff the output of 'gcc -E -dM' and 'gcc
-E -dM
-pthread' I get '#define _REENTRANT 1'.
So, -pthread clearly defines an extra preprocessor variable.
We've always defined _REENTRANT manually and specified -lpthread but
looking into this further I'm guessing we're just getting lucky since
we've never built on platforms where this doesn't work.
http://stackoverflow.com/questions/875789/gcc-do-i-need-dreentrant-with-pthreads
Also regarding the lack of a global -pthread in the docs, this post
was kind of illuminating.
http://lists.freebsd.org/pipermail/freebsd-threads/2003-September/001202.html
So the gist of it is, if your only Unix compiler is gcc and if you add
-pthread to your CMAKE_C_FLAGS/CMAKE_CXX_FLAGS you really have no
need for FindThreads at all, as far as I can tell.
--
Philip Lowman
Well, yes, unless you're considering Mac OSX a Unix system as well,
which IMHO it is, nowadays. GCC gives an 'unsupported option' warning
when specifying '-pthread'. So clearly, '-pthread' is not supported on
Mac OSX.
Marcel Loose
___
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] Updated FindThreads.cmake in tracker
On Sun, 2009-09-20 at 19:32 -0400, Philip Lowman wrote:
On Sun, Sep 20, 2009 at 3:02 PM, Hendrik Sattler
p...@hendrik-sattler.de wrote:
Am Sonntag 20 September 2009 17:16:19 schrieb Philip Lowman:
Hello,
I've merged (optional) Pthreads-win32 support into a
FindThreads.cmake
attached in the tracker and added some documentation on how
to use it.
Since FindThreads isn't my module I wanted to throw this up
on the mailing
list for feedback.
http://www.cmake.org/Bug/view.php?id=6399
Also, in regard to a previous mailing list thread about
FindThreads...
I'm not sure which platform the block Check if compiler
accepts -pthread
is executed on. The documentation I attached to the code
advises calling
target_link_libraries(target ${CMAKE_THREAD_LIBS_INIT}).
After grokking
the code a bit further I'm now guessing this -pthread
argument is
technically accepted by the linker and not needed by the
compiler, but it
would be nice to know this for sure to ensure the
documentation is correct.
gcc says:
-pthread
Adds support for multithreading with the pthreads
library. This
option sets flags for both the preprocessor and
linker.
So it may work to only use it during linking but this may
cause subtle failure
on some platforms.
When writing FindThreads.cmake, it would be better to really
rewrite it and
use the common naming standards for cmake modules.
I'm hesitant to rewrite anything that works, especially if it works on
platforms I don't have access too. :)
Include library variables probably could be added if it can be done
in a safe way with the compile checks already in place.
Not sure on -pthread, we've never added it to our gcc command lines
before. Looking at the man page, it's only a compile flag under
IA-64, RS-6000, PPC, and SPARC. Would recommending people add it to
their compiler flags and only rely on the output of
${CMAKE_THREAD_LIBS_INIT} for linking be the right thing to do?
--
Philip Lowman
Hmm, don't know if the documentation is correct.
I tested this on Linux x86_64 (gcc 4.3) and on an old i686 (gcc 3.2). On
both systems, when I diff the output of 'gcc -E -dM' and 'gcc -E -dM
-pthread' I get '#define _REENTRANT 1'.
So, -pthread clearly defines an extra preprocessor variable.
Marcel Loose
___
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] add_subdirectory and build directory
Hi Pierre-Julien, You are right. You don't need add_dependencies() when specifying link dependencies using target_link_libraries(). The latter, BTW, is of course the preferred way to do this. Without an example of you CMakeLists.txt files, it's very hard to tell what, if anything, is going wrong. Regards, Marcel Loose. On Mon, 2009-09-14 at 16:28 +0200, Pierre-Julien Villoud wrote: Sorry I did not reply to you... I actually use the target_link_libraries and the add_dependencies which is useless if using the target_link_libraries (I think ?) So I really wonder why my objects are re-built... It's still a mystery for me ! Thanks again Pierre-Julien VILLOUD -Message d'origine- De : Marcel Loose [mailto:lo...@astron.nl] Envoyé : vendredi 11 septembre 2009 18:09 À : Pierre-Julien Villoud Cc : cmake@cmake.org Objet : Re: [CMake] add_subdirectory and build directory Hi Pierre-Julien, I think I see what the problem is. You didn't specify any dependencies. You mention that project A depends on B. But don't you actually mean that libA depends on libB? If that's the case you should add a target_link_libraries(libA libB) to the CMakeLists.txt file of project A. Anyway, you may want to post your CMakeLists.txt files, so that people can spot what you might be doing wrong. At the moment, I can only make some wild guesses. Best regards, Marcel Loose. On Fri, 2009-09-11 at 17:34 +0200, Pierre-Julien Villoud wrote: Hi and thanks for your answer... Here is the ouput : I'm building A : My CMakelists.txt is in C:/A -- Configuring done -- Generating done -- Build files have been written to: C:/A/Debug ==Building A== [ 0%] Built target CMake Scanning dependencies of target B [ 4%] Building CXX object C:/B/CMakeFiles/B.dir/B.cpp.obj Linking CXX static library C:\lib\libB.a [ 4%] Built target B Linking CXX shared module C:\bin\A.dll [100%] Built target A Then I'm building B : My CMakeLists.txt is in C:/B -- Configuring done -- Generating done -- Build files have been written to: C:/B/Debug ==Building B== [ 0%] Built target CMake Scanning dependencies of target B [100%] Building CXX object CMakeFiles/B.dir/B.cpp.obj Linking CXX static library C:\lib\libB.a [100%] Built target B Any clues ? @Michael : I did not look at your long and precise answer (thank you very much for it BTW) but it seems quite complicated !! How are you managing your dependencies ? Thank you for your help ! -Message d'origine- De : Marcel Loose [mailto:lo...@astron.nl] Envoyé : vendredi 11 septembre 2009 16:30 À : Pierre-Julien Villoud Cc : cmake@cmake.org Objet : Re: [CMake] add_subdirectory and build directory Hi Pierre-Julien, Are you sure it's rebuilding? CMake (or 'make' actually), prints a lot of messages Built target ... even if no compilation was needed. However, if you also see messages like Building ... then it is actually rebuilding. Without an example of the output of your build, it is hard to judge what, if anything, is going wrong. Best regards, Marcel Loose. On Fri, 2009-09-11 at 15:12 +0200, Pierre-Julien Villoud wrote: Hi everyone, After unsuccessfully looking for an answer on Google, I contact you. I have a question regarding the use of add_subdirectory. When a project A is depending on a project B, I add the following in A's CMakeLists.txt : Add_subdirectory(B Path/To/B/Build/Directory) It does build B before A. But when I build B in its build directory and I build A after, it builds B again whereas it should not since B is up to date. Anyone sees what's wrong ? Thanks in advance Pierre-Julien VILLOUD ___ 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 ___ 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
Re: [CMake] add_subdirectory and build directory
Aah, I see now what the problem really is. You're building in two different directories. So, you will end up with two versions of libMaths. That exactly explains the output you're seeing. * First, in directory Maths, you're building libMaths. * Next, in directory HelloMath, you're building both HelloMath and libMaths, the latter due to the link dependency. The library libmMaths is not up-to-date as you suggest; it hasn't been built yet! * Finally, in directory Math, you're building libMaths again, but now it's up-to-date, so nothing needs to be done. Best regards, Marcel Loose. On Tue, 2009-09-15 at 10:16 +0200, Pierre-Julien Villoud wrote: I found my problem Here are 2 CMakeLists.txt : === CMakeLists.txt : libMaths : #Minimum Cmake version required cmake_minimum_required(VERSION 2.6) add_library(Maths MathFuncsLib.cpp ) === === CMakeLists.txt : HelloMath : #Minimum Cmake version required cmake_minimum_required(VERSION 2.6) include_directories(../Math) link_directories(../Math) add_executable(HelloMath hellomath.cpp ) target_link_libraries(HelloMath Maths ) add_subdirectory(../Math ../Math) === My build process is the following : Cmake (...) make And it's the cmake call that causes the problem : In C:\Maths : Cmake -GMinGW Makefiles -DCMAKE_BUILD_TYPE=Release make = builds libMaths In C:\HelloMath : Cmake -GMinGW Makefiles -DCMAKE_BUILD_TYPE=Release make = builds HelloMath AND builds libMaths (whereas it's up to date) because of the cmake call. The following works : In C:\HelloMath : Cmake -GMinGW Makefiles -DCMAKE_BUILD_TYPE=Release make = builds HelloMath AND builds libMaths because of the cmake call. In C:\Maths : make = does not build libMaths since it's up to date. So I must try to remove the cmake call and it will be fine ! Sorry to have bothered you... Thanks ! Pierre-Julien VILLOUD -Message d'origine- De : Marcel Loose [mailto:lo...@astron.nl] Envoyé : mardi 15 septembre 2009 09:38 À : Pierre-Julien Villoud Cc : cmake@cmake.org Objet : RE: [CMake] add_subdirectory and build directory Hi Pierre-Julien, You are right. You don't need add_dependencies() when specifying link dependencies using target_link_libraries(). The latter, BTW, is of course the preferred way to do this. Without an example of you CMakeLists.txt files, it's very hard to tell what, if anything, is going wrong. Regards, Marcel Loose. On Mon, 2009-09-14 at 16:28 +0200, Pierre-Julien Villoud wrote: Sorry I did not reply to you... I actually use the target_link_libraries and the add_dependencies which is useless if using the target_link_libraries (I think ?) So I really wonder why my objects are re-built... It's still a mystery for me ! Thanks again Pierre-Julien VILLOUD -Message d'origine- De : Marcel Loose [mailto:lo...@astron.nl] Envoyé : vendredi 11 septembre 2009 18:09 À : Pierre-Julien Villoud Cc : cmake@cmake.org Objet : Re: [CMake] add_subdirectory and build directory Hi Pierre-Julien, I think I see what the problem is. You didn't specify any dependencies. You mention that project A depends on B. But don't you actually mean that libA depends on libB? If that's the case you should add a target_link_libraries(libA libB) to the CMakeLists.txt file of project A. Anyway, you may want to post your CMakeLists.txt files, so that people can spot what you might be doing wrong. At the moment, I can only make some wild guesses. Best regards, Marcel Loose. On Fri, 2009-09-11 at 17:34 +0200, Pierre-Julien Villoud wrote: Hi and thanks for your answer... Here is the ouput : I'm building A : My CMakelists.txt is in C:/A -- Configuring done -- Generating done -- Build files have been written to: C:/A/Debug ==Building A== [ 0%] Built target CMake Scanning dependencies of target B [ 4%] Building CXX object C:/B/CMakeFiles/B.dir/B.cpp.obj Linking CXX static library C:\lib\libB.a [ 4%] Built target B Linking CXX shared module C:\bin\A.dll [100%] Built target A Then I'm building B : My CMakeLists.txt is in C:/B -- Configuring done -- Generating done -- Build files have been written to: C:/B/Debug ==Building B== [ 0%] Built target CMake Scanning dependencies of target B [100%] Building CXX object CMakeFiles/B.dir/B.cpp.obj Linking CXX static library C:\lib\libB.a [100%] Built target B Any clues ? @Michael : I did not look at your long and precise answer (thank you very much for it BTW) but it seems quite complicated !! How are you managing your dependencies ? Thank you for your help
[CMake] Difficult 'make install' problem
Hi all, I am facing a difficult 'make install' problem. I'll try to explain my project setup. The main project consists of parts and subsystems. Parts contain source code; subsystems do not contain source code, but define a certain subset of all available parts. Here is a simplified version of my source code tree. main subsystems subsys_1 (depends on part_1b, part_2a) subsys_2 (depends on part_1a, part_1c, part_2b) part_1 part_1a part_1b (depends on part_1a) part_1c (depends on part_1a) part_2 part_2a (depends on part_1c) part_2b (depends on part_1b) Each leaf-directory contains a CMake project. The subsystems tree does not contain any source code; it merely contains CMakeLists.txt files that record the subsystem's dependencies. Only the part_* directories contain source code files. For each project, a custom target is defined with the same name as that of the project. That way, you can easily define project dependencies (which may reach a bit further than just library dependencies). With this setup, it is straightforward to build, say, subsys_1. This will trigger a build of the (sub)projects part_1a, part_1b, part_1c, and part_2a. There's one caveat, though: you can only build a subsystem from the top-level build directory! When typing 'make' in the subsystems/subsys_1 directory, nothing happens. This is different from the behaviour you see when typing 'make' in, e.g., the directory part_1/part_1c. This isn't a big deal when simply building the target subsys_1. However, it is a problem if you want to install subsys_1, where installing means, installing all the products (i.e. libraries, binaries, etc.) that subsys_1 consists of. What I would like is that, if I type 'make install' in the directory subsystems/subsys_1, the result would be the same as if I had subsequently typed 'make install' in the directories part_1/part_1a, part_1/part_1b, part_1/part_1c, and part_2/part_2a. Does anyone know how I could achieve this in CMake? Best regards, Marcel Loose. ___ 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] Make project name a target
Hi all, I was wondering whether it's a good idea to make the project name (i.e. the argument to the 'project' command) a target. Rationale: I have a project that consists of numerous sub-projects and I would like to be able to build some of these separately. Wrapping the 'project' command in a macro is not a solution, because AFAIK CMake *must* see a 'project' command in the top-level CMakeLists.txt file; a 'myproject' macro, wrapping the 'project' command, will not do. Any comments? Best regards, Marcel Loose. ___ 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] Make project name a target
Hi David, I don't see the exact difference between (1) and (2). And yes, I was thinking of using the project name as a target. You are right, that it might cause clashes with existing projects, though :-( We use the convention that project names are always capitalized, so we usually don't run into problems. Is there a nifty trick to wrap the 'project' command? I never succeeded in doing that. Best regards, Marcel Loose. On Fri, 2009-09-11 at 07:09 -0400, David Cole wrote: When you say make the project name a target what do you mean by that? (1) internally create a CMake target with the given name? (2) create a makefile target with that name that builds all the cmake targets in that cmake project? (3) something else? (1) is probably not feasible for most folks -- because many people use the same name for their PROJECT statement and the main library or executable for that project which is already a cmake target (and a makefile target) with that name. On Fri, Sep 11, 2009 at 3:51 AM, Marcel Loose lo...@astron.nl wrote: Hi all, I was wondering whether it's a good idea to make the project name (i.e. the argument to the 'project' command) a target. Rationale: I have a project that consists of numerous sub-projects and I would like to be able to build some of these separately. Wrapping the 'project' command in a macro is not a solution, because AFAIK CMake *must* see a 'project' command in the top-level CMakeLists.txt file; a 'myproject' macro, wrapping the 'project' command, will not do. Any comments? Best regards, Marcel Loose. ___ 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] add_subdirectory and build directory
Hi Pierre-Julien, Are you sure it's rebuilding? CMake (or 'make' actually), prints a lot of messages Built target ... even if no compilation was needed. However, if you also see messages like Building ... then it is actually rebuilding. Without an example of the output of your build, it is hard to judge what, if anything, is going wrong. Best regards, Marcel Loose. On Fri, 2009-09-11 at 15:12 +0200, Pierre-Julien Villoud wrote: Hi everyone, After unsuccessfully looking for an answer on Google, I contact you. I have a question regarding the use of add_subdirectory. When a project A is depending on a project B, I add the following in As CMakeLists.txt : Add_subdirectory(B Path/To/B/Build/Directory) It does build B before A. But when I build B in its build directory and I build A after, it builds B again whereas it should not since B is up to date. Anyone sees whats wrong ? Thanks in advance Pierre-Julien VILLOUD ___ 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] add_subdirectory and build directory
Hi Pierre-Julien, I think I see what the problem is. You didn't specify any dependencies. You mention that project A depends on B. But don't you actually mean that libA depends on libB? If that's the case you should add a target_link_libraries(libA libB) to the CMakeLists.txt file of project A. Anyway, you may want to post your CMakeLists.txt files, so that people can spot what you might be doing wrong. At the moment, I can only make some wild guesses. Best regards, Marcel Loose. On Fri, 2009-09-11 at 17:34 +0200, Pierre-Julien Villoud wrote: Hi and thanks for your answer... Here is the ouput : I'm building A : My CMakelists.txt is in C:/A -- Configuring done -- Generating done -- Build files have been written to: C:/A/Debug ==Building A== [ 0%] Built target CMake Scanning dependencies of target B [ 4%] Building CXX object C:/B/CMakeFiles/B.dir/B.cpp.obj Linking CXX static library C:\lib\libB.a [ 4%] Built target B Linking CXX shared module C:\bin\A.dll [100%] Built target A Then I'm building B : My CMakeLists.txt is in C:/B -- Configuring done -- Generating done -- Build files have been written to: C:/B/Debug ==Building B== [ 0%] Built target CMake Scanning dependencies of target B [100%] Building CXX object CMakeFiles/B.dir/B.cpp.obj Linking CXX static library C:\lib\libB.a [100%] Built target B Any clues ? @Michael : I did not look at your long and precise answer (thank you very much for it BTW) but it seems quite complicated !! How are you managing your dependencies ? Thank you for your help ! -Message d'origine- De : Marcel Loose [mailto:lo...@astron.nl] Envoyé : vendredi 11 septembre 2009 16:30 À : Pierre-Julien Villoud Cc : cmake@cmake.org Objet : Re: [CMake] add_subdirectory and build directory Hi Pierre-Julien, Are you sure it's rebuilding? CMake (or 'make' actually), prints a lot of messages Built target ... even if no compilation was needed. However, if you also see messages like Building ... then it is actually rebuilding. Without an example of the output of your build, it is hard to judge what, if anything, is going wrong. Best regards, Marcel Loose. On Fri, 2009-09-11 at 15:12 +0200, Pierre-Julien Villoud wrote: Hi everyone, After unsuccessfully looking for an answer on Google, I contact you. I have a question regarding the use of add_subdirectory. When a project A is depending on a project B, I add the following in A's CMakeLists.txt : Add_subdirectory(B Path/To/B/Build/Directory) It does build B before A. But when I build B in its build directory and I build A after, it builds B again whereas it should not since B is up to date. Anyone sees what's wrong ? Thanks in advance Pierre-Julien VILLOUD ___ 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 ___ 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] Make project name a target
Hi JeDi,
If you look carefully, you will notice that, when you create a project
through a macro (e.g. myproject), CMake will create a dummy project
named Project and assume you're using C and C++ as default languages.
Note that I intentionally chose a non-supported language, CPP, in the
example below. Look at the line printing PROJECT_NAME. But you'll notice
a significant difference in output anyway.
Best regards,
Marcel Loose.
CMakeLists.txt with direct call of project() command:
$ pwd
/home/loose/work/cmake/build
$ cat ../proj/CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
message(STATUS PROJECT_NAME = ${PROJECT_NAME})
project(main CPP)
$ cmake -DCMAKE_MODULE_PATH:PATH=$HOME/work/cmake/proj ../proj
-- PROJECT_NAME =
CMake Error: Error required internal CMake variable not set, cmake may
be not be built correctly.
Missing variable is:
CMAKE_CPP_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may
be not be built correctly.
Missing variable is:
CMAKE_CPP_COMPILER
CMake Error: Could not find cmake module
file:/home/loose/work/cmake/build/CMakeFiles/CMakeCPPCompiler.cmake
CMake Error: Could not find cmake module file:CMakeCPPInformation.cmake
CMake Error: CMAKE_CPP_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
CMakeLists.txt with call of project() through myproject macro:
-
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
message(STATUS PROJECT_NAME = ${PROJECT_NAME})
include(myproject)
myproject(main CPP)
$ cmake -DCMAKE_MODULE_PATH:PATH=$HOME/work/cmake/proj ../proj
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- PROJECT_NAME = Project
CMake Error: Error required internal CMake variable not set, cmake may
be not be built correctly.
Missing variable is:
CMAKE_CPP_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may
be not be built correctly.
Missing variable is:
CMAKE_CPP_COMPILER
CMake Error: Could not find cmake module
file:/home/loose/work/cmake/build/CMakeFiles/CMakeCPPCompiler.cmake
CMake Error: Could not find cmake module file:CMakeCPPInformation.cmake
CMake Error: CMAKE_CPP_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
On Fri, 2009-09-11 at 16:34 +0200, Jeroen Dierckx wrote:
On Fri, Sep 11, 2009 at 4:22 PM, Marcel Loose lo...@astron.nl wrote:
Hi David,
I don't see the exact difference between (1) and (2). And yes, I was
thinking of using the project name as a target. You are right, that it
might cause clashes with existing projects, though :-(
We use the convention that project names are always capitalized, so we
usually don't run into problems.
Is there a nifty trick to wrap the 'project' command? I never succeeded
in doing that.
I did this once inside a macro, and that should work as expected. The
code of the macro should behave just as if it was copy-pasted to the
place where you call the macro, so scope and such will be that of the
place where you call it.
Greetings,
JeDi
Best regards,
Marcel Loose.
On Fri, 2009-09-11 at 07:09 -0400, David Cole wrote:
When you say make the project name a target what do you mean by
that?
(1) internally create a CMake target with the given name?
(2) create a makefile target with that name that builds all the cmake
targets in that cmake project?
(3) something else?
(1) is probably not feasible for most folks -- because many people use
the same name for their PROJECT statement and the main library or
executable for that project which is already a cmake target (and a
makefile target) with that name.
On Fri, Sep 11, 2009 at 3:51 AM, Marcel Loose lo...@astron.nl wrote:
Hi all,
I was wondering whether it's a good idea to make the project
name (i.e.
the argument to the 'project' command) a target.
Rationale: I have a project that consists of numerous
sub-projects and I
would like to be able to build some of these separately.
Wrapping the
'project' command in a macro is not a solution, because AFAIK
CMake
*must* see a 'project' command in the top-level CMakeLists.txt
file; a
'myproject' macro, wrapping the 'project' command, will not
do.
Any comments?
Best regards,
Marcel Loose
Re: [CMake] FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH
On Mon, 2009-09-07 at 22:01 +0200, Alexander Neundorf wrote: On Monday 07 September 2009, Marcel Loose wrote: Hi all, In fact the subject line says it all. To be compliant with the naming conventions proposed in the Modules/readme.txt file, FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH. To avoid breaking existing software, it would be best to simply just add a definition for PYTHON_INCLUDE_DIR. please put it in the bug tracker, ideally together with a patch :-) Alex It's in the tracker (issue #9508). Regards, Marcel Loose ___ 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] FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH
On Wed, 2009-09-09 at 09:26 +0200, Marcel Loose wrote: On Mon, 2009-09-07 at 22:01 +0200, Alexander Neundorf wrote: On Monday 07 September 2009, Marcel Loose wrote: Hi all, In fact the subject line says it all. To be compliant with the naming conventions proposed in the Modules/readme.txt file, FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH. To avoid breaking existing software, it would be best to simply just add a definition for PYTHON_INCLUDE_DIR. please put it in the bug tracker, ideally together with a patch :-) Alex It's in the tracker (issue #9508). Regards, Marcel Loose Along with a patch. Marcel ___ 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] Let CMake convert CMAKE_MODULE_PATH to absolute path
On Fri, 2009-09-04 at 21:48 +0200, Alexander Neundorf wrote: On Tuesday 25 August 2009, Marcel Loose wrote: Hi all, I've been bitten by this more than once. When specifying a module path on the command line, you must not forget to make this an absolute path, otherwise calling a macro from a (CMakeLists.txt file in a) subdirectory will fail. Would it be an idea to let CMake always convert a relative module path to an absolute path, before putting it in the cache? Hmm, that would be special handling for that one variable. I guess it should be interpreted as relative to CMAKE_BINARY_DIR ? Wouldn't it be confusing if this one variable would be handled differently than all others ? Alex Well, I don't know how many variables might be affected by this. Maybe it's breaking more things that it's supposed to fix. I was just wondering, because I ran into this problem more than once. Besides, you do not have to specify the absolute path to the CMakeLists.txt file you're feeding to cmake (I agree, though, that that's not exactly the same thing.) Best regards, Marcel Loose. ___ 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] FindThreads: the odd one out?
On Fri, 2009-09-04 at 21:55 +0200, Alexander Neundorf wrote: On Sunday 30 August 2009, Philip Lowman wrote: On Fri, Aug 28, 2009 at 4:29 AM, Marcel Loose lo...@astron.nl wrote: Hi all, Up till now I've been using the not officially supported and released FindPthreads.cmake macro to check for the presence of pthreads. However, the maintainer of that macro wrote (a comment in Mantis) that he would drop support for FindPthreads in favor of the more general and officially supported FindThreads.cmake macro. However, I have some difficulty understandig how to properly use FindThreads.cmake. Contrary to most FindXXX macros it does not set THREADS_INCLUDE_DIR and THREADS_LIBRARY. It does set some *_INIT variables, but I thought that *_INIT variables were only used by CMake itself to preset compiler and linker flags, and that these were not to be used outside. Could someone shed a light on this? I could also use some illumination on this. I get that you're supposed to use CMAKE_THREAD_LIBS_INIT with target_link_libraries() because libpthread isn't always called libpthread, but it also looks like CMAKE_THREAD_LIBS_INIT can also be set to -pthread in the event the system doesn't have a pthread library and it's supposed to be a compile definition thing...??? If so, why one variable instead of two? Also what systems does this happen on? I'm not sure if anyone is actually using the pthreads-win32 stuff I wrote This one: http://sourceware.org/pthreads-win32/ ? 3 years ago I was using it (to make that software easily portable). I also think FindThreads.cmake is somewhat strange, doesn't it basically load the thread library of the current platform ? That means that you get different APIs on different platforms and therefor need different code ? Alex It turns out there different versions of the FindPthreads macro lying around :-(. I was refering to this http://www.vtk.org/Bug/file_download.php?file_id=2282type=bug version, which can be found here http://www.vtk.org/Bug/view.php?id=9074 Best regards, Marcel Loose. ___ 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] FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH
Hi all, In fact the subject line says it all. To be compliant with the naming conventions proposed in the Modules/readme.txt file, FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH. To avoid breaking existing software, it would be best to simply just add a definition for PYTHON_INCLUDE_DIR. Best regards, Marcel Loose. ___ 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] Howto byte-compile python files during install
Hi all, What is the best way to make sure that Python files are byte-compiled at install time? I couldn't find a pre- or post-install hook in the install() command. Best regards, Marcel Loose. ___ 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: generating CTest tests
Hi John, How do you get these CPU times printed. I've never seen these before. Or is that a Windows thingy, that doesn't work on Linux? Best regards, Marcel Loose. On Fri, 2009-08-28 at 14:14 -0400, John Drescher wrote: 1Performing Post-Build Event... 1Start processing tests 1Test project X:/32Bit/VC.80/Qt/QtBasicUtils 1 1/ 48 Testing FileCMD0 . Passed0.55 sec 1 2/ 48 Testing FileCMD1 . Passed1.58 sec 1 3/ 48 Testing Test0 Passed0.17 sec 1 4/ 48 Testing Test1 Passed0.16 sec ... 1100% tests passed, 0 tests failed out of 48 1Total CPU time = 11.78 sec 1Build log was saved at file://x:\32Bit\VC.80\Qt\QtBasicUtils\RUN_TESTS.dir\RelWithDebInfo\BuildLog.htm 1RUN_TESTS - 0 error(s), 0 warning(s) == Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped == ___ 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] FindThreads: the odd one out?
Hi all, Up till now I've been using the not officially supported and released FindPthreads.cmake macro to check for the presence of pthreads. However, the maintainer of that macro wrote (a comment in Mantis) that he would drop support for FindPthreads in favor of the more general and officially supported FindThreads.cmake macro. However, I have some difficulty understandig how to properly use FindThreads.cmake. Contrary to most FindXXX macros it does not set THREADS_INCLUDE_DIR and THREADS_LIBRARY. It does set some *_INIT variables, but I thought that *_INIT variables were only used by CMake itself to preset compiler and linker flags, and that these were not to be used outside. Could someone shed a light on this? Best regards, Marcel Loose. ___ 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 build 2 targets from the same source, differing in -D_SWITCHES_ only
Hi Eike,
I think the only safe and reliable way to do this is create several
build directories, e.g. build/type_1 and build/type_2.
When running cmake in build/type_1, you should add -D_TYPE1_ to the
preprocessor flags; same for build/type_2.
Best regards,
Marcel Loose.
On Thu, 2009-08-27 at 12:28 +0200, Eike Kroemer wrote:
Hi there,
in the hope of achieving platform independence of my plain-C project
I have started looking into CMake, trying to duplicate what my
manually created makefiles do.
A minimalistic description of my problem is the following:
* I have 2 executable targets
* both having the same main program source MAIN/main.c
* both linking to a library libvehicle.a that is built from the same
set of sources, e.g. VEHICLE/read_hydrodynamic_coeffs.c
The difference between both targets is a compiler definition
-D_TYPE1_ or -D_TYPE2_ that is used in the sourcecode, e.g.
hydro_par_t read_hydrodynamic_coeffs(sys_par_t sys_par)
{
#if defined(_TYPE1_)
return(read_hydrodynamic_coeffs_type1(sys_par));
#elif defined(_TYPE2_)
return(read_hydrodynamic_coeffs_type2(sys_par));
#endif
}
So the in both cases the library libvehicle.a will contain a
function read_hydrodynamic_coeffs but the actual content of this
function will be different.
[
In realiter it's more complicated because there are more
executables and combinations of several switches, so I really don't
want to change the sources.
]
What I've done so far is
* in the main CMakeLists.txt:
add_subdirectory(CMakeTargets/sim_type1)
* in CMakeTargets/sim_type1/CMakeLists.txt:
add_definitions(-D_TYPE1_)
include_directories(../../VEHICLE/INCLUDE)
add_subdirectory(../../VEHICLE VEHICLE)
add_executable(sim_type1 ../../MAIN/main)
target_link_libraries(sim_type1 vehicle)
* in CMakeTargets/VEHICLE/CMakeLists.txt:
set(SRC read_hydrodynamic_coeffs)
set(SRC ${SRC} read_hydrodynamic_coeffs_type1)
set(SRC ${SRC} read_hydrodynamic_coeffs_type2)
add_library(vehicle ${SRC})
For one target only this gives a executable
CMakeTargets/sim_type1/sim_type1 that is working as expected.
As specified by
add_subdirectory(../../VEHICLE VEHICLE),
object file and library are created locally:
./CMakeTargets/sim_type1/VEHICLE/CMakeFiles/vehicle.dir/read_hydrodynamic_coeffs.c.o
./CMakeTargets/sim_type1/VEHICLE/libvehicle.a
But as soon as I try to
add_subdirectory(CMakeTargets/sim_type2)
[rest as above, only 1-2]
I get an error message
add_library cannot create target vehicle because another target with the
same name already exists. The existing target is a static library created
in source directory ./VEHICLE. See documentation
for policy CMP0002 for more details.
Trying to cheat with cmake_policy(SET CMP0002 OLD) I can compile
both executables but they are messed up, obviously trying to execute
read_hydrodynamic_coeffs for the wrong type.
So, how do I define a set of executable make targets, differing only
in the -D_defines_ that are used to build all of the source needed?
Thanks in advance,
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
[CMake] Let CMake convert CMAKE_MODULE_PATH to absolute path
Hi all, I've been bitten by this more than once. When specifying a module path on the command line, you must not forget to make this an absolute path, otherwise calling a macro from a (CMakeLists.txt file in a) subdirectory will fail. Would it be an idea to let CMake always convert a relative module path to an absolute path, before putting it in the cache? Best regards, Marcel Loose. ___ 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] add_custom_command using CMAKE_CXX_FLAGS
Hi John,
I took a different approach to the problem you're describing.
Following the instructions on the Wiki
(http://www.cmake.org/Wiki/CMake/Assembler), I've written the three
required *ASM*.cmake files.
In the CMakeASM-fooInformation.cmake file I've redefined the rule to
build .S files.
set(CMAKE_ASM${ASM_DIALECT}_SOURCE_FILE_EXTENSIONS S)
set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT CMAKE_ASM
${ASM_DIALECT}_COMPILER DEFINES FLAGS -c -o OBJECT SOURCE)
set(CMAKE_ASM${ASM_DIALECT}_LINK_EXECUTABLE CMAKE_ASM
${ASM_DIALECT}_COMPILER FLAGS LINK_FLAGS OBJECTS -o TARGET
LINK_LIBRARIES)
The trick is in the second line; there I've added DEFINES so that any
relevant preprocessor variables will actually be passed when invoking
the compiler.
Furthermore, you need to make sure that the variable
CMAKE_ASM-foo_COMPILER points to your C or C++ compiler. This variable
must be set before you use the enable_language(foo) command.
Hope this helps.
Best regards,
Marcel Loose.
On Mon, 2009-08-24 at 13:38 -0400, John Smith wrote:
On Aug 24, 2009, at 12:48 PM, Tyler Roscoe wrote:
On Sun, Aug 23, 2009 at 09:03:22PM -0400, John Smith wrote:
I am using the following test case in an attempt to add a custom
command to build an assembly file. The assembly file should be
compiled with the C++ compiler driver (which in turn should invoke
the
assembler after pre-processing), and I am building up a
CMAKE_CXX_FLAGS variable from separate pieces:
I think you can just hand your .S files to add_library(). Did you try
searching the ML archives or google for how to handle assembler files
with CMake?
I have tried doing that. However, the net end result is that I get a
rule that invokes the assembler on the assembly source file. My top-
level assembly source file is a shell containing a bunch of platform-
specific conditionals, which in turn guard include directives for
platform-specific assembly source files. Thus, I want to have the C++
compiler driver compile the top-level file; the compiler driver would
first preprocess the include directives and then invoke the assembler
on the resulting translation unit.
An example of such a technique is here:
http://svn.apache.org/viewvc/stdcxx/trunk/src/atomic.s?revision=704153
set(CMAKE_CXX_FLAGS -m32)
When you do this, you clobber the pre-existing value of
CMAKE_CXX_FLAGS,
which has some defaults that are probably useful for your platform.
Are
you sure this is what you want?
Poorly chosen example, my bad. The point was to show how a variable is
constructed in my CMakeLists.txt and how it ends up being used.
[...]
add_library(test SHARED foo.cpp bar.S)
Yeah I think you're overthinking this. Look for some CMake examples
that
use assembler and go from there.
Most surely I am over-thinking it. After more local testing I think I
understand how variables are processed in the generation of commands.
I started from the command include_directories which actually builds a
*list* of tokens, each an include directory to be used in (a) makefile
rule. I noticed that using such a list as ARGS to ADD_CUSTOM_COMMAND
results in the splitting of the list in separate tokens, i.e.:
set(FOO a b c)
ADD_CUSTOM_COMMAND(...
ARGS ${FOO}
...)
ends up in a rule like:
CMD a b c ...
However, strings set up as:
set (FOO a b c)
end up in the rule as:
CMD a\ b\ c ...
Therefore, I conclude that ARGS require lists, not strings of
concatenated, space-separated options. Am I right in this?
Thanks for the help.
-J
___
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] Possible to clean files of one target library only?
On Wed, 2009-08-19 at 11:02 -0700, Tyler Roscoe wrote: On Wed, Aug 19, 2009 at 11:54:18AM -0600, Timothy M. Shead wrote: If you are using CMake to generate makefiles, you can run make clean in a subdirectory of your build tree, and make will only remove the files for that directory - you can use this to do library-specific cleaning, provided that you've organized your sources so each library has its own directory. I do not see this behavior. make clean gets rid of object files and libraries for the project where I run make clean and for all that project's dependencies. All my projects have their own source and binary directories. tyler Hmm, just a guess (I haven't tried it out). Maybe it's working for Tim because he has a hierarchy of projects. I have a big project that is subdivided into (sub)projects. As a result, the build directory of a sub-project is a subdirectory of the build directory of the top-level project. When I go to the build directory of a given sub-project and issue 'make clean', only the files for that sub-project are deleted, not those of its parent project. So, maybe this only works if you've divided your (big) project into sub-projects. Best regards, Marcel Loose. ___ 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] Tests without CTest (was Re: Custom target bug...)
On Wed, 2009-08-19 at 21:20 -0700, Tim Kientzle wrote: David Cole wrote: You're using incorrect arguments as DEPENDS. Things that follow DEPENDS should be full path file names... not cmake target names. Okay, I think I finally figured out how to do what I need (which is, of course, to run custom test code without using CTest): # CMakeLists.txt PROJECT(foobar C) ADD_CUSTOM_TARGET(run_all_tests) ADD_SUBDIRECTORY(foo) # foo_test/CMakeLists.txt ADD_EXECUTABLE(foo_test foo_test.c) ADD_CUSTOM_TARGET(run_foo_test COMMAND foo_test) ADD_DEPENDENCIES(run_all_tests run_foo_test) With this, I can easily add other subdirectories with their own test code and build up run_all_tests conditionally depending on which modules are enabled. I recall someone else asked this list recently about using DejaGNU tests with CMake; I believe this approach should work for that as well. Cheers, Tim Hi Tim, Did you read this http://www.cmake.org/Wiki/CMakeEmulateMakeCheck Wiki page and this http://www.mail-archive.com/cmake@cmake.org/msg19936.html thread on the mailing list? Best regards, Marcel Loose. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Digest, Vol 64, Issue 50
Hi Steve, Unless you're using make's -j option, there should not be any concurrency issues. Check the command line and your MAKEFLAGS variable. Best regards, Marcel Loose. On Wed, 2009-08-19 at 17:31 -0700, Steve Mathers wrote: Hi Michael. that option is what I am already doing, which is why I am confused. 'make' from the terminal works great, 'make' from eclipse craps out. I tried running eclipse from the terminal, and it didnt help. I noticed something else strange here is the output from eclipse once I have done a make from the terminal, then done a build in eclipse (essentially nothing to do, so eclipse doesnt bomb) Build of configuration Linux GCC for project mdc make VERBOSE=1 -d GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i686-redhat-linux-gnu Reading makefiles... Reading makefile `Makefile'... Updating makefiles Considering target file `Makefile'. Looking for an implicit rule for `Makefile'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile,v'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `RCS/Makefile,v'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `RCS/Makefile'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `s.Makefile'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `SCCS/s.Makefile'. No implicit rule found for `Makefile'. Finished prerequisites of target file `Makefile'. No need to remake target `Makefile'. Updating goal targets etc NOW, here is the output having modfiied foo so that it needs to be rebuilt. (one run) Build of configuration Linux GCC for project mdc make VERBOSE=1 -d GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i686-redhat-linux-gnu Reading makefiles... Reading makefile `Makefile'... Updating makefiles Considering target file `Makefile'. Looking for an implicit rule for `Makefile'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile,v'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `RCS/Makefile,v'. make[2]: *** [CMakeFiles/appmonitor.dir/AppMonitor/foo.cpp.o] Error 1 Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `RCS/Makefile'. make[1]: *** [CMakeFiles/appmonitor.dir/all] Error 2 make: *** [all] Error 2 Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `s.Makefile'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `SCCS/s.Makefile'. No implicit rule found for `Makefile'. -- and here is the output of a second run... notice how the errors are reported in different stages... is that because there is some kind of concurrnecy thing going on with the build or what? Is it important? I have no clue about this, but it seems to me that eclipse is alomst trying to compete with the makefile if that makes sense? I dont know... Build of configuration Linux GCC for project mdc make VERBOSE=1 -d GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A make[2]: *** [CMakeFiles/appmonitor.dir/AppMonitor/foo.cpp.o] Error 1 make[1]: *** [CMakeFiles/appmonitor.dir/all] Error 2 make: *** [all] Error 2 PARTICULAR PURPOSE. This program built for i686-redhat-linux-gnu Reading makefiles... Reading makefile `Makefile'... Updating makefiles Considering target file `Makefile'. Looking for an implicit rule for `Makefile'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile,v'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `RCS/Makefile,v'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `RCS/Makefile'. Trying pattern rule with stem `Makefile'. - Original Message Message: 4 Date: Wed, 19 Aug 2009 09:56:35 -0400 From: Michael Jackson Subject: Re: [CMake] eclipse-cmake bug - more info To: Cmake Mailing List Message-ID: 418516b5-1a33-4599-93b9-8752fc2da...@bluequartz.net Content-Type
[CMake] CMake Python support
Hi all, Would it be worthwhile to add Python as a valid language to the project() method? Or is it better to use the currently available FindPython-like scripts. My reason for asking is that oftentimes you'd like to byte-compile Python source and install these byte-compiled files along with the Python sources. If Python were a fully supported programming language, then you could write the CMakeLists.txt files more or less the same way as for other languages (e.g., like Java). It's just a thought, and maybe I'm overlooking all kinds of potential pitfalls. Best regards, Marcel Loose. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Python support
Ah thanks, I didn't know that byte code is incompatible between Python releases. That's definitely a pitfall ;-). I agree that, in that case, it's better to let the installer handle byte compilation. So, in short, I can do with the existing FindPython* scripts, I guess? Thanks for your prompt reply. Best regards, Marcel Loose. On Wed, 2009-08-19 at 10:02 +0200, Hendrik Sattler wrote: Zitat von Marcel Loose lo...@astron.nl: Would it be worthwhile to add Python as a valid language to the project() method? Or is it better to use the currently available FindPython-like scripts. My reason for asking is that oftentimes you'd like to byte-compile Python source and install these byte-compiled files along with the Python sources. If Python were a fully supported programming language, then you could write the CMakeLists.txt files more or less the same way as for other languages (e.g., like Java). It's just a thought, and maybe I'm overlooking all kinds of potential pitfalls. Citing from http://effbot.org/zone/python-compile.htm: Python?s byte code is portable between platforms, but not necessarily between Python releases. Unless your python module is for only one specific version or you know the python interpreter version on all installation targets, you better leave it up to the installer to compile the module (the page shows trivial code in python to do this). Something different would be to get complete application binaries. However, that somehow defeats one purpose of using Python. HS ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Python support
Hi Philip, I guess Python 2.x will be around for some time, before Python 3 really becomes mainstream. So I think it should be possible to select a 2.x version, even if 3.x is available. Best regards, Marcel Loose. On Wed, 2009-08-19 at 08:34 -0400, Philip Lowman wrote: Speaking of the existing FindPython* scripts they do not support v3.0 yet. Is there a need to maintain support for picking 2.x if two versions of python are installed? On Wed, Aug 19, 2009 at 4:15 AM, Marcel Loose lo...@astron.nl wrote: Ah thanks, I didn't know that byte code is incompatible between Python releases. That's definitely a pitfall ;-). I agree that, in that case, it's better to let the installer handle byte compilation. So, in short, I can do with the existing FindPython* scripts, I guess? Thanks for your prompt reply. Best regards, Marcel Loose. On Wed, 2009-08-19 at 10:02 +0200, Hendrik Sattler wrote: Zitat von Marcel Loose lo...@astron.nl: Would it be worthwhile to add Python as a valid language to the project() method? Or is it better to use the currently available FindPython-like scripts. My reason for asking is that oftentimes you'd like to byte-compile Python source and install these byte-compiled files along with the Python sources. If Python were a fully supported programming language, then you could write the CMakeLists.txt files more or less the same way as for other languages (e.g., like Java). It's just a thought, and maybe I'm overlooking all kinds of potential pitfalls. Citing from http://effbot.org/zone/python-compile.htm: Python?s byte code is portable between platforms, but not necessarily between Python releases. Unless your python module is for only one specific version or you know the python interpreter version on all installation targets, you better leave it up to the installer to compile the module (the page shows trivial code in python to do this). Something different would be to get complete application binaries. However, that somehow defeats one purpose of using Python. HS ___ 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 -- Philip Lowman ___ 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] Useful feature: join_arguments() ?
Hi all, I was wondering whether it would be useful if join_arguments() were added to CMake (not as a macro, but as a built-in command), where join_arguments() does the oppositie of separate_arguments(); i.e. create a space separated string of the elements of a list. I know that several people have brewn their join_arguments() macro (or whatever they called it) in the past, and so did I. But it feels like such a fundamental operation that I think it deserves to be a built-in command. Best regards, Marcel Loose. ___ 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 pass -D options when compiling assembly files using gcc?
On Fri, 2009-07-24 at 22:16 +0200, Alexander Neundorf wrote:
On Monday 13 July 2009, Michael Wild wrote:
On 13. Jul, 2009, at 10:28, Eric Noulard wrote:
2009/7/12 Marcel Loose lo...@astron.nl:
Hi Eric,
Thanks, I'll try that tomorrow. Another option that occurred to me
today
is that, since I'm using gcc to preprocess and compile the assembly
sources, I might add .S as source file extension to
CMAKE_C_SOURCE_FILE_EXTENSIONS. Any idea if that might work?
I really don't know.
Like I said before I have no experience with ASM file and CMake
nor the definition of a new compiler variant with CMake.
Once you have tried a little more, I'd rather let CMake developer
or CMake user with more expeperience in the field
answer that one :-)
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
Hi
I think I remember once having seen that for such a thing the LANGUAGE
property on the .S files was being set to C. Might want to give that a
shot...
set(ASM_SRCS foo.S bar.S)
set_source_files_properties(${ASM_SRCS} PROPERTIES LANGUAGE C)
That's a bit ugly but it should do what you want.
Hi Alex,
Sorry for the late reply; holidays :-)
I think it's this bug: http://public.kitware.com/Bug/view.php?id=8392
and I'm not completely sure how to fix it.
Should I add a CMakeASM-GCCInformation.cmake, and use that if the extension
is .S ? (...and set it up so that it keeps the definitions).
Yes, that bug covers exactly what I meant.
Do other C compilers also support compiling assembler files or is this only
gcc ?
Alex
___
Best regards,
Marcel Loose.
___
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] How to catch CMake Error get_directory_property
Hi all, Is there a way to catch the CMake Error 'get_directory_property' when requesting a property from a directory that has not yet been processed by CMake. I need to do this, because, in my situation, it is not an error if one or more directories are not present (i.e. checked out). I would like get_directory_property() to return FALSE or NOTFOUND when it cannot find the requested directory, so that I can take appropriate action myself. Is that somehow possible? Best regards, Marcel Loose. ___ 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] Globbing expression
Hi Arnaud, You can't trigger the FILE(GLOB...) command during or prior to compilation or linking. The FILE(GLOB...) is executed by CMake, when CMake runs. The only way I can think of doing this is, indeed, to create a custom command and invoke some kind of globbing command (be it a shell script, you name it). I certainly do NOT recommend this!! For one, because glob cannot match names of libraries that have not yet been built, because the files don't yet exist! If you've got your dependencies set up correctly, then you'll never run into the problem of the need to link against a library that's not yet built. Just use target_link_libraries() judiciously. Best regards, Marcel Loose. On Mon, 2009-07-13 at 14:08 +0200, Arnaud Devalkeneer wrote: Thanks a lot Marcel. Another should be : - make a second GLOB expression gathering all libraries you do not need - make a LIST( REMOVE_ITEM FIRST_GLOB_RESULT SECOND_BLOG_RESULT) but I suspect your solution is much efficient... One additionnal question : do you know how to trigger the GLOB command just before a link target handling. Because in my case, the GLOB command is running at the beginning of the compilation process, regardless the fact that I need to link to some .so's that have not been built yet. Is a custom target is a right way? Thanks again, Arnaud. On Mon, Jul 13, 2009 at 10:58 AM, Marcel Loose lo...@astron.nl wrote: Hi Arnaud, Your mixing globbing with regular expressions. AFAIK it is not possible to do this with one statement. I would just glob for all *.so files and then use string(REGEX REPLACE ...) to replace occurrences of '^libA.* \.so' with an empty string. Best regards, Marcel Loose. On Mon, 2009-07-13 at 10:43 +0200, Arnaud Devalkeneer wrote: Hello everybody, I would like to know if there exists a way to find all files in a directory with a custom file extension (e.g. *.so) except files beginning by a custom string (here libA). For example I am using the line : FILE( GLOB RESULT path/[^libA]*.so ) but the RESULT variable remains empty. Of cource I am sure of *.so files existance in the path. Has anybody already tried to glob files in a directory, excluding some file name patterns? Thank you in advance for your help. Enjoy Cmake, Arnaud. ___ 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] CMAKE_FIND_ROOT_PATH and cross-compilation
Hi all, Is there a way to globally set a variable or property that forces each find_xxx() command to only use CMAKE_FIND_ROOT_PATH when searching for files? The reason I'm asking this is that I'm getting errors like this: Cannot generate a safe runtime search path for target getparsetvalue because files in some directories may conflict with libraries in implicit directories: runtime library [libz.so.1] in /usr/lib may be hidden by files in: /bgsys/drivers/ppcfloor/linux/OS/usr/lib Some of these libraries may not be found correctly. I suspect it has to do with find_xxx() not only searching in CMAKE_FIND_ROOT_PATH but also in system directories. Now I know that you can add ONLY_CMAKE_FIND_ROOT_PATH to a find_xxx() option. However, I only need this when cross-compiling. In the documentation I saw a hint about CMAKE_FIND_ROOT_PATH_MODE_XXX, but I couldn't find any more info on that. Is this the variable I'm looking for? And if so, is it a boolean? Best regards, Marcel Loose. ___ 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] Querying global property in FindXXX.cmake: good or bad?
Hi all, I was wondering whether it is good or bad practice to query a (global) property in a FindXXX.cmake file. The reason I wanted to do this is, that when creating statically linked executables you will have to link against every library that you (indirectly) depend upon. When creating dynamically linked executables you usually don't have to worry so much, because indirect dependencies will be handled by the dynamic loader (assuming that the library you directly depend upon has its run-time dependencies set up properly). So, for example, assume I want to link against libldap. The 'ldd' command reveals all libraries that (the dynamic library) libldap.so depends upon. When creating a statically linked executable, I would have to link against each and every (static) library in that list. On the other hand, when linking dynamically, I would only have to link against libldap.so. Testing needlessly for the presence of all these (static) libraries makes CMake run unnecessary slow, so I would prefer to only do this if absolutely necessary: i.e. when creating a statically linked executable. For this I could query the global property TARGET_SUPPORTS_SHARED_LIBS, and have my FindXXX macro only check for all indirect dependencies when that property is FALSE. Good idea or bad idea? Best regards, Marcel Loose. ___ 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] Globbing expression
Hi Arnaud, Your mixing globbing with regular expressions. AFAIK it is not possible to do this with one statement. I would just glob for all *.so files and then use string(REGEX REPLACE ...) to replace occurrences of '^libA.* \.so' with an empty string. Best regards, Marcel Loose. On Mon, 2009-07-13 at 10:43 +0200, Arnaud Devalkeneer wrote: Hello everybody, I would like to know if there exists a way to find all files in a directory with a custom file extension (e.g. *.so) except files beginning by a custom string (here libA). For example I am using the line : FILE( GLOB RESULT path/[^libA]*.so ) but the RESULT variable remains empty. Of cource I am sure of *.so files existance in the path. Has anybody already tried to glob files in a directory, excluding some file name patterns? Thank you in advance for your help. Enjoy Cmake, Arnaud. ___ 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] How to pass -D options when compiling assembly files using gcc?
On Sun, 2009-07-12 at 00:09 +0200, Eric Noulard wrote: 2009/7/11 Marcel Loose lo...@astron.nl: Hi Bill, The problem is not in the invocation of gcc. That works fine. The problem is that I lose the preprocessor definitions that were added with add_definitions() when compiling assembly files. These assembly files must be preprocessed by gcc. I have the feeling that CMake purposely drops these. So the question is how I can persuade CMake to keep the -D options on the command line. I don't know if you can persuade CMake to keep those for compiling ASM instead of C but you may be you get the currently added definitions using properties: (on directory, target or source see cmake --help-properties) e.g.: get_directory_property(ASM_DEF DEFINITION) then use the value of ASM_DEF in your *ASM*.cmake. Take my opinion as pure guess because I does not know much on how CMake*Compiler.cmake works so I don't know if you may share some variables values between the standard C and your custom ASM. Note that I have defined an assembler for BG/P that uses gcc as frontend, using the *ASM*.cmake macros mentioned in my previous mail. Hi Eric, Thanks, I'll try that tomorrow. Another option that occurred to me today is that, since I'm using gcc to preprocess and compile the assembly sources, I might add .S as source file extension to CMAKE_C_SOURCE_FILE_EXTENSIONS. Any idea if that might work? Best regards, Marcel Loose. ___ 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
