Re: [cmake-developers] Bug fix requests for the *next* release of CMake...
When using external_project, if GIT_TAG is modified the entire source tree is removed and re-cloned causing a full rebuild of said project. http://cmake.org/Bug/view.php?id=11403 On Tue, Mar 29, 2011 at 1:56 PM, David Cole david.c...@kitware.com wrote: Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. *Just a short reply with bug numbers* or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. We are aiming for quarterly releases from now on, scheduling them every 3 or 4 months. That would make the next release of CMake version 2.8.5, scheduled to have an rc1 release candidate on Wed. April 27, 2011. If you have a particular issue that you think should be fixed for inclusion in 2.8.5, please bring it up by the end of this week. Ideally, each issue will be discussed as needed on the mailing list to come to any consensus about what should be done to fix it, and then an entry in the bug tracker may be used to keep it on the radar screen, and to track activity related to it. Patches are always welcome. Patches that include testing of any new features, or tests that prove a bug is really fixed on the dashboards, basically any patch with testing is preferred over a patch with no testing. Also, if you are *adding* code, then you also probably need to add *tests* of that code, so that the coverage percentage stays as is or rises. Please discuss issues here as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur over the next 4 weeks. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.4 release, see here: http://public.kitware.com/Bug/changelog_page.php -- it currently lists 127 issues that we resolved: nice job, everybody! (Many of those were specifically addressed because somebody brought it up in response to my similar email from just after 2.8.3... Don't be shy!) ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Proceccor identification
On 03/26/2011 10:05 AM, Rolf Eike Beer wrote: -can kwsys be moved from CVS to git? I know David Cole was in favor of this too. KWSys is shared by several Kitware projects of which at least some are still in CVS. It cannot move. -can the SystemInformation.cxx file be split up into OS dependent things please? This file alone has more then 3.5k lines containing tons of #ifdef for every OS and it's brother. I would like to make SystemInformationImplementation an (abstract?) base class that every OS inherits from and implements it's own stuff. This can easily be split into seperate files, can be totally excluded from build on non-related OS and would greatly reduce the #ifdef count and amount of lines in that single file. Sure. All that code can be much better organized. Instead of keeping it in KWSys just create brand new code that is specific to CMake and not in the KWSys directory. In this case I think the duplication is better than trying to maintain this in KWSys. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012029]: finding boost libs
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12029
==
Reported By:Clinton Stimpson
Assigned To:
==
Project:CMake
Issue ID: 12029
Category: Modules
Reproducibility:have not tried
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2011-03-30 17:05 EDT
Last Modified: 2011-03-30 17:05 EDT
==
Summary:finding boost libs
Description:
I have a local install of boost in my home directory and I set the
CMAKE_PREFIX_PATH to include the root of that boost installation, but
find_package(Boost) gives me a mixed set of paths.
Boost_INCLUDE_DIR=${HOME}/boost-1.46/include
Boost_LIBRARY_DIRS=/usr/lib
Boost_THREAD_LIBRARY_RELEASE=/usr/lib/libboost_thread-mt.so
==
Issue History
Date ModifiedUsername FieldChange
==
2011-03-30 17:05 Clinton StimpsonNew Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Does set_target_properties compile_flags option override include_directories?
Hello all,
The project I am working on uses pkg-config --cflags option to get the
include directories of an external project, and I am trying to add the
output to the compile_flags option used in set_target_properties. As
well as the pkg-config directory, some other flags are specified and
well recognized by the IDE we are building the project for (Visual
Studio).
The code stands as specified here (run_pkgconfig is a macro):
RUN_PKGCONFIG(--cflags ACE result LINKER_FLAGS)
SET(LINKER_FLAGS ${LINKER_FLAGS} -D_CRT_SECURE_NO_WARNINGS
-DACE_AS_STATIC_LIBS)
SET_TARGET_PROPERTIES(
myproject PROPERTIES
COMPILE_FLAGS ${LINKER_FLAGS} )
pkg-config output: -Ic:/ace/ace_wrappers/include
The LINKER_FLAGS variable is well set to with this content:
-Ic:/ace/ace_wrappers/include -D_CRT_SECURE_NO_WARNINGS
-DACE_AS_STATIC_LIBS
Prior to this, some include directories from our own project are added
using include_directories statement.
INCLUDE_DIRECTORIES(
${MYPROJECT_DIR_PATH}
${MYPROJECT_DIR_PATH}/component
${MYPROJECT_DIR_PATH}/error
${MYPROJECT_DIR_PATH}/libraries)
The project is then built successfully until we open the visual studio
solution generated. After exploring the C/C++ command line properties
of the project, it seems that all the include directories but the one
generated by pkg-config are missing:
/Ic:/ace/ace_wrappers/include /D _CRT_SECURE_NO_WARNINGS /D
ACE_AS_STATIC_LIBS
If I don't add the pkg-config output, then all the directories
included with include-directories appear to be ok:
/IC:/git-projects/myproject /IC:/git-projects/myproject/component
/IC:/git-projects/myproject/error
/IC:/git-projects/myproject/libraries /D _CRT_SECURE_NO_WARNINGS
/D ACE_AS_STATIC_LIBS
So the question is, does compile-flags option override all the
directories included with include_directories? If that's the case,
then how do I add external include directories through pkg-config? I
am pretty new at cmake so any help will be appreciated.
Thank you in advance.
Laura Autón.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Does set_target_properties compile_flags option override include_directories?
2011/3/30 Laura Auton Garcia darklulu+cm...@gmail.com:
Hello all,
The project I am working on uses pkg-config --cflags option to get the
include directories of an external project, and I am trying to add the
output to the compile_flags option used in set_target_properties. As
well as the pkg-config directory, some other flags are specified and
well recognized by the IDE we are building the project for (Visual
Studio).
The code stands as specified here (run_pkgconfig is a macro):
RUN_PKGCONFIG(--cflags ACE result LINKER_FLAGS)
SET(LINKER_FLAGS ${LINKER_FLAGS} -D_CRT_SECURE_NO_WARNINGS
-DACE_AS_STATIC_LIBS)
SET_TARGET_PROPERTIES(
myproject PROPERTIES
COMPILE_FLAGS ${LINKER_FLAGS} )
Did you know that there is a FindPkgConfig.cmake module shipped with CMake?
It may helps you to use PkgConfig.
pkg-config output: -Ic:/ace/ace_wrappers/include
The LINKER_FLAGS variable is well set to with this content:
-Ic:/ace/ace_wrappers/include -D_CRT_SECURE_NO_WARNINGS
-DACE_AS_STATIC_LIBS
Prior to this, some include directories from our own project are added
using include_directories statement.
INCLUDE_DIRECTORIES(
${MYPROJECT_DIR_PATH}
${MYPROJECT_DIR_PATH}/component
${MYPROJECT_DIR_PATH}/error
${MYPROJECT_DIR_PATH}/libraries)
The project is then built successfully
You mean CMake successfully generate the project files right?
You did not manage to build your project outside Visual Studio?
until we open the visual studio
solution generated. After exploring the C/C++ command line properties
of the project, it seems that all the include directories but the one
generated by pkg-config are missing:
/Ic:/ace/ace_wrappers/include /D _CRT_SECURE_NO_WARNINGS /D
ACE_AS_STATIC_LIBS
If I don't add the pkg-config output, then all the directories
included with include-directories appear to be ok:
/IC:/git-projects/myproject /IC:/git-projects/myproject/component
/IC:/git-projects/myproject/error
/IC:/git-projects/myproject/libraries /D _CRT_SECURE_NO_WARNINGS
/D ACE_AS_STATIC_LIBS
So the question is, does compile-flags option override all the
directories included with include_directories? If that's the case,
then how do I add external include directories through pkg-config? I
am pretty new at cmake so any help will be appreciated.
Not it shouldn't.
Which version of CMake are you using?
Is the myproject use in this:
SET_TARGET_PROPERTIES(
myproject PROPERTIES
COMPILE_FLAGS ${LINKER_FLAGS} )
a target from add_executable() or add_library() or is it
the name of the project used in project() statement?
May be you can give us more information about your CMakeLists.txt.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?
On 03/29/2011 11:36 PM, Rolf Eike Beer wrote:
Am Dienstag, 29. März 2011, 09:41:36 schrieb Brad King:
On 03/29/2011 05:19 AM, Rolf Eike Beer wrote:
The basic idea is: any symbols from those private libraries are, well,
private. The user only ever sees the symbols from the public library. In
fact he _can't_ even link to the private libraries on Windows as we
never
install the .lib files. And that's no problem at all as we already link
to everything we need. I'm using --as-needed and --no-undefined on Un*x
and see no problem there either.
So the point is I want CMake to stop telling the user that he needs to
those private libraries as that's simply not true.
As Michael pointed out it is needed to set this property:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:IMPORTED_LINK_
DEPENDENT_LIBRARIES
CMake running in an outside application needs to know these private runtime
dependencies. It needs them ensure that the application link line is
generated such that the linker can find the transitive dependencies (e.g.
-rpath-link) of the public library.
No, why should it? Take the attached example. Build it. Do ldd on testthing.
It links against Qt. Run testthing. It prints your path. Delete libqthing.
Move libcthing to libqtthing. Run testthing. It prints your path just like
before. ldd testthing. It still links against Qt.
Besides, ldd is not appropriate to check against which shared libraries
a binary is linked because it gathers all shared libraries recursively.
As a proof, set the LINK_INTERFACE_LIBRARIES property on qthing to the
empty string and rebuild; ldd testthing still shows the Qt libraries,
indirectly pulled in by qthing. Instead, one should apply readelf -d
and look for the NEEDED fields to see which shared libraries a binary
actually depends on explicitly, at least on an ELF platform.
Now when I set LINK_INTERFACE_LIBRARIES on qthing to empty it will prevent
testthing to be linked against Qt itself so after replacing libqthing with
libcthing everything works fine but without the (now useless) dependency on
Qt.
So why would I import that dependency to an outside project then?
I think this transitive linking for _shared_ libraries should actually be
considered harmful. We provide an API and that's all a user should care
about.
We may change our internal libraries in any release at will and the user
should care. In fact we have done this more than one and the binaries linked
against older runtime versions just happily work with newer releases. If that
transitive stuff would have been used none of them would work anymore because
we have moved, renamed, deleted, replaced and done other things to our
internal libraries.
I guess you had a reason for this transitive stuff, but I don't understand
it.
To prevent the silly user from accidentially underlinking his executables and
libs? I know where this is needed for in static libs, but for shared ones?
Eike
Everything you're saying above is correct, and perhaps one can argue
about such a kind of transitive linking, but you can avoid it easily
with the LINK_INTERFACE_LIBRARIES properties which are also honored by
INSTALL(EXPORT), i.e. with imported targets. Take the exemplary project
LIL from my previous post, build/install it and look at the following:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LILUSR C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
INCLUDE(lil)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main1 main.c)
TARGET_LINK_LIBRARIES(main1 f1)
ADD_EXECUTABLE(main2 main.c)
TARGET_LINK_LIBRARIES(main2 f2)
Configure with CMAKE_MODULE_PATH set to the directory containing the
lil.cmake file from the LIL project and look for the linker commands;
you'll see that main1 gets linked against libf1.so and libf0.so while
main2 gets linked against libf2.so only - no f0 in sight. Hence, the
f2 target's IMPORTED_LINK_DEPENDENT_LIBRARIES property actually does
what's expected: It prevents libf0.so from appearing in the linker's
command line, so there is no direct dependency of main2 on libf0.so.
However, I still don't understand the relation of that transitive
linking and its avoidance, respectively, to your initial complaint
about CMake's error message due to the missing library in another
library's export set. Unless I'm mistaken, you've a shared library
target publiclib which is linked explicitly against another target
privatelib via TARGET_LINK_LIBRARIES(). This means you can't place
publiclib in an export set without privatelib since the former could
not be set up properly w.r.t. its diverse IMPORTED properties if the
latter is not installed, too, i.e. INSTALL(EXPORT) could not generate
a valid export file.
If you want to remove the error message, just include privatelib in
publiclibs's export set; here, both targets may perfectly reside in
different directories with different CMakeLists.txt files, but they
must be members of the same
Re: [CMake] Does set_target_properties compile_flags option override include_directories?
(sorry I am having troubles receiving the messages from this mailing
list, well I am not receiving anything at all but the confirmation
mails, so I am pasting from the archives)
2011/3/30 Eric Noulard:
Did you know that there is a FindPkgConfig.cmake module shipped with CMake?
It may helps you to use PkgConfig.
That module is used indeed, to find the pkg-config executable file. I
didn't write the macro as I am not the owner of this project, just a
tiny contributor, so I suppose they had their reasons.
You mean CMake successfully generate the project files right?
Correct. Cmake generates it successfully.
You did not manage to build your project outside Visual Studio?
If you mean if I have been able to compile the project using any other
tool, no. As Visual Studio usage is compulsory I don't have any other
choice. If Visual Studio is the problem then I have to find any other
way to include external include directories through cmake, not using
compile flags in set_target_properties.
So the question is, does compile-flags option override all the
directories included with include_directories? If that's the case,
then how do I add external include directories through pkg-config? I
am pretty new at cmake so any help will be appreciated.
Not it shouldn't. Which version of CMake are you using?
2.8.3
Is the myproject use in this:
SET_TARGET_PROPERTIES(
myproject PROPERTIES
COMPILE_FLAGS ${LINKER_FLAGS} )
a target from add_executable() or add_library() or is it the name of the
project used in project() statement?
Yes. I omitted it as I didn't know it had something to do with it:
SET(MYPROJECT_SRCS
${Common_SRCS}
${Common_HDRS}
${MSWIN_SRCS}
${MSWIN_HDRS} )
ADD_LIBRARY(myproject ${MYPROJECT_SRCS})
TARGET_LINK_LIBRARIES(myproject ${ACE_LIBRARIES})
SET_TARGET_PROPERTIES(
myproject PROPERTIES
COMPILE_FLAGS ${LINKER_FLAGS} )
___
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] Specify an alternate C++ compiler for some source files
Hi,
How to specify different compilers for different source files in
CMakeLists.txt, e.g. if
test1.cxx must be compiled with g++
test2.cxx must be compiled with mpicxx (mpi compiler)
I tried
add_executable(test1.exe test1.cxx)
set_source_files_properties(test2.cxx PROPERTIES CMAKE_CXX_COMPILER
${MPI_COMPILER})
add_executable(test2.exe test2.cxx)
but it didn't work (i.e. g++ is still used for test2.cxx - test2.o).
Any help appreciated.
Best Regards,
Marc
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?
On 03/29/2011 11:36 PM, Rolf Eike Beer wrote:
Am Dienstag, 29. März 2011, 09:41:36 schrieb Brad King:
On 03/29/2011 05:19 AM, Rolf Eike Beer wrote:
The basic idea is: any symbols from those private libraries are, well,
private. The user only ever sees the symbols from the public library.
In
fact he _can't_ even link to the private libraries on Windows as we
never
install the .lib files. And that's no problem at all as we already
link
to everything we need. I'm using --as-needed and --no-undefined on
Un*x
and see no problem there either.
So the point is I want CMake to stop telling the user that he needs to
those private libraries as that's simply not true.
As Michael pointed out it is needed to set this property:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:IMPORTED_LINK_
DEPENDENT_LIBRARIES
CMake running in an outside application needs to know these private
runtime
dependencies. It needs them ensure that the application link line is
generated such that the linker can find the transitive dependencies
(e.g.
-rpath-link) of the public library.
No, why should it? Take the attached example. Build it. Do ldd on
testthing.
It links against Qt. Run testthing. It prints your path. Delete
libqthing.
Move libcthing to libqtthing. Run testthing. It prints your path just
like
before. ldd testthing. It still links against Qt.
Besides, ldd is not appropriate to check against which shared libraries
a binary is linked because it gathers all shared libraries recursively.
As a proof, set the LINK_INTERFACE_LIBRARIES property on qthing to the
empty string and rebuild; ldd testthing still shows the Qt libraries,
indirectly pulled in by qthing. Instead, one should apply readelf -d
and look for the NEEDED fields to see which shared libraries a binary
actually depends on explicitly, at least on an ELF platform.
Yes and no. Of course it shows the recursive things. But if you delete
libqthing.so ldd on the file still shows it is linking against Qt but that
can't come from libqthing anymore. So the executable is actually
overlinked.
Now when I set LINK_INTERFACE_LIBRARIES on qthing to empty it will
prevent
testthing to be linked against Qt itself so after replacing libqthing with
libcthing everything works fine but without the (now useless) dependency
on Qt.
So why would I import that dependency to an outside project then?
I think this transitive linking for _shared_ libraries should actually
be
considered harmful. We provide an API and that's all a user should care
about.
We may change our internal libraries in any release at will and the user
should care. In fact we have done this more than one and the binaries
linked
against older runtime versions just happily work with newer releases.
If that
transitive stuff would have been used none of them would work anymore
because
we have moved, renamed, deleted, replaced and done other things to our
internal libraries.
I guess you had a reason for this transitive stuff, but I don't
understand it.
To prevent the silly user from accidentially underlinking his
executables and
libs? I know where this is needed for in static libs, but for shared ones?
Everything you're saying above is correct, and perhaps one can argue
about such a kind of transitive linking, but you can avoid it easily
with the LINK_INTERFACE_LIBRARIES properties which are also honored by
INSTALL(EXPORT), i.e. with imported targets. Take the exemplary project
LIL from my previous post, build/install it and look at the following:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LILUSR C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
INCLUDE(lil)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main1 main.c)
TARGET_LINK_LIBRARIES(main1 f1)
ADD_EXECUTABLE(main2 main.c)
TARGET_LINK_LIBRARIES(main2 f2)
Configure with CMAKE_MODULE_PATH set to the directory containing the
lil.cmake file from the LIL project and look for the linker commands;
you'll see that main1 gets linked against libf1.so and libf0.so while
main2 gets linked against libf2.so only - no f0 in sight. Hence, the
f2 target's IMPORTED_LINK_DEPENDENT_LIBRARIES property actually does
what's expected: It prevents libf0.so from appearing in the linker's
command line, so there is no direct dependency of main2 on libf0.so.
However, I still don't understand the relation of that transitive
linking and its avoidance, respectively, to your initial complaint
about CMake's error message due to the missing library in another
library's export set. Unless I'm mistaken, you've a shared library
target publiclib which is linked explicitly against another target
privatelib via TARGET_LINK_LIBRARIES().
Yes.
This means you can't place
publiclib in an export set without privatelib since the former could
not be set up properly w.r.t. its diverse IMPORTED properties if the
latter is not installed, too, i.e. INSTALL(EXPORT) could not generate
a
Re: [CMake] Different CMAKE_CXX_FLAGS for different executables
On 03/25/2011 03:36 PM, David Doria wrote: Could you post the output of make VERBOSE=1? On *nix, the following CMakeLists.txt works as expected: The output of make VERBOSE=1 contains: .../c++ -DUNIX -o .../SetTargetProperties.cxx.o -c .../SetTargetProperties.cxx It is working properly now. I must not have done a 'make clean'. BTW, preprocessor definitions like -DUNIX should be set via the COMPILE_DEFINITIONS properties instead of the COMPILE_FLAGS ones. It seems to generate exactly the same thing if I use set_target_properties(CompilerFlags PROPERTIES COMPILE_FLAGS -DUNIX) and set_target_properties(CompilerFlags PROPERTIES COMPILE_DEFINITIONS UNIX) After reading the documentation you set certainly sounds like I should use the COMPILE_DEFINITIONS version, but is there a difference? Thanks again, David For simple defines, i.e. without = sign, COMPILE_FLAGS with -D and COMPILE_DEFINITIONS without -D should act equivalently. However, the latter cares about the correct escaping for more complex definitions, i.e. -DXYZ=\...\ and the like. Furthermore, COMPILE_DEFINITIONS has configuration-specific variants and is also available as a directory property. Finally, it is list-oriented while COMPILE_FLAGS is space- separated. Thus, COMPILE_DEFINITIONS is preferable for preprocessor definitions while COMPILE_FLAGS should be reserved for non-define flags - as long as it doesn't become obsolete anyway due to the envisaged COMPILE_OPTIONS property [1]. Regards, Michael [1] http://public.kitware.com/Bug/view.php?id=6493#c13821 ___ 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] Specify an alternate C++ compiler for some source files
On 03/30/2011 01:42 PM, Marc Tajchman wrote:
Hi,
How to specify different compilers for different source files in
CMakeLists.txt, e.g. if
test1.cxx must be compiled with g++
test2.cxx must be compiled with mpicxx (mpi compiler)
I tried
add_executable(test1.exe test1.cxx)
set_source_files_properties(test2.cxx PROPERTIES CMAKE_CXX_COMPILER
${MPI_COMPILER})
add_executable(test2.exe test2.cxx)
but it didn't work (i.e. g++ is still used for test2.cxx - test2.o).
Any help appreciated.
Best Regards,
Marc
CMake can't do that. But if you need MPI, use
find_package(MPI REQUIRED)
include_directories(${MPI_INCLUDE_PATH})
add_executable(test1 test1.cxx)
add_executable(test2 test2.cxx)
target_link_libraries(test2 ${MPI_LIBRARIES})
set_target_properties(test2 PROPERTIES
COMPILE_FLAGS ${MPI_COMPILE_FLAGS}
LINK_FLAGS ${MPI_LINK_FLAGS})
HTH
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?
On 03/30/2011 02:02 PM, Rolf Eike Beer wrote:
However, I still don't understand the relation of that transitive
linking and its avoidance, respectively, to your initial complaint
about CMake's error message due to the missing library in another
library's export set. Unless I'm mistaken, you've a shared library
target publiclib which is linked explicitly against another target
privatelib via TARGET_LINK_LIBRARIES().
Yes.
This means you can't place
publiclib in an export set without privatelib since the former could
not be set up properly w.r.t. its diverse IMPORTED properties if the
latter is not installed, too, i.e. INSTALL(EXPORT) could not generate
a valid export file.
Yes, and that's basically the problem I have.
Ok, I went and put every thing in the same export set. Which itself is a
bit weird as I now have to INSTALL static libraries that were linked by
the shared ones only to be able to specify that they are in the export
set. And at the end all those libraries of course show up in the export.
And I still see IMPORTED_LINK_DEPENDENT_LIBRARIES_DEBUG of the library
that this is all about set to it's dependencies.
W.r.t. *static* libraries, that's not necessary: If a shared library is
linked against a static one and the former prevents transitive linking
for the latter by setting LINK_INTERRFACE_LIBRARIES appropriately, the
static library does not need to be put in the shared one's export set:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(PRIVATE C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f STATIC f.c)
FILE(WRITE ${CMAKE_BINARY_DIR}/g.c void g(void){f();}\n)
ADD_LIBRARY(g SHARED g.c)
TARGET_LINK_LIBRARIES(g f)
SET_TARGET_PROPERTIES(g PROPERTIES LINK_INTERFACE_LIBRARIES )
INSTALL(TARGETS g EXPORT public LIBRARY DESTINATION lib)
INSTALL(EXPORT public DESTINATION share)
In the export file, the static f isn't mentioned at all, and that's
perfect. Without LINK_INTERFACE_LIBRARIES set or with a *shared* f,
this does not work, of course.
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Visual Studio 6 generator and relative source file path
I've already posted the question about different targets with the same name. I'm trying to change my project's cmake configuration towards it like this (this is a very simplicated example): |-- foo | cmake_foo1 |--- CMakeLists.txt | cmake_foo2 |--- CMakeLists.txt | | bar.cpp | CMakeLists.txt | foo.cpp | foo.rc cmake_foo1/CMakeLists.txt: add_library(foo1 ../bar.cpp ../foo.cpp ../foo.rc) cmake_foo2/CMakeLists.txt ist similar. I've got the wrong intermediate path for foo.cpp and foo.rc, because CMake thinks, its the same filename, so it must generate the output in different dirs. I've got the cmake source code and tried to debug. I've found out, that the function cmLocalVisualStudioGenerator::CountObjectNames calculates object file name wrong. It adds obj regardless source file type. It must be - objectName += this-GlobalGenerator-GetLanguageOutputExtension(*sf) - instead. I think, its a easy fix. -- BG, Alexey ___ 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] Bug fix requests for the *next* release of CMake...
Hi David, http://public.kitware.com/Bug/view.php?id=11896 Thanks, Shash -Original Message- From: cmake-boun...@cmake.org on behalf of David Cole Sent: Tue 3/29/2011 12:56 PM To: cmake; CMake Developers Subject: [CMake] Bug fix requests for the *next* release of CMake... Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. *Just a short reply with bug numbers* or links to the bugs is all we need here. ___ 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] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?
On 03/30/2011 02:02 PM, Rolf Eike Beer wrote:
However, I still don't understand the relation of that transitive
linking and its avoidance, respectively, to your initial complaint
about CMake's error message due to the missing library in another
library's export set. Unless I'm mistaken, you've a shared library
target publiclib which is linked explicitly against another target
privatelib via TARGET_LINK_LIBRARIES().
Yes.
This means you can't place
publiclib in an export set without privatelib since the former could
not be set up properly w.r.t. its diverse IMPORTED properties if the
latter is not installed, too, i.e. INSTALL(EXPORT) could not generate
a valid export file.
Yes, and that's basically the problem I have.
Ok, I went and put every thing in the same export set. Which itself is a
bit weird as I now have to INSTALL static libraries that were linked by
the shared ones only to be able to specify that they are in the export
set. And at the end all those libraries of course show up in the export.
And I still see IMPORTED_LINK_DEPENDENT_LIBRARIES_DEBUG of the library
that this is all about set to it's dependencies.
W.r.t. *static* libraries, that's not necessary: If a shared library is
linked against a static one and the former prevents transitive linking
for the latter by setting LINK_INTERRFACE_LIBRARIES appropriately, the
static library does not need to be put in the shared one's export set:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(PRIVATE C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f STATIC f.c)
FILE(WRITE ${CMAKE_BINARY_DIR}/g.c void g(void){f();}\n)
ADD_LIBRARY(g SHARED g.c)
TARGET_LINK_LIBRARIES(g f)
SET_TARGET_PROPERTIES(g PROPERTIES LINK_INTERFACE_LIBRARIES )
INSTALL(TARGETS g EXPORT public LIBRARY DESTINATION lib)
INSTALL(EXPORT public DESTINATION share)
In the export file, the static f isn't mentioned at all, and that's
perfect. Without LINK_INTERFACE_LIBRARIES set or with a *shared* f,
this does not work, of course.
What CMake version are you using? For me CMake is complaining that the
public library depends on some private libraries that are not exported and
they are static. Only adding
INSTALL(TARGETS privstatic EXPORT myexport DESTINATION trash)
made CMake complete successfully, resulting in the static stuff showing up
in the export, too.
Maybe I just write the export file by hand as what's happening here is
just plain wrong IMHO. At least for my case.
Eike
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
Support for assembler sources in the Visual Studio generators, please! http://public.kitware.com/Bug/view.php?id=9905 http://public.kitware.com/Bug/view.php?id=11536 Thanks, Jay. ___ 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] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?
On 03/30/2011 03:14 PM, Rolf Eike Beer wrote:
On 03/30/2011 02:02 PM, Rolf Eike Beer wrote:
However, I still don't understand the relation of that transitive
linking and its avoidance, respectively, to your initial complaint
about CMake's error message due to the missing library in another
library's export set. Unless I'm mistaken, you've a shared library
target publiclib which is linked explicitly against another target
privatelib via TARGET_LINK_LIBRARIES().
Yes.
This means you can't place
publiclib in an export set without privatelib since the former could
not be set up properly w.r.t. its diverse IMPORTED properties if the
latter is not installed, too, i.e. INSTALL(EXPORT) could not generate
a valid export file.
Yes, and that's basically the problem I have.
Ok, I went and put every thing in the same export set. Which itself is a
bit weird as I now have to INSTALL static libraries that were linked by
the shared ones only to be able to specify that they are in the export
set. And at the end all those libraries of course show up in the export.
And I still see IMPORTED_LINK_DEPENDENT_LIBRARIES_DEBUG of the library
that this is all about set to it's dependencies.
W.r.t. *static* libraries, that's not necessary: If a shared library is
linked against a static one and the former prevents transitive linking
for the latter by setting LINK_INTERRFACE_LIBRARIES appropriately, the
static library does not need to be put in the shared one's export set:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(PRIVATE C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f STATIC f.c)
FILE(WRITE ${CMAKE_BINARY_DIR}/g.c void g(void){f();}\n)
ADD_LIBRARY(g SHARED g.c)
TARGET_LINK_LIBRARIES(g f)
SET_TARGET_PROPERTIES(g PROPERTIES LINK_INTERFACE_LIBRARIES )
INSTALL(TARGETS g EXPORT public LIBRARY DESTINATION lib)
INSTALL(EXPORT public DESTINATION share)
In the export file, the static f isn't mentioned at all, and that's
perfect. Without LINK_INTERFACE_LIBRARIES set or with a *shared* f,
this does not work, of course.
What CMake version are you using? [...]
2.8.4
[...] For me CMake is complaining that the
public library depends on some private libraries that are not exported and
they are static. [...]
Does the above-noted example fail with your version of CMake?
[...] Only adding
INSTALL(TARGETS privstatic EXPORT myexport DESTINATION trash)
made CMake complete successfully, resulting in the static stuff showing up
in the export, too.
Could you provide a minimal but complete example with that issue?
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
CMAKE_BUILD_TYPE should be a drop down box/fixed set of choices http://public.kitware.com/Bug/view.php?id=11806 http://public.kitware.com/Bug/view.php?id=11806 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
Re: [CMake] Bug fix requests for the *next* release of CMake...
http://public.kitware.com/Bug/view.php?id=11171 I'm hoping this one isn't too hard to fix. --- Aaron Wright From: David Cole david.c...@kitware.com To: cmake cmake@cmake.org, CMake Developers cmake-develop...@cmake.org Date: 03/29/2011 10:57 AM Subject:[CMake] Bug fix requests for the *next* release of CMake... Sent by:cmake-boun...@cmake.org Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. Just a short reply with bug numbers or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. We are aiming for quarterly releases from now on, scheduling them every 3 or 4 months. That would make the next release of CMake version 2.8.5, scheduled to have an rc1 release candidate on Wed. April 27, 2011. If you have a particular issue that you think should be fixed for inclusion in 2.8.5, please bring it up by the end of this week. Ideally, each issue will be discussed as needed on the mailing list to come to any consensus about what should be done to fix it, and then an entry in the bug tracker may be used to keep it on the radar screen, and to track activity related to it. Patches are always welcome. Patches that include testing of any new features, or tests that prove a bug is really fixed on the dashboards, basically any patch with testing is preferred over a patch with no testing. Also, if you are *adding* code, then you also probably need to add *tests* of that code, so that the coverage percentage stays as is or rises. Please discuss issues here as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur over the next 4 weeks. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.4 release, see here: http://public.kitware.com/Bug/changelog_page.php -- it currently lists 127 issues that we resolved: nice job, everybody! (Many of those were specifically addressed because somebody brought it up in response to my similar email from just after 2.8.3... Don't be shy!) ___ 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] List of possible completion values
Hi, Is there a way (and if not, how do I submit a feature request) to have a set of drop-down type options in the ccmake interface? The obvious example is for CMAKE_BUILD_TYPE, where something like hitting Enter scrolls through Release - Debug - MinSizeRel, etc.. Maybe somebody has already written something to do this somewhere and I just can't find it... Thanks, Tim ___ 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] List of possible completion values
On Wed, Mar 30, 2011 at 11:52 AM, Tim Gallagher tim.gallag...@gatech.eduwrote: Hi, Is there a way (and if not, how do I submit a feature request) to have a set of drop-down type options in the ccmake interface? The obvious example is for CMAKE_BUILD_TYPE, where something like hitting Enter scrolls through Release - Debug - MinSizeRel, etc.. Maybe somebody has already written something to do this somewhere and I just can't find it... Thanks, Tim I have requested exactly this here: http://public.kitware.com/Bug/view.php?id=11806 http://public.kitware.com/Bug/view.php?id=11806There is a solution posted there (which I haven't tried) that may get you through for now. What I was suggesting, though, was for this to be the default behavior of CMAKE_BUILD_TYPE. 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
Re: [CMake] List of possible completion values
On 03/30/2011 05:52 PM, Tim Gallagher wrote: Hi, Is there a way (and if not, how do I submit a feature request) to have a set of drop-down type options in the ccmake interface? The obvious example is for CMAKE_BUILD_TYPE, where something like hitting Enter scrolls through Release - Debug - MinSizeRel, etc.. Maybe somebody has already written something to do this somewhere and I just can't find it... Thanks, Tim yes. set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS Debug Release RelWithDebInfo MinSizeRel) HTH Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] List of possible completion values
On Wed, Mar 30, 2011 at 11:56 AM, Michael Wild them...@gmail.com wrote: On 03/30/2011 05:52 PM, Tim Gallagher wrote: Hi, Is there a way (and if not, how do I submit a feature request) to have a set of drop-down type options in the ccmake interface? The obvious example is for CMAKE_BUILD_TYPE, where something like hitting Enter scrolls through Release - Debug - MinSizeRel, etc.. Maybe somebody has already written something to do this somewhere and I just can't find it... Thanks, Tim yes. set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS Debug Release RelWithDebInfo MinSizeRel) HTH Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake This behavior is presently only implemented in cmake-gui. It is not in ccmake. 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
Re: [CMake] Bug fix requests for the *next* release of CMake...
http://public.kitware.com/Bug/print_bug_page.php?bug_id=10077* * James * * On Tue, Mar 29, 2011 at 11:56 AM, David Cole david.c...@kitware.com wrote: Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. *Just a short reply with bug numbers* or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. We are aiming for quarterly releases from now on, scheduling them every 3 or 4 months. That would make the next release of CMake version 2.8.5, scheduled to have an rc1 release candidate on Wed. April 27, 2011. If you have a particular issue that you think should be fixed for inclusion in 2.8.5, please bring it up by the end of this week. Ideally, each issue will be discussed as needed on the mailing list to come to any consensus about what should be done to fix it, and then an entry in the bug tracker may be used to keep it on the radar screen, and to track activity related to it. Patches are always welcome. Patches that include testing of any new features, or tests that prove a bug is really fixed on the dashboards, basically any patch with testing is preferred over a patch with no testing. Also, if you are *adding* code, then you also probably need to add *tests* of that code, so that the coverage percentage stays as is or rises. Please discuss issues here as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur over the next 4 weeks. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.4 release, see here: http://public.kitware.com/Bug/changelog_page.php -- it currently lists 127 issues that we resolved: nice job, everybody! (Many of those were specifically addressed because somebody brought it up in response to my similar email from just after 2.8.3... Don't be shy!) ___ 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] Specify an alternate C++ compiler for some source files
Since our default compilers are not gcc (icc, pgcc, cc, xlc_r etc) we've
introduced FLEXLM_C_COMPILER and friends to be able to compile this from a
single source tree.
But perhaps it would be cleaner to off-load it with ExternalProject_Add().
Seriously, how often do you want to compile LAPACK, BLAS, MPI, FLEXlm
yourself...
Regards,
Arjen
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Michael Wild
Sent: woensdag 30 maart 2011 14:11
To: cmake@cmake.org
Subject: Re: [CMake] Specify an alternate C++ compiler for some source
files
On 03/30/2011 01:42 PM, Marc Tajchman wrote:
Hi,
How to specify different compilers for different source files in
CMakeLists.txt, e.g. if
test1.cxx must be compiled with g++
test2.cxx must be compiled with mpicxx (mpi compiler)
I tried
add_executable(test1.exe test1.cxx)
set_source_files_properties(test2.cxx PROPERTIES CMAKE_CXX_COMPILER
${MPI_COMPILER})
add_executable(test2.exe test2.cxx)
but it didn't work (i.e. g++ is still used for test2.cxx - test2.o).
Any help appreciated.
Best Regards,
Marc
CMake can't do that. But if you need MPI, use
find_package(MPI REQUIRED)
include_directories(${MPI_INCLUDE_PATH})
add_executable(test1 test1.cxx)
add_executable(test2 test2.cxx)
target_link_libraries(test2 ${MPI_LIBRARIES})
set_target_properties(test2 PROPERTIES
COMPILE_FLAGS ${MPI_COMPILE_FLAGS}
LINK_FLAGS ${MPI_LINK_FLAGS})
HTH
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...
When using external_project, if GIT_TAG is modified the entire source tree is removed and re-cloned causing a full rebuild of said project. http://cmake.org/Bug/view.php?id=11403 On Tue, Mar 29, 2011 at 1:56 PM, David Cole david.c...@kitware.com wrote: Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. *Just a short reply with bug numbers* or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. We are aiming for quarterly releases from now on, scheduling them every 3 or 4 months. That would make the next release of CMake version 2.8.5, scheduled to have an rc1 release candidate on Wed. April 27, 2011. If you have a particular issue that you think should be fixed for inclusion in 2.8.5, please bring it up by the end of this week. Ideally, each issue will be discussed as needed on the mailing list to come to any consensus about what should be done to fix it, and then an entry in the bug tracker may be used to keep it on the radar screen, and to track activity related to it. Patches are always welcome. Patches that include testing of any new features, or tests that prove a bug is really fixed on the dashboards, basically any patch with testing is preferred over a patch with no testing. Also, if you are *adding* code, then you also probably need to add *tests* of that code, so that the coverage percentage stays as is or rises. Please discuss issues here as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur over the next 4 weeks. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.4 release, see here: http://public.kitware.com/Bug/changelog_page.php -- it currently lists 127 issues that we resolved: nice job, everybody! (Many of those were specifically addressed because somebody brought it up in response to my similar email from just after 2.8.3... Don't be shy!) ___ cmake-developers mailing list cmake-develop...@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers ___ 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] Replacing compiler flags for certain project subdirectories
Shortening to reduce wall-of-text: I have a Fortran project with a top-level CMakeLists.txt file with 47 add_subdirectory calls. Three of the subdirectories require a different set of preprocessor definitions and compiler flags than the other 47. I can add the preprocessor definitions, but am having trouble with the compiler flags. I need to have a completely different set in those subdirectories, so COMPILE_FLAGS target property won't work as it augments what's already there. How can I replace (not extend) the compiler flags for these few subdirectories? Tim -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Whitcomb, Mr. Tim Sent: Friday, March 25, 2011 3:18 PM To: 'cmake@cmake.org' Subject: [CMake] Replacing compiler flags for certain project subdirectories I'm in the process of adding Cmake-build capability to a Fortran project that currently follows a traditional recursive-make build structure. I've converted all the makefiles to CMakeLists.txt files and can now produce all the target libraries and executables with their dependencies correctly recognized. These dependencies have made a huge difference in allowing us to perform parallel builds and have the project ready to go *much* faster than before. I have a top-level CMakeLists.txt file that contains a few library searches (e.g. LAPACK, BLAS) and then an add_subdirectory call for each subdirectory in the project. Each subdirectory corresponds to a library and/or an executable. Now that the listing files contain all the sources files they need, my current task is to go through and set the proper compiler/preprocessor flags to match the original makefiles. We have several directories in our source tree that are auxiliary libraries that we store in our Subversion repository and build as part of our regular build process. The libraries that are built in these directories are compiled with different compiler flags and different preprocessor definitions than the rest of the project. I've been able to handle the preprocessor definitions by using add_definitions in the CMakeLists.txt files in the lower-level directories. I see based on reading through some past threads (including the recent Different CMAKE_CXX_FLAGS for different executables) on this list and on some StackOverflow questions that the COMPILE_FLAGS target property is very close to what I need (and actually *was* what I needed in several cases) but only appends flags to those currently in use. What I need is to be able to define a new set of compile flags (i.e. forget everything you were using before and use THIS set in this directory). I've started going through the documentation for Building External Projects[*] but the first line states that [a]n external project is one that you can get the source code for, but does not readily build with a simple ADD_SUBDIRECTORY call in your CMakeLists.txt file. This feels like it's designed to solve a slightly different problem than what I'm trying to do - I have an add_subdirectory call in my CMakeLists.txt file - is the proper fix for this issue to make the pieces that require different flags external projects? Will making some of these libraries external projects mess with the dependency calculation? I'm just getting started and trying to wrap my head around the options available. What is the standard way of dealing with this issue? Is there anything I'm missing? Thank you for your assistance! Tim [w] [*] http://www.kitware.com/products/html/BuildingExternalProjectsW ithCMake2.8.html ___ 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] Bug fix requests for the *next* release of CMake...
I second this request. This also includes http://public.kitware.com/Bug/view.php?id=8170 http://public.kitware.com/Bug/view.php?id=8170Brian On Wed, Mar 30, 2011 at 6:25 AM, Jay Foad jay.f...@gmail.com wrote: Support for assembler sources in the Visual Studio generators, please! http://public.kitware.com/Bug/view.php?id=9905 http://public.kitware.com/Bug/view.php?id=11536 Thanks, Jay. ___ 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 errror
Hello friends, When running cmake command with a toolchain file I got this error: -- Detecting CXX compiler ABI info - done CMake Error at C:/cygwin/CMake/CMake 2.8/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:48 (FILE): file STRINGS file C:/OMAPFlash_Latest/Cmake_OMAPFlash/omapflash/cmake_build/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin cannot be read. Call Stack (most recent call first): C:/cygwin/CMake/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:64 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:2 (project) The toolchain file has the following content: set(CMAKE_SYSTEM_NAME Linux) #specify the cross-compiler set (CMAKE_C_COMPILER /bin/gcc-linux) #set (CMAKE_C_FLAGS -Wall -pedantic -DCOMDRIVER_EXPORTS -DBUILD_FIX_TMP -DFIX_WIN32 -DNO_ZIP -D_DEBUG -D_CONSOLE) set (CMAKE_CXX_COMPILER /bin/g++-linux) set (CMAKE_CXX_FLAGS -Wall -pedantic -DCOMDRIVER_EXPORTS -DBUILD_FIX_TMP -DFIX_WIN32 -D_DEBUG -D_CONSOLE) It actually was working right in one computer, but when installed in another I got this error. I already checked that all the environment is exactly the same, but I don't know where to look now. Can you help me? Thanks Enrique ___ 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] BundleUtilities Error between 2.8.3 and 2.8.4
Were there any major changes to the BundleUtilities.cmake file between 2.8.3 and 2.8.4? I have a project that installs just fine when running against CMake 2.8.3 but when using CMake 2.8.4 it errors out somewhere in BundleUtilities. I was wondering if there were any major changes to that file that would have caused issues when I upgraded. OS X 10.6.7, CMake 2.8.3 Xcode 3.2.x tool set. Here is the output from the make install -- # Starting OS X Tool Fixup -- -- fixup_bundle -- app='/Users/Shared/Toolkits/emmpm/tools/emmpm_debug' -- libs='' -- dirs='/Users/mjackson/Workspace/EIM-emmpm/Build/Bin;/Users/mjackson/Workspace/EIM-emmpm/Build/Bin' -- fixup_bundle: preparing... -- fixup_bundle: copying... -- 1/6: *NOT* copying '/Users/Shared/Toolkits/emmpm/tools/emmpm_debug' -- 2/6: copying '/Users/Shared/Toolkits/tiff/lib/libtiff_debug.dylib' -- 3/6: copying '/Users/mjackson/Workspace/EIM-emmpm/Build/Bin/libEMMPMLib_debug.dylib' -- fixup_bundle: fixing... -- 4/6: fixing up '/Users/Shared/Toolkits/emmpm/tools/emmpm_debug' exe_dotapp_dir/='/Users/Shared/Toolkits/emmpm/tools.app/' item_substring='/Users/Shared/Toolkits/emmpm/tools/emmp' resolved_embedded_item='/Users/Shared/Toolkits/emmpm/tools/emmpm_debug' Install or copy the item into the bundle before calling fixup_bundle CMake Error at /Users/Shared/Toolkits/CMake-2.8.4/CMake-2.8.4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:557 (message): cannot fixup an item that is not in the bundle... Call Stack (most recent call first): /Users/Shared/Toolkits/CMake-2.8.4/CMake-2.8.4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:645 (fixup_bundle_item) apps/OSX_Scripts/emmpm_CompleteBundle.cmake:86 (fixup_bundle) apps/cmake_install.cmake:44 (INCLUDE) cmake_install.cmake:33 (INCLUDE) The library (EMMPMLib) is located in /Users/mjackson/Workspace/EIM-emmpm/Build/Bin and the executable is located in /Users/Shared/Toolkits/emmpm/tools/ with a name of emmpm_debug. Note that emmpm_debug is a command line application and NOT an actual .app bundle. Then source to the project is located at http://scm.bluequartz.net/eim/emmpm Thanks ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio ___ 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] BundleUtilities Error between 2.8.3 and 2.8.4
I think you are running into an error message introduced with this commit. cmake.org/gitweb?p=cmake.git;a=commit;h=c2895f48a4e79af49937b9e6a260076440b1a67a You can read about the change which was to prevent problems. Does it not apply to you and its being too restrictive? Clint - Reply message - From: Michael Jackson mike.jack...@bluequartz.net Date: Wed, Mar 30, 2011 4:50 pm Subject: [CMake] BundleUtilities Error between 2.8.3 and 2.8.4 To: CMake ML cmake@cmake.org Were there any major changes to the BundleUtilities.cmake file between 2.8.3 and 2.8.4? I have a project that installs just fine when running against CMake 2.8.3 but when using CMake 2.8.4 it errors out somewhere in BundleUtilities. I was wondering if there were any major changes to that file that would have caused issues when I upgraded. OS X 10.6.7, CMake 2.8.3 Xcode 3.2.x tool set. Here is the output from the make install -- # Starting OS X Tool Fixup -- -- fixup_bundle -- app='/Users/Shared/Toolkits/emmpm/tools/emmpm_debug' -- libs='' -- dirs='/Users/mjackson/Workspace/EIM-emmpm/Build/Bin;/Users/mjackson/Workspace/EIM-emmpm/Build/Bin' -- fixup_bundle: preparing... -- fixup_bundle: copying... -- 1/6: *NOT* copying '/Users/Shared/Toolkits/emmpm/tools/emmpm_debug' -- 2/6: copying '/Users/Shared/Toolkits/tiff/lib/libtiff_debug.dylib' -- 3/6: copying '/Users/mjackson/Workspace/EIM-emmpm/Build/Bin/libEMMPMLib_debug.dylib' -- fixup_bundle: fixing... -- 4/6: fixing up '/Users/Shared/Toolkits/emmpm/tools/emmpm_debug' exe_dotapp_dir/='/Users/Shared/Toolkits/emmpm/tools.app/' item_substring='/Users/Shared/Toolkits/emmpm/tools/emmp' resolved_embedded_item='/Users/Shared/Toolkits/emmpm/tools/emmpm_debug' Install or copy the item into the bundle before calling fixup_bundle CMake Error at /Users/Shared/Toolkits/CMake-2.8.4/CMake-2.8.4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:557 (message): cannot fixup an item that is not in the bundle... Call Stack (most recent call first): /Users/Shared/Toolkits/CMake-2.8.4/CMake-2.8.4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:645 (fixup_bundle_item) apps/OSX_Scripts/emmpm_CompleteBundle.cmake:86 (fixup_bundle) apps/cmake_install.cmake:44 (INCLUDE) cmake_install.cmake:33 (INCLUDE) The library (EMMPMLib) is located in /Users/mjackson/Workspace/EIM-emmpm/Build/Bin and the executable is located in /Users/Shared/Toolkits/emmpm/tools/ with a name of emmpm_debug. Note that emmpm_debug is a command line application and NOT an actual .app bundle. Then source to the project is located at http://scm.bluequartz.net/eim/emmpm Thanks ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio ___ 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-commits] CMake branch, next, updated. v2.8.4-1281-gc8c5602
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via c8c56021f4619db9881b6d0179589533b2fa5db5 (commit)
via 128605054a2d773189869d6e1b5000e6d4a93241 (commit)
from cb6c118336b318547e8a936e3496d6262df1cccf (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8c56021f4619db9881b6d0179589533b2fa5db5
commit c8c56021f4619db9881b6d0179589533b2fa5db5
Merge: cb6c118 1286050
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Mar 30 10:05:09 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Mar 30 10:05:09 2011 -0400
Merge topic 'custom-command-slashes' into next
1286050 Normalize slashes of add_custom_(command|target) DEPENDS (#11973)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=128605054a2d773189869d6e1b5000e6d4a93241
commit 128605054a2d773189869d6e1b5000e6d4a93241
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Mar 30 09:52:07 2011 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Mar 30 09:52:07 2011 -0400
Normalize slashes of add_custom_(command|target) DEPENDS (#11973)
All commands accepting file paths should normalize the slashes so that
the string-represented names can be compared reliably. The commands
add_library and add_executable have done this for years. We taught
add_custom_command to normalize its OUTPUT names in commit a75a0a14
(Normalize add_custom_command OUTPUT names, 2010-12-15). We handled a
special case of the DEPENDS option in commit 7befc007 (Handle trailing
slashes on add_custom_command DEPENDS, 2011-01-26).
Teach both add_custom_command and add_custom_target to normalize slashes
of DEPENDS files up front. This approach subsumes the above-mentioned
special case so remove the one line added for it but keep its test.
Extend the CustomCommand test to check that slash count mismatches
between custom command OUTPUT and DEPENDS can still be linked correctly.
diff --git a/Source/cmAddCustomCommandCommand.cxx
b/Source/cmAddCustomCommandCommand.cxx
index 502829e..5634849 100644
--- a/Source/cmAddCustomCommandCommand.cxx
+++ b/Source/cmAddCustomCommandCommand.cxx
@@ -195,11 +195,13 @@ bool cmAddCustomCommandCommand
{
// An implicit dependency starting point is also an
// explicit dependency.
- depends.push_back(copy);
+ std::string dep = copy;
+ cmSystemTools::ConvertToUnixSlashes(dep);
+ depends.push_back(dep);
// Add the implicit dependency language and file.
cmCustomCommand::ImplicitDependsPair
- entry(implicit_depends_lang, copy);
+ entry(implicit_depends_lang, dep);
implicit_depends.push_back(entry);
// Switch back to looking for a language.
@@ -213,7 +215,11 @@ bool cmAddCustomCommandCommand
target = copy;
break;
case doing_depends:
- depends.push_back(copy);
+ {
+ std::string dep = copy;
+ cmSystemTools::ConvertToUnixSlashes(dep);
+ depends.push_back(dep);
+ }
break;
case doing_outputs:
outputs.push_back(filename);
diff --git a/Source/cmAddCustomTargetCommand.cxx
b/Source/cmAddCustomTargetCommand.cxx
index 27dea98..4eba886 100644
--- a/Source/cmAddCustomTargetCommand.cxx
+++ b/Source/cmAddCustomTargetCommand.cxx
@@ -123,7 +123,11 @@ bool cmAddCustomTargetCommand
currentLine.push_back(copy);
break;
case doing_depends:
- depends.push_back(copy);
+ {
+ std::string dep = copy;
+ cmSystemTools::ConvertToUnixSlashes(dep);
+ depends.push_back(dep);
+ }
break;
case doing_comment:
comment_buffer = copy;
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index cd265c1..d3cbc1f 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1893,7 +1893,6 @@ bool cmLocalGenerator::GetRealDependency(const char*
inName,
{
// This is a full path. Return it as given.
dep = inName;
-cmSystemTools::ConvertToUnixSlashes(dep);
return true;
}
diff --git a/Tests/CustomCommand/CMakeLists.txt
b/Tests/CustomCommand/CMakeLists.txt
index 19e3c2c..b7c9ea2 100644
--- a/Tests/CustomCommand/CMakeLists.txt
+++ b/Tests/CustomCommand/CMakeLists.txt
@@ -102,7 +102,7 @@ ADD_CUSTOM_TARGET(TDocument ALL
COMMAND ${CMAKE_COMMAND} -E echo Copying doc1.h to doc2.h.
COMMAND ${CMAKE_COMMAND} -E copy
