[cmake-developers] [CMake 0014644]: FindJPEG.cmake doesn't honour JPEG_ROOT_DIR
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14644 == Reported By:Marcel Metz Assigned To: == Project:CMake Issue ID: 14644 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-12-12 13:24 CET Last Modified: 2013-12-12 13:24 CET == Summary:FindJPEG.cmake doesn't honour JPEG_ROOT_DIR Description: According to Modules/readme.txt Find* modules should honour the Xxx_ROOT_DIR variable to locate separate installations of a library. However the FindJPEG modules doesn't use such a variable or a suitable alternative. Therefor it is impossible to select a jpeg library that isn't installed in a well known directory. == Issue History Date ModifiedUsername FieldChange == 2013-12-12 13:24 Marcel MetzNew Issue 2013-12-12 13:24 Marcel MetzFile Added: FindJPEG.cmake.patch == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014645]: exec_program and execute_process don't capture output when it does not end in a newline
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14645 == Reported By:Nathan Climer Assigned To: == Project:CMake Issue ID: 14645 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-12-12 11:46 EST Last Modified: 2013-12-12 11:46 EST == Summary:exec_program and execute_process don't capture output when it does not end in a newline Description: When trying to capture output of a process, if the stream does not end in a new line, these commands cannot capture the output. Steps to Reproduce: The following batch script shows the problem nicely MESSAGE(STATUS Outputting captured newline) EXEC_PROGRAM(printf ARGS \output is shown\\n\) MESSAGE(STATUS Outputting without newline) EXEC_PROGRAM(printf ARGS \output is not shown\) == Issue History Date ModifiedUsername FieldChange == 2013-12-12 11:46 Nathan Climer New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake build does too much work
On 12/12/2013 11:46 AM, Matthew Woehlke wrote: Where template.hpp changes (testing with 2.8.12.1 shows that touching template.hpp triggers a rebuild with Ninja, but not Unix Makefiles), That sounds like a bug :-). Yes, this is a bug. ninja and make should be the same. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] question about SET_SOURCE_FILES_PROPERTIES
Dear CMakers,
I have a Fortran project to be built on Windows and Linux using ifort
compiler. For two of the project files, I need to add
specific compiler flag (i.e. /assume:byterecl). To do so, I used the
following CMake command:
SET_SOURCE_FILES_PROPERTIES(file1.f90 PROPERTIES COMPILE_FLAGS
${CMAKE_Fortran_FLAGS} /assume:byterecl)
There is one point I could not make clear up to now: if I want this
extra flag to be used whatever the
CMAKE_BUILD_TYPE, is the above command sufficient ? By sufficient I mean
will the use of
${CMAKE_Fortran_FLAGS} be spread all over the
${CMAKE_Fortran_FLAGS_DEBUG}, ${CMAKE_Fortran_FLAGS_RELEASE} ... flags ?
I would like to avoid something like:
IF(CMAKE_BUILD_TYPE STREQUAL Debug)
SET_SOURCE_FILES_PROPERTIES(file1.f90 PROPERTIES COMPILE_FLAGS
${CMAKE_Fortran_FLAGS_DEBUG} /assume:byterecl)
ELSEIF(CMAKE_BUILD_TYPE STREQUAL Release)
SET_SOURCE_FILES_PROPERTIES(file1.f90 PROPERTIES COMPILE_FLAGS
${CMAKE_Fortran_FLAGS_RELEASE} /assume:byterecl)
... and so on for the other build type. Not very nice isn't it but do I
have the choice ?
thanks a lot for your help
Eric
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] depend.make
Thank you for your feedback.
This however only explain part of the issue as far as I can tell. To debug the
issue I added
#pragma message(boost tr1 iostream)
at the top of the boost/tr1/iostream file. When building the source that
message is shown in the console windows which then indicate the compiler has
accessed the file. So far so good. I then did the same trick with
boost/aligned_storage.hpp, boost/array.hpp and boost/assert.hpp which are the
three first boost reference in depend.make and none of them not show up during
building.
So why are these files included in the depend.make?
Regards,
Lars
Date: Wed, 11 Dec 2013 16:08:28 +0100
From: nilsglad...@gmail.com
To: laasu...@hotmail.com; cmake@cmake.org
Subject: Re: [CMake] depend.make
On 11.12.2013 12:53, Lars wrote:
Here is the source code used (which does not use the Boost
library).
#include iostream
int main(int argc, char **argv)
{
std::cout Hello world std::endl;
return 0;
}
${Boost_INCLUDE_DIR}/boost/tr1/tr1 does seem to contain an
iostream header which your #include iostream probably
picks up.
Maybe that further includes the other boost headers?
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] depend.make
Hi,
I cannot find it anymore in the documentation , but I remember to have read
that the dependency scanner of CMake does not take into account the
preprocessor conditionals (#ifdef, etc), thus producing a superset of the
actual dependencies.
It is quite probable that boost/tr1/iostream _may_ include the other headers
under some particular combination of preprocessor macros, so they are not used
at compile time, but they taken into account by CMake.
Cheers
Marco
On Thursday 12 December 2013 11:51:52 Lars wrote:
Thank you for your feedback.
This however only explain part of the issue as far as I can tell. To debug
the issue I added #pragma message(boost tr1 iostream)
at the top of the boost/tr1/iostream file. When building the source that
message is shown in the console windows which then indicate the compiler
has accessed the file. So far so good. I then did the same trick with
boost/aligned_storage.hpp, boost/array.hpp and boost/assert.hpp which are
the three first boost reference in depend.make and none of them not show up
during building.
So why are these files included in the depend.make?
Regards,
Lars
Date: Wed, 11 Dec 2013 16:08:28 +0100
From: nilsglad...@gmail.com
To: laasu...@hotmail.com; cmake@cmake.org
Subject: Re: [CMake] depend.make
On 11.12.2013 12:53, Lars wrote:
Here is the source code used (which does not use the Boost
library).
#include iostream
int main(int argc, char **argv)
{
std::cout Hello world std::endl;
return 0;
}
${Boost_INCLUDE_DIR}/boost/tr1/tr1 does seem to contain an
iostream header which your #include iostream probably
picks up.
Maybe that further includes the other boost headers?
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] depend.make
Very interesting.
Found this thread where Brad King is saying more or less the same thing (this
is in 2009). Can anyone confirm this is still the case?
How can we filter out boost from depend.make? Using include_regular_expression
only allows files filtering and that does not really help in this case.
Regards,
Lars
From: marco.clemen...@cern.ch
To: cmake@cmake.org
CC: laasu...@hotmail.com; nilsglad...@gmail.com
Subject: Re: [CMake] depend.make
Date: Thu, 12 Dec 2013 12:03:06 +0100
Hi,
I cannot find it anymore in the documentation , but I remember to have read
that the dependency scanner of CMake does not take into account the
preprocessor conditionals (#ifdef, etc), thus producing a superset of the
actual dependencies.
It is quite probable that boost/tr1/iostream _may_ include the other headers
under some particular combination of preprocessor macros, so they are not
used
at compile time, but they taken into account by CMake.
Cheers
Marco
On Thursday 12 December 2013 11:51:52 Lars wrote:
Thank you for your feedback.
This however only explain part of the issue as far as I can tell. To debug
the issue I added #pragma message(boost tr1 iostream)
at the top of the boost/tr1/iostream file. When building the source that
message is shown in the console windows which then indicate the compiler
has accessed the file. So far so good. I then did the same trick with
boost/aligned_storage.hpp, boost/array.hpp and boost/assert.hpp which are
the three first boost reference in depend.make and none of them not show up
during building.
So why are these files included in the depend.make?
Regards,
Lars
Date: Wed, 11 Dec 2013 16:08:28 +0100
From: nilsglad...@gmail.com
To: laasu...@hotmail.com; cmake@cmake.org
Subject: Re: [CMake] depend.make
On 11.12.2013 12:53, Lars wrote:
Here is the source code used (which does not use the Boost
library).
#include iostream
int main(int argc, char **argv)
{
std::cout Hello world std::endl;
return 0;
}
${Boost_INCLUDE_DIR}/boost/tr1/tr1 does seem to contain an
iostream header which your #include iostream probably
picks up.
Maybe that further includes the other boost headers?
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] depend.make
Here is the link: http://www.itk.org/Bug/print_bug_page.php?bug_id=8561
From: laasu...@hotmail.com
To: marco.clemen...@cern.ch; cmake@cmake.org
Date: Thu, 12 Dec 2013 13:58:36 +0100
Subject: Re: [CMake] depend.make
Very interesting.
Found this thread where Brad King is saying more or less the same thing (this
is in 2009). Can anyone confirm this is still the case?
How can we filter out boost from depend.make? Using include_regular_expression
only allows files filtering and that does not really help in this case.
Regards,
Lars
From: marco.clemen...@cern.ch
To: cmake@cmake.org
CC: laasu...@hotmail.com; nilsglad...@gmail.com
Subject: Re: [CMake] depend.make
Date: Thu, 12 Dec 2013 12:03:06 +0100
Hi,
I cannot find it anymore in the documentation , but I remember to have read
that the dependency scanner of CMake does not take into account the
preprocessor conditionals (#ifdef, etc), thus producing a superset of the
actual dependencies.
It is quite probable that boost/tr1/iostream _may_ include the other headers
under some particular combination of preprocessor macros, so they are not
used
at compile time, but they taken into account by CMake.
Cheers
Marco
On Thursday 12 December 2013 11:51:52 Lars wrote:
Thank you for your feedback.
This however only explain part of the issue as far as I can tell. To debug
the issue I added #pragma message(boost tr1 iostream)
at the top of the boost/tr1/iostream file. When building the source that
message is shown in the console windows which then indicate the compiler
has accessed the file. So far so good. I then did the same trick with
boost/aligned_storage.hpp, boost/array.hpp and boost/assert.hpp which are
the three first boost reference in depend.make and none of them not show up
during building.
So why are these files included in the depend.make?
Regards,
Lars
Date: Wed, 11 Dec 2013 16:08:28 +0100
From: nilsglad...@gmail.com
To: laasu...@hotmail.com; cmake@cmake.org
Subject: Re: [CMake] depend.make
On 11.12.2013 12:53, Lars wrote:
Here is the source code used (which does not use the Boost
library).
#include iostream
int main(int argc, char **argv)
{
std::cout Hello world std::endl;
return 0;
}
${Boost_INCLUDE_DIR}/boost/tr1/tr1 does seem to contain an
iostream header which your #include iostream probably
picks up.
Maybe that further includes the other boost headers?
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Organizing source files in XCode project to match directory layout
Hi, I recently ported a relatively small project (https://github.com/kpu/kenlm) to CMake. When I use the Unix Makefile generator, everything works well as expected. Unfortunately, when I use the XCode generator, I'm having difficulty getting the files within the XCode project organized in the desired manner. My goal is to have the layout of files in the XCode project match the layout of directories and files on disk. I have so far been unable to figure out how to do so. The directory structure is described briefly below. I would appreciate any guidance that anyone might have. The project has two directories (lm and util), and each of those directories contains two subdirectories. Each directory and subdirectory has a CMakeLists.txt file. Each directory contains a number of source and header files; these files are organized within the CMakeLists.txt files into object libraries using add_library(foo OBJECT ...). Some of the directories also contain one or more *_main.cc files (each of these gets compiled into an executable), and one or more *_test.cc files (each of these gets compiled into a unit test executable). When I use CMake to generate an XCode project, the XCode project contains a Sources directory. Under Sources, there is one directory for each executable, one directory for each unit test, and one directory for each object library. Each of those directories are further divided into a Source Files subdirectory, an Object Files subdirectory, and a CMakeFiles.txt file. Additionally, the Sources directory also contains three additional subdirectories: ALL_BUILD, CTestDashboardTarget, and ZERO_CHECK. kenlm/ Sources/ ALL_BUILD/ CTestDashBoardTarget/ ZERO_CHECK/ bit_packing_test/ file_piece_test/ ... kenlm_util ... query/ filter/ Source Files/ Object Files/ CMakeLists.txt ... By using set_target_properties(... PROPERTIES FOLDER ...), I have been able to group some of the directories (the unit tests and the executables) together, like so: kenlm/ Sources/ ALL_BUILD/ CTestDashBoardTarget/ ZERO_CHECK/ unit_tests/ bit_packing_test/ file_piece_test/ ... kenlm_util ... executables/ query/ filter/ Source Files/ Object Files/ CMakeLists.txt ... By additionally using source_group( ... FILES ...) I have been able to rename any of the Source Files/ subdirectories. For example, I can go from this: kenlm/ executables/ filter/ Source Files/ Object Files/ CMakeLists.txt To this: kenlm/ executables/ filter/ my_custom_src_name/ Object Files/ CMakeLists.txt I want the XCode project to look more or less just like the actual directory layout: kenlm/ Sources/ lm/ *.cc *.hh builder/ *.cc *.hh filter/ *.cc *.hh util/ *.cc *.hh double_conversion/ *.cc *.hh stream/ *.cc *.hh Based on other threads and bug reports that I've found online, I suspect that this should be doable using source_group( ... FILES ...) and/or set_target_properties(... PROPERTIES FOLDER ...), but I so far haven't been able to figure out how. Any advice or tips would be greatly appreciated. Thanks, Lane -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] depend.make
On 12/12/2013 8:17 AM, Lars wrote: Here is the link: http://www.itk.org/Bug/print_bug_page.php?bug_id=8561 Is this causing you a problem?If there are some extra depends on boost files what is the harm? I am assuming that you are not changing them that much... You could also try the ninja generator that does the depends different and is faster anyway... -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Testing for a target broke for me
I've had this working and I don't *THINK* I changed anything that would cause it to fail now but I'm not completely sure. I have a project I converted over to cmake from automake which requires wxWidgets 3.0 (or the 2.9 devel branch). Although it just released I still want to maintain the ability to build it within the project itself for distro's that are slow to adopt it (on linux) or windows/mac as well. Because wxWidgets uses a custom script to get compiler flags and includes I have to bootstrap the build such that the first time you run cmake/make it builds wxWidgets and the second time it builds the project. To that end I had the follow strategy working: # # Pull in external wxWidgets target if performing static build. # if(BOOTSTRAP_WXWIDGETS) include(cmake/BuildWxWidgets.cmake) endif(BOOTSTRAP_WXWIDGETS) # # Perform bootstrap build of wxWidgets # if(BOOTSTRAP_WXWIDGETS AND NOT TARGET wxWidgets) message(STATUS Will perform bootstrap build of wxWidgets. After make step completes, re-run cmake and make again to perform FreeDV build.) # # Continue normal build if not bootstrapping wxWidgets or already built it. # else(BOOTSTRAP_WXWIDGETS AND NOT TARGET wxWidgets) continue normal build endif(BOOTSTRAP_WXWIDGETS AND NOT TARGET wxWidgets) --- Even though I can verify that BOOTSTRAP_WXWIDGETS is true, it's failing the conditional and I can only assume it has to do with the target checking. Any ideas? Thanks, Richard -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Testing for a target broke for me
This is a case for ExternalProjects. http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html Also search for 'cmake superbuild' for discussion of how people are using external projects. An example build setup for prerequisites/projects here: https://github.com/BRAINSia/NamicExternalProjects -- Kent Williams norman-k-willi...@uiowa.edu On 12/12/13 10:31 AM, Richard Shaw hobbes1...@gmail.com wrote: I've had this working and I don't *THINK* I changed anything that would cause it to fail now but I'm not completely sure. I have a project I converted over to cmake from automake which requires wxWidgets 3.0 (or the 2.9 devel branch). Although it just released I still want to maintain the ability to build it within the project itself for distro's that are slow to adopt it (on linux) or windows/mac as well. Because wxWidgets uses a custom script to get compiler flags and includes I have to bootstrap the build such that the first time you run cmake/make it builds wxWidgets and the second time it builds the project. To that end I had the follow strategy working: # # Pull in external wxWidgets target if performing static build. # if(BOOTSTRAP_WXWIDGETS) include(cmake/BuildWxWidgets.cmake) endif(BOOTSTRAP_WXWIDGETS) # # Perform bootstrap build of wxWidgets # if(BOOTSTRAP_WXWIDGETS AND NOT TARGET wxWidgets) message(STATUS Will perform bootstrap build of wxWidgets. After make step completes, re-run cmake and make again to perform FreeDV build.) # # Continue normal build if not bootstrapping wxWidgets or already built it. # else(BOOTSTRAP_WXWIDGETS AND NOT TARGET wxWidgets) continue normal build endif(BOOTSTRAP_WXWIDGETS AND NOT TARGET wxWidgets) --- Even though I can verify that BOOTSTRAP_WXWIDGETS is true, it's failing the conditional and I can only assume it has to do with the target checking. Any ideas? Thanks, Richard Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] depend.make
Building our software using CMake and VS2005 on Windows platform is very slow. Debugging this issue I discovered the several of the depent.make files are huge. One example is a depent.make file that is roughly 10 MB. In this file most of the object files dependent on almost all boost header files. I am guessing a huge depent.make file would affect at least dependency scanning. Obviously I do not know how much this affect performance. Will take a look at ninja. Any other suggestions? Regards,Lars Date: Thu, 12 Dec 2013 11:14:29 -0500 From: bill.hoff...@kitware.com To: cmake@cmake.org Subject: Re: [CMake] depend.make On 12/12/2013 8:17 AM, Lars wrote: Here is the link: http://www.itk.org/Bug/print_bug_page.php?bug_id=8561 Is this causing you a problem?If there are some extra depends on boost files what is the harm? I am assuming that you are not changing them that much... You could also try the ninja generator that does the depends different and is faster anyway... -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] depend.make
On 12/12/2013 1:07 PM, Lars wrote: Building our software using CMake and VS2005 on Windows platform is very slow. Debugging this issue I discovered the several of the depent.make files are huge. One example is a depent.make file that is roughly 10 MB. In this file most of the object files dependent on almost all boost header files. I am guessing a huge depent.make file would affect at least dependency scanning. Obviously I do not know how much this affect performance. Will take a look at ninja. Any other suggestions? You could do this: include_regular_expression(^([^b]|b[^o]|bo[^o]|boo[^s]|boos[^t]|boost[^/]).*$) Then see if it impacts your performance. I would be interested to here if it did or did not. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Testing for a target broke for me
On Thu, Dec 12, 2013 at 11:20 AM, Williams, Norman K norman-k-willi...@uiowa.edu wrote: This is a case for ExternalProjects. http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html I've read that before but didn't find anything new there. I also tried checking the state of BOOTSTRAP_WXWIDGETS and the target separately and both individually seem to test correctly. It seems the problem is: if(BOOTSTRAP_WXWIDGETS AND NOT TARGET wxWidgets) though I don't see anything semantically wrong with it. Also search for 'cmake superbuild' for discussion of how people are using external projects. An example build setup for prerequisites/projects here: https://github.com/BRAINSia/NamicExternalProjects Very interesting but not quite what I'm looking for, in this case the main CMakeLists.txt does actually build a project, I just need it to build wxWidgets first. Thanks, Richard -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cannot set CMP0022 to OLD
Hi, I've been quite annoyed by the warnings from CMP0022 in a project I use ( http://quickgit.kde.org/?p=kdevplatform.git) and wanted to set the policy to OLD to hide the warnings (porting the code is not an option as that would require to enforce CMake 2.8.11 which is too new for this project). Unfortunately no matter where I put either a cmake_policy(VERSION 2.8.6) or even cmake_policy(SET CMP0022 OLD) I still get the warnings all the time. I'm using CMake 2.8.12.1 here and was wondering wether anybody else run into this already? I've tried to come up with a small example, but can't seem to get it to trigger the CMP warning at all. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Testing for a target broke for me
On 12/12/13 2:13 PM, Richard Shaw
hobbes1...@gmail.commailto:hobbes1...@gmail.com wrote:
Very interesting but not quite what I'm looking for, in this case the main
CMakeLists.txt does actually build a project, I just need it to build wxWidgets
first.
Well it's up to you but 'build X and then build Y' is the definition of how
using ExternalProject work.
What you describe doesn't seem like it would ever work, because the CMake
source code is evaluated at Configuration time, not compile time. How is
wxWidgets a target? Do you have an ADD_CUSTOM_TARGET command somewhere? You
might have had it accidentally work because of how variables persist between
make/configure runs in CMakeCache.txt, but I don't see how it could ever be
dependable or predictable.
if(BOOTSTRAP_WXWIDGETS AND NOT TARGET wxWidgets)
message(Build wxWidgets)
else()
message(Doing normal build)
endif()
The CMake code below would do what you want to do. It builds wxWindows, and
then builds your project.
project(TWOSTAGE)
include(ExternalProject)
if(NOT BUILD_MY_PROJECT) # starts out un-set/false at top level build dir
include(cmake/BuildWxWidgets.cmake)
# your project builds in a subdirectory of the top level build dir
ExternalProject_add(MyActualProject
DOWNLOAD_COMMAND
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/MyActualProject-build
CMAKE_ARGS
-DBUILD_MY_PROJECT:BOOL=TRUE
all relevant cmake args, including where to find wxWindows
libs/include
INSTALL_COMMAND # presumably you don't want to install immediately.
)
else()
normal build stuff, depending on WxWidgets
endif()
Notice: This UI Health Care e-mail (including attachments) is covered by the
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and
may be legally privileged. If you are not the intended recipient, you are
hereby notified that any retention, dissemination, distribution, or copying of
this communication is strictly prohibited. Please reply to the sender that you
have received the message in error, then delete it. Thank you.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6200-gb692db5
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 b692db5561a0cbecfacfcc468b70b9798016ade7 (commit)
via 5e96322fcf2808e2e68e15ab7a5b23b612ca269a (commit)
from 58a99f40bb9ee6cc5cb0b85b700733cc14cc3788 (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=b692db5561a0cbecfacfcc468b70b9798016ade7
commit b692db5561a0cbecfacfcc468b70b9798016ade7
Merge: 58a99f4 5e96322
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Dec 12 06:54:02 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Dec 12 06:54:02 2013 -0500
Merge topic 'GenerateExportHeader-tests' into next
5e96322 Maybe fix MSVC6.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5e96322fcf2808e2e68e15ab7a5b23b612ca269a
commit 5e96322fcf2808e2e68e15ab7a5b23b612ca269a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Dec 12 12:51:13 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Dec 12 12:53:21 2013 +0100
Maybe fix MSVC6.
diff --git a/Tests/Module/GenerateExportHeader/exportheader_test.cpp
b/Tests/Module/GenerateExportHeader/exportheader_test.cpp
index e5f30fa..146374a 100644
--- a/Tests/Module/GenerateExportHeader/exportheader_test.cpp
+++ b/Tests/Module/GenerateExportHeader/exportheader_test.cpp
@@ -13,7 +13,7 @@
#include fstream
#include iostream
-#include cstdlib
+#include stdlib.h
#include string
void compare(const char* refName, const char* testName)
@@ -23,7 +23,7 @@ void compare(const char* refName, const char* testName)
if (!ref.is_open())
{
std::cout Could not open \ refName \. std::endl;
-std::exit(1);
+exit(1);
}
std::ifstream test;
test.open(testName);
---
Summary of changes:
.../GenerateExportHeader/exportheader_test.cpp |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6202-g6da6fa0
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 6da6fa0023c4aa0a93a6d073bd13c7f343684126 (commit)
via 3e97bcb1ef18c7b1e16f81733896764bfd8178aa (commit)
from b692db5561a0cbecfacfcc468b70b9798016ade7 (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=6da6fa0023c4aa0a93a6d073bd13c7f343684126
commit 6da6fa0023c4aa0a93a6d073bd13c7f343684126
Merge: b692db5 3e97bcb
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Dec 12 12:23:01 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Dec 12 12:23:01 2013 -0500
Merge topic 'Qt4-NO_DEBUG-define' into next
3e97bcb Use a config-specific moc parameters file, if needed.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3e97bcb1ef18c7b1e16f81733896764bfd8178aa
commit 3e97bcb1ef18c7b1e16f81733896764bfd8178aa
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Dec 12 18:22:17 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Dec 12 18:22:17 2013 +0100
Use a config-specific moc parameters file, if needed.
diff --git a/Modules/Qt4Macros.cmake b/Modules/Qt4Macros.cmake
index b5f005f..fd9819f 100644
--- a/Modules/Qt4Macros.cmake
+++ b/Modules/Qt4Macros.cmake
@@ -120,6 +120,7 @@ macro (QT4_CREATE_MOC_COMMAND infile outfile moc_flags
moc_options moc_target)
string (REPLACE ; \n _moc_parameters ${_moc_parameters})
if(moc_target)
+set (_moc_parameters_file
${_moc_parameters_file}$$BOOL:$CONFIGURATION:_$CONFIGURATION)
set(targetincludes $TARGET_PROPERTY:${moc_target},INCLUDE_DIRECTORIES)
set(targetdefines $TARGET_PROPERTY:${moc_target},COMPILE_DEFINITIONS)
---
Summary of changes:
Modules/Qt4Macros.cmake |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12.1-908-g5e43d6d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 5e43d6d3d0285901af816ab1ed37563ea00eaf21 (commit) from edaef237bf90b5e6af095883370d0f490d13c844 (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=5e43d6d3d0285901af816ab1ed37563ea00eaf21 commit 5e43d6d3d0285901af816ab1ed37563ea00eaf21 Author: Kitware Robot kwro...@kitware.com AuthorDate: Fri Dec 13 00:01:07 2013 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Fri Dec 13 00:01:07 2013 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7943fb7..8ae87ef 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 12) -set(CMake_VERSION_TWEAK 20131212) +set(CMake_VERSION_TWEAK 20131213) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
