[cmake-developers] [CMake 0012531]: Lintain failures due to permission issues with pre/post install/remove scripts.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12531 == Reported By:Philip Schwartz Assigned To: == Project:CMake Issue ID: 12531 Category: CPack Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-10-21 10:22 EDT Last Modified: 2011-10-21 10:22 EDT == Summary:Lintain failures due to permission issues with pre/post install/remove scripts. Description: When a Deb created with CPack and CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA is set to point to a preinst, postinst, prerm, postrm, Lintain reports package errors when installed from the Ubuntu Software Center. E: hpccsystems-platform: control-file-has-bad-owner md5sums phschwartz/phschwartz != root/root E: hpccsystems-platform: control-file-has-bad-owner postinst phschwartz/phschwartz != root/root E: hpccsystems-platform: control-file-has-bad-owner postrm phschwartz/phschwartz != root/root E: hpccsystems-platform: control-file-has-bad-owner prerm phschwartz/phschwartz != root/root When building in the fakeroot in 2.8.5 and 2.8.6, these files should be set when copied by CPack to root/root in order to not violate the Debian Policy settings as defined in Lintain. This can be seen in the building of the HPCC platform from HPCCSystems. Source http://github.com/hpcc-systems/HPCC-Platform == Issue History Date ModifiedUsername FieldChange == 2011-10-21 10:22 Philip SchwartzNew 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
[cmake-developers] [CMake 0012532]: Defining different settings for different configurations in Xcode (4.0.2) generator
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12532
==
Reported By:Daniel Dekkers
Assigned To:
==
Project:CMake
Issue ID: 12532
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2011-10-21 12:53 EDT
Last Modified: 2011-10-21 12:53 EDT
==
Summary:Defining different settings for different
configurations in Xcode (4.0.2) generator
Description:
Setting properties with the [variant=] construction in SET_TARGET_PROPERTIES()
gives unexpected results.
Steps to Reproduce:
As an example:
SET_TARGET_PROPERTIES( ${APP_NAME} PROPERTIES
XCODE_ATTRIBUTE_CODE_SIGN_ENTITLEMENTS[variant=Debug] EntitlementsDebug.plist
)
SET_TARGET_PROPERTIES( ${APP_NAME} PROPERTIES
XCODE_ATTRIBUTE_CODE_SIGN_ENTITLEMENTS[variant=Release]
EntitlementsAdHoc.plist )
Will fill both configurations (Debug and Release) with both settings
(EntitlementsDebug.plist and EntitlementsAdHoc.plist).
Additional Information:
The [variant=] construction is undocumented, apart from the bug tracker.
Related to...
http://www.cmake.org/Bug/view.php?id=11667
http://www.cmake.org/Bug/view.php?id=8179
==
Issue History
Date ModifiedUsername FieldChange
==
2011-10-21 12:53 Daniel Dekkers 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] Bug fix requests for the *next* release of CMake...
As an esteemed colleague has pointed out, those with reporter level account in Mantis may not edit bugs other than their own directly. So. if you are in that boat, but would like to vote for a bug fix to be considered for 2.8.7, please reply to this thread, and just list the bug number, or a URL linking to its bug tracker page. I will follow the replies to this thread and add those bugs to the roadmap as they roll in. Thanks, David C. On Fri, Oct 21, 2011 at 12:19 PM, David Cole david.c...@kitware.com wrote: Hi all, *NO* replies requested. Different technique this time. Please edit the bug tracker directly. (Unless you have problems with the bug tracker: if so, please feel free to reply here with your suggestions.) We are planning for CMake 2.8.7, aiming for a December release. We're targeting Dec. 28, 2011 for releasing it, and in order to make that happen we'll have to do an rc1 by Dec. 7th or so... about 7 weeks from now. If you have a particular issue that you think should be fixed for inclusion in 2.8.7, please put it on the roadmap yourself by the end of next week, Fri. Oct. 28th. To do so, edit the bug at http://public.kitware.com/Bug and set the Target Version field to CMake 2.8.7 - that will make it appear on the roadmap page ( http://www.cmake.org/Bug/roadmap_page.php?version_id=89 ). Also: add a note saying why it's important to you, or even add a patch that fixes and documents and tests it if you're able to. 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 the 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 are better: a patch with testing is strongly 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 on the mailing list as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.7 -- we will be looking at activity both on the mailing list and in the bug tracker to help prioritize the bug fixes for the next couple months. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.6 release, including contributions from 27 individuals around the world, see here: http://public.kitware.com/Bug/changelog_page.php?version_id=87 -- it currently lists 43 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.5... 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Windows 8 and Visual Studio 2011 Developer Preview cannot open cmake-generated vcproj files
On 10/20/2011 6:56 PM, David Cole wrote: It's not a Windows 8 thing at all... Same symptom occurs on Windows 7. It's CMake generating this incorrectly: # Visual Studio 2011 When it should be generating: # Visual Studio 11 Since the comment there does not start with the expected string, the launcher does not recognize it. This commit just pushed to 'next' should fix it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0d66ab40aee3af3d201201e7b1275783ffbab36 That commit will make it into the next rev of CMake. So, you should be able to build if you open VS 11, and then use File open and find the .sln file that CMake created. It just won't work from explorer by double clicking. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom_command question
Hi all, with cmake 2.8.6 all my problems are solved, I'm can easily recreate/replicate custom_target. Thanks a lot! Best regards Lukasz -- 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] RC compiler on Linux
Hi all, I use CMake 2.8.5 on Linux and Windows machine to build a Fortran project. On Windows, no problem, the build and the resulting GUI are OK. On Linux, the build seems to be OK but the resulting GUI gives an empty screen. Discussing with Michael a few days ago made me think that it could be related to the use of an inappropriated motif library. However, looking in more details I see with a make VERBOSE=1 that my rc file is not built (I do not see the line Building RC object ...). even if it is declared as one of my sources files. Is there some extra commands to specify to make cmake recognize and compile a rc file ? thanks Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Include source files on a per-configuration basis
On 10/06/2011 10:29 AM, Michael Wild wrote:
On 10/06/2011 08:14 AM, Michael Hertling wrote:
On 10/06/2011 07:04 AM, Michael Wild wrote:
On Thu 06 Oct 2011 05:17:00 AM CEST, Michael Hertling wrote:
On 10/05/2011 10:47 PM, Robert Dailey wrote:
In my particular CMake project, I have three CPP files:
a.cpp
b.cpp
c.cpp
I want 'a.cpp' to be compiled in all configurations (release debug).br
I only want 'b.cpp' to be compiled in DEBUG configuration.br
I only want 'c.cpp' to be compiled in RELEASE configuration.
How can I do this? I need something similar to the `debug` and `optimized`
keywords that are accepted by the `target_link_libraries()` CMake
operation.
If it's okay that b.cpp and c.cpp are compiled in all configurations but
incorporated in the final binaries only in the DEBUG or in the RELEASE
configuration, respectively, you might do the following:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(IMPORTEDEMPTY C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# Add library for DEBUG:
FILE(WRITE ${CMAKE_BINARY_DIR}/b.c void b(void){}\n)
ADD_LIBRARY(b STATIC b.c)
# Add library for RELEASE:
FILE(WRITE ${CMAKE_BINARY_DIR}/c.c void c(void){}\n)
ADD_LIBRARY(c STATIC c.c)
# Add empty static library:
FILE(WRITE ${CMAKE_BINARY_DIR}/empty.c )
ADD_LIBRARY(empty STATIC empty.c)
# Reimport empty static library:
EXPORT(TARGETS empty NAMESPACE imported FILE importedempty.cmake)
INCLUDE(${CMAKE_BINARY_DIR}/importedempty.cmake)
# Impose IMPORTED_LINK_INTERFACE_LIBRARIES_{DEBUG,RELEASE} properties:
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES ITEMS ${CMAKE_BUILD_TYPE})
STRING(TOUPPER ${i} i)
IF(i STREQUAL DEBUG)
SET_TARGET_PROPERTIES(importedempty PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_${i} b)
ELSEIF(i STREQUAL RELEASE)
SET_TARGET_PROPERTIES(importedempty PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_${i} c)
ENDIF()
ENDFOREACH()
# Specify required dependencies:
ADD_DEPENDENCIES(importedempty empty b c)
# Add final binary:
FILE(WRITE ${CMAKE_BINARY_DIR}/a.c int main(void){return 0;}\n)
ADD_EXECUTABLE(a a.c)
TARGET_LINK_LIBRARIES(a importedempty)
Adventurous, but somewhat clean; see [1] for an explanation, and be
especially careful with a file named libc.a on *nix systems. ;-)
If you really need to avoid the compilation of b.cpp or c.cpp in
certain configurations, you might try the following approach:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RECONF C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/a.c int main(void){return 0;}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/b.c void b(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/c.c void c(void){}\n)
STRING(TOUPPER ${CONF} CONF)
IF(CONF STREQUAL DEBUG)
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c b.c)
ELSEIF(CONF STREQUAL RELEASE)
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c c.c)
ELSE()
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c)
ENDIF()
ADD_CUSTOM_TARGET(a ALL
COMMAND ${CMAKE_COMMAND}
-DCONF=$CONFIGURATION
${CMAKE_BINARY_DIR}
COMMAND ${CMAKE_COMMAND}
--build ${CMAKE_BINARY_DIR}
--config $CONFIGURATION
--target a0)
Effectively, when target a is built, the project reconfigures itself
with the current configuration passed in via CONF and with a helper
target a0 which is made up from the configuration-specific sources;
finally, this target a0 is built with the current configuration.
This can be seen working on *nix with Makefiles, but there might
be issues with other generators and IDEs.
'hope that helps.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34680.html
I think it would be much easier to have a wrapper file, say b_or_c.cpp
which #include's b.cpp or c.cpp at compile time depending on the current
configuration. E.g. like this:
///
#if defined USE_B_CPP
# include b.cpp
#elseif defined USE_C_CPP
# include c.cpp
#else // what should happen otherwise?
# error Either USE_B_CPP or USE_C_CPP must be defined!
#endif
///
And then in your CMakeLists.txt you do:
###
set_source_files_properties(b_or_c.cpp PROPERTIES
COMPILE_DEFINITIONS_DEBUG USE_B_CPP
COMPILE_DEFINITIONS_RELEASE USE_C_CPP
# what should happen in a default build?
# Or RELWITHDEBINFO and MINSIZEREL?
)
###
Yes, this would work, too, but if neither b.cpp nor c.cpp should be
compiled if the current configuration is neither DEBUG nor RELEASE,
the b_or_c.cpp file would be effectively empty, and adding an object
file compiled from an empty source file to a binary is not 100 % the
same as dropping the object file completely - at least with gcc and
even with -Os. However, it's a quite negligible effect, but linking
[CMake] Bug fix requests for the *next* release of CMake...
Hi all, *NO* replies requested. Different technique this time. Please edit the bug tracker directly. (Unless you have problems with the bug tracker: if so, please feel free to reply here with your suggestions.) We are planning for CMake 2.8.7, aiming for a December release. We're targeting Dec. 28, 2011 for releasing it, and in order to make that happen we'll have to do an rc1 by Dec. 7th or so... about 7 weeks from now. If you have a particular issue that you think should be fixed for inclusion in 2.8.7, please put it on the roadmap yourself by the end of next week, Fri. Oct. 28th. To do so, edit the bug at http://public.kitware.com/Bug and set the Target Version field to CMake 2.8.7 - that will make it appear on the roadmap page ( http://www.cmake.org/Bug/roadmap_page.php?version_id=89 ). Also: add a note saying why it's important to you, or even add a patch that fixes and documents and tests it if you're able to. 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 the 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 are better: a patch with testing is strongly 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 on the mailing list as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.7 -- we will be looking at activity both on the mailing list and in the bug tracker to help prioritize the bug fixes for the next couple months. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.6 release, including contributions from 27 individuals around the world, see here: http://public.kitware.com/Bug/changelog_page.php?version_id=87 -- it currently lists 43 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.5... 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
Re: [CMake] RC compiler on Linux - new problem
Hi all, after digging and googling some hours I did a first step in the right direction. I had to add the command: enable_language(rc) set(cmake_rc_compiler_arg1 -cif8) The resource compiler I (must) use is the one provided by winteracter Fortran library. This led me to a serie of problems related to the use of this compiler: - it does not accept any output flag so that the output resource object is always created in-source in the rc file directory. - on Linux, it produces a .o object file instead of a .res file Looking at the CMakeRCInformation.cmake I see that by construction CMake will use the following compile command: CMAKE_RC_COMPILER FLAGS DEFINES /foOBJECT SOURCE with a resource object file with a .res extension. On a Linux machine, this produces a wrong build command line with the path for the output object file being /foCMakeFiles/ This problem was raised sometime ago in the mantis bug tracker but unfortunatley the patch proposed apply for mingw using windres but not for Linux. Is there a fix for this ? If no, is there a way to inform the linker that: - my resource object file is located in-source - the extension is not .res but .o thanks for your help Eric pellegrini a écrit : Hi all, I use CMake 2.8.5 on Linux and Windows machine to build a Fortran project. On Windows, no problem, the build and the resulting GUI are OK. On Linux, the build seems to be OK but the resulting GUI gives an empty screen. Discussing with Michael a few days ago made me think that it could be related to the use of an inappropriated motif library. However, looking in more details I see with a make VERBOSE=1 that my rc file is not built (I do not see the line Building RC object ...). even if it is declared as one of my sources files. Is there some extra commands to specify to make cmake recognize and compile a rc file ? thanks Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake, eclipse, and multiple projects
On Friday 21 October 2011, Dan Kegel wrote: Where I work, a lot of people use Eclipse, a few people use Xcode, a few people use Visual Studio, and a few people use vi and the commandline. (I'm in the latter camp, and have only moderate familiarity with IDEs.) Each camp seems to have a different way of building the same code. Naturally, the thought of unifying build systems with cmake was attractive, so I picked up cmake and got one little corner of the world building with it. The project is structured as several artifacts (executables and shared libraries), each with its own versioned subversion tree. This seemed odd to me until I realized it's probably the way Eclipse users think: each artifact's source should be its own project, with its own little repository. [See rant 1] Initially, I had a separate CMakeLists.txt for each artifact, and used find_package() to locate the other artifacts needed to build the current one. But that left me with no overall way to build the whole project from the commandline, so I switched to having an outer CMakeList.txt that included all the others. That works great... until you think about how the Eclipse users are going to use it. Now, I haven't tried generating an Eclipse project from cmake yet, but I suspect it's going to generate a single .project/.cproject pair no matter how many executables and shared libraries it builds. Yes. With 2.8.6, in the Makefile targets tab you get clickable items for each target (executable, library, etc.), so there they can build just what they want. In 2.8.7, there will be additionally a Targets virtual folder, which will have a flat list of all targets, and under each targets its source files. This should make for easier editing. On the cmake-developers list there was recently somebody working on generating multiple .project/.cproject files. But I didn't here from hin again since May now already. IIRC his work required an additional plugin for Eclipse, to be able to import multiple projects at once. If you're interested, you can have a look. (it was in april, subject Better Eclipse CDT support): http://www.cmake.org/pipermail/cmake-developers/2011-April/thread.html http://www.cmake.org/pipermail/cmake-developers/2011-May/thread.html Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
As an esteemed colleague has pointed out, those with reporter level account in Mantis may not edit bugs other than their own directly. So. if you are in that boat, but would like to vote for a bug fix to be considered for 2.8.7, please reply to this thread, and just list the bug number, or a URL linking to its bug tracker page. I will follow the replies to this thread and add those bugs to the roadmap as they roll in. Thanks, David C. On Fri, Oct 21, 2011 at 12:19 PM, David Cole david.c...@kitware.com wrote: Hi all, *NO* replies requested. Different technique this time. Please edit the bug tracker directly. (Unless you have problems with the bug tracker: if so, please feel free to reply here with your suggestions.) We are planning for CMake 2.8.7, aiming for a December release. We're targeting Dec. 28, 2011 for releasing it, and in order to make that happen we'll have to do an rc1 by Dec. 7th or so... about 7 weeks from now. If you have a particular issue that you think should be fixed for inclusion in 2.8.7, please put it on the roadmap yourself by the end of next week, Fri. Oct. 28th. To do so, edit the bug at http://public.kitware.com/Bug and set the Target Version field to CMake 2.8.7 - that will make it appear on the roadmap page ( http://www.cmake.org/Bug/roadmap_page.php?version_id=89 ). Also: add a note saying why it's important to you, or even add a patch that fixes and documents and tests it if you're able to. 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 the 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 are better: a patch with testing is strongly 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 on the mailing list as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.7 -- we will be looking at activity both on the mailing list and in the bug tracker to help prioritize the bug fixes for the next couple months. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.6 release, including contributions from 27 individuals around the world, see here: http://public.kitware.com/Bug/changelog_page.php?version_id=87 -- it currently lists 43 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.5... 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
[CMake] Custom target with just cmake files in it
I have a folder with a bunch of cmake modules in it that contain my custom CMake code used across all projects. I only generate for visual studio, so I was thinking it would be useful to have a dummy project in my solution named _cmake that contains nothing but my *.cmake files in it. How would I create such a project? It needs to show up in ANY solution opened that is generated at any level via call to project(). - Robert Dailey -- 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] Precompiled header support in Visual Studio?
I did some searching and on stackoverflow I found a post that had code in it
to provide precompiled header support:
http://stackoverflow.com/questions/148570/using-pre-compiled-headers-with-cmake
Below is the relevant macro I am using from that post. Unfortunately this
does not seem to work when generating for VS2008 or VS 2003. For some reason
the CPP files other than the precompiled source itself do not have the
Using precompiled headers option set on them when I view that file's
properties.
What improvements could be made to this macro? I'm not familiar at all with
the command line parameters so I'm hoping someone can help me out.
macro( set_precompiled_header pch_header pch_source source )
IF(MSVC)
GET_FILENAME_COMPONENT(PrecompiledBasename ${PrecompiledHeader} NAME_WE)
SET(PrecompiledBinary
${CMAKE_CURRENT_BINARY_DIR}/${PrecompiledBasename}.pch)
SET(Sources ${${SourcesVar}})
SET_SOURCE_FILES_PROPERTIES(${PrecompiledSource}
PROPERTIES COMPILE_FLAGS
/Yc\${PrecompiledHeader}\ /Fp\${PrecompiledBinary}\
OBJECT_OUTPUTS
${PrecompiledBinary})
SET_SOURCE_FILES_PROPERTIES(${Sources}
PROPERTIES COMPILE_FLAGS
/Yu\${PrecompiledBinary}\ /FI\${PrecompiledBinary}\
/Fp\${PrecompiledBinary}\
OBJECT_DEPENDS
${PrecompiledBinary})
ENDIF(MSVC)
endmacro()
-
Robert Dailey
--
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...
Yes, me - http://public.kitware.com/Bug/view.php?id=12532 Don't think as a reporter you can even edit your own bug entries after committing them. Or I'm missing a button somewhere. Op 21 okt. 2011 om 20:20 heeft David Cole david.c...@kitware.com het volgende geschreven: As an esteemed colleague has pointed out, those with reporter level account in Mantis may not edit bugs other than their own directly. So. if you are in that boat, but would like to vote for a bug fix to be considered for 2.8.7, please reply to this thread, and just list the bug number, or a URL linking to its bug tracker page. I will follow the replies to this thread and add those bugs to the roadmap as they roll in. Thanks, David C. On Fri, Oct 21, 2011 at 12:19 PM, David Cole david.c...@kitware.com wrote: Hi all, *NO* replies requested. Different technique this time. Please edit the bug tracker directly. (Unless you have problems with the bug tracker: if so, please feel free to reply here with your suggestions.) We are planning for CMake 2.8.7, aiming for a December release. We're targeting Dec. 28, 2011 for releasing it, and in order to make that happen we'll have to do an rc1 by Dec. 7th or so... about 7 weeks from now. If you have a particular issue that you think should be fixed for inclusion in 2.8.7, please put it on the roadmap yourself by the end of next week, Fri. Oct. 28th. To do so, edit the bug at http://public.kitware.com/Bug and set the Target Version field to CMake 2.8.7 - that will make it appear on the roadmap page ( http://www.cmake.org/Bug/roadmap_page.php?version_id=89 ). Also: add a note saying why it's important to you, or even add a patch that fixes and documents and tests it if you're able to. 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 the 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 are better: a patch with testing is strongly 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 on the mailing list as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.7 -- we will be looking at activity both on the mailing list and in the bug tracker to help prioritize the bug fixes for the next couple months. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.6 release, including contributions from 27 individuals around the world, see here: http://public.kitware.com/Bug/changelog_page.php?version_id=87 -- it currently lists 43 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.5... 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] RC compiler on Linux - new problem
On 10/21/2011 06:49 PM, pellegrini wrote:
Hi all,
after digging and googling some hours I did a first step in the right
direction.
I had to add the command:
enable_language(rc)
set(cmake_rc_compiler_arg1 -cif8)
The resource compiler I (must) use is the one provided by winteracter
Fortran library.
This led me to a serie of problems related to the use of this compiler:
- it does not accept any output flag so that the output resource
object is always created in-source in the rc file directory.
- on Linux, it produces a .o object file instead of a .res file
Looking at the CMakeRCInformation.cmake I see that by construction CMake
will use the following compile command:
CMAKE_RC_COMPILER FLAGS DEFINES /foOBJECT SOURCE
with a resource object file with a .res extension.
You might rewrite this rule variable, e.g. in order to drop
/foOBJECT, but this wouldn't resolve your issues, AFAICS.
On a Linux machine, this produces a wrong build command line with the
path for the output object file being /foCMakeFiles/ This problem
was raised sometime ago in the mantis bug tracker but unfortunatley the
patch proposed apply for mingw using windres but not for Linux.
Is there a fix for this ?
If no, is there a way to inform the linker that:
- my resource object file is located in-source
You might create symlinks to the resource files - or copy them - so
that the winteracter RC generates its output files within the build
tree; note that the source tree may be read-only. This could even be
done on the fly with an adapted version of ADD_EXECUTABLE/LIBRARY().
- the extension is not .res but .o
You might use a RULE_LAUNCH_COMPILE property in conjunction with a
shell script which recognizes RC command lines, moves the .o to a
.res in the correct directory and drops the undesired /fo switch.
The attached CMakeLists.txt and rc.sh files outline these approaches;
check them out with meaningful ${CMAKE_SOURCE_DIR}/{abs,srcdir}.rc
and ${CMAKE_BINARY_DIR}/bindir.rc. However, they are untested as I
currently haven't any RC at hand; moreover, they're restricted to
Makefiles and won't work on Windows.
Regards,
Michael
pellegrini a écrit :
Hi all,
I use CMake 2.8.5 on Linux and Windows machine to build a Fortran
project.
On Windows, no problem, the build and the resulting GUI are OK. On
Linux, the build seems to
be OK but the resulting GUI gives an empty screen. Discussing with
Michael a few days ago made
me think that it could be related to the use of an inappropriated
motif library.
However, looking in more details I see with a make VERBOSE=1 that my
rc file is not built
(I do not see the line Building RC object ...). even if it is
declared as one of my sources files.
Is there some extra commands to specify to make cmake recognize and
compile a rc file ?
thanks
Eric
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RC C RC)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/rc)
FUNCTION(ADD_EXECUTABLE TARGET)
UNSET(ARGS)
FOREACH(i IN LISTS ARGN)
IF(i MATCHES \\.rc$)
IF(IS_ABSOLUTE ${i})
GET_FILENAME_COMPONENT(p ${i} PATH)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/rc${p})
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E create_symlink
${i} ${CMAKE_BINARY_DIR}/rc${i})
LIST(APPEND ARGS ${CMAKE_BINARY_DIR}/rc${i})
ELSEIF(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/${i})
GET_FILENAME_COMPONENT(p ${CMAKE_CURRENT_SOURCE_DIR}/${i}
PATH)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/rc${p})
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E create_symlink
${CMAKE_CURRENT_SOURCE_DIR}/${i}
${CMAKE_BINARY_DIR}/rc${CMAKE_CURRENT_SOURCE_DIR}/${i})
LIST(APPEND ARGS
${CMAKE_BINARY_DIR}/rc${CMAKE_CURRENT_SOURCE_DIR}/${i})
ELSE()
GET_FILENAME_COMPONENT(p ${CMAKE_CURRENT_BINARY_DIR}/${i}
PATH)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/rc${p})
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E create_symlink
${CMAKE_CURRENT_BINARY_DIR}/${i}
${CMAKE_BINARY_DIR}/rc${CMAKE_CURRENT_BINARY_DIR}/${i})
LIST(APPEND ARGS
${CMAKE_BINARY_DIR}/rc${CMAKE_CURRENT_BINARY_DIR}/${i})
ENDIF()
ELSE()
LIST(APPEND ARGS ${i})
ENDIF()
ENDFOREACH()
_ADD_EXECUTABLE(${TARGET} ${ARGS})
ENDFUNCTION()
SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_COMPILE bash
${CMAKE_SOURCE_DIR}/rc.sh CMAKE_RC_COMPILER SOURCE OBJECT)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/bindir.rc ) # -- Something meaningful.
ADD_EXECUTABLE(main main.c srcdir.rc bindir.rc ${CMAKE_SOURCE_DIR}/abs.rc)
rc.sh
Description: Bourne shell script
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep
[CMake] OS X Frameworks with spaces in filename
Sorry if this is not the correct list to post questions. Please direct me
to the proper place if so.
I'm having trouble linking my OS X application to a specific framework using
CMake without explicitly setting linker flags (somewhat defeating the
purpose of using CMake for cross-platform building). Say I have a framework
called My Framework.framework. CMake successfully finds the framework
when I run:
find_library(MY_LIB \My\ Framework\)
Then I link to my target with:
target_link_libraries(MyTarget ${MY_LIB})
The resulting linker flag is:
-Framework My Framework
This of course is incorrect and will cause gcc to try to link to My and
Framework separately.
The solution is to write the linker flags myself, as follows:
set(CMAKE_EXE_LINKER_FLAGS -framework\ \My\ Framework\)
Is there a better way?
BTW, I tried to fix up the name by replacing with \ i.e.
string(REPLACE \\ MY_LIB_FIX ${MY_LIB})
Such that MY_LIB_FIX is /Library/Frameworks/My\ Framework.framework. But to
my dismay, CMake interprets this format differently and produces a warning
that says [the path] is a full-path but not a valid library file name.
The the resulting linker flag is -l rather than the required -framework.
Any help greatly appreciated!
--
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] pr.swiggett.crystal
SALVADOR wolfieyo http://www.narcononfreedomcenter.com/wp-admin/images/79m9o.php?pkmac765¢dha6 -- 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.6-1607-g9217831
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 9217831a37d63bfb9d40af5ba23c121198c0d747 (commit) via 5a94d099ddbd8f3d4b850957faa8c11f619c6f18 (commit) from 51b2f74062eca6b6d85017bf5a96cb341ece9347 (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=9217831a37d63bfb9d40af5ba23c121198c0d747 commit 9217831a37d63bfb9d40af5ba23c121198c0d747 Merge: 51b2f74 5a94d09 Author: David Cole david.c...@kitware.com AuthorDate: Fri Oct 21 10:52:22 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Oct 21 10:52:22 2011 -0400 Merge topic 'fix-12522-avoid-xcode-env-spew' into next 5a94d09 Xcode: Avoid spewing the environment on every script run (#12522) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5a94d099ddbd8f3d4b850957faa8c11f619c6f18 commit 5a94d099ddbd8f3d4b850957faa8c11f619c6f18 Author: Johan Bjork p...@spotify.com AuthorDate: Mon Oct 17 13:47:19 2011 +0200 Commit: David Cole david.c...@kitware.com CommitDate: Thu Oct 20 19:14:28 2011 -0400 Xcode: Avoid spewing the environment on every script run (#12522) This is the prefered way to get rid of the 'setenv XXX' output, instead of stripping it in the cmakexbuild wrapper. diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx index 09265ae..32eaef8 100644 --- a/Source/cmGlobalXCodeGenerator.cxx +++ b/Source/cmGlobalXCodeGenerator.cxx @@ -1328,6 +1328,8 @@ cmGlobalXCodeGenerator::AddCommandsToBuildPhase(cmXCodeObject* buildphase, cmSystemTools::ReplaceString(makecmd, \\ , ); buildphase-AddAttribute(shellScript, this-CreateString(makecmd.c_str())); + buildphase-AddAttribute(showEnvVarsInLog, + this-CreateString(0)); } // @@ -2065,6 +2067,9 @@ cmGlobalXCodeGenerator::CreateUtilityTarget(cmTarget cmtarget) shellBuildPhase-AddAttribute(shellScript, this-CreateString( # shell script goes here\nexit 0)); + shellBuildPhase-AddAttribute(showEnvVarsInLog, +this-CreateString(0)); + cmXCodeObject* target = this-CreateObject(cmXCodeObject::PBXAggregateTarget); target-SetComment(cmtarget.GetName()); --- Summary of changes: Source/cmGlobalXCodeGenerator.cxx |5 + 1 files changed, 5 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.6-62-gaf77289
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 af772893b856b50697f18c9bb7b1a0fb326cf715 (commit) from b9e9ad57fa9914d5b3c34a39a5d00d77051a1614 (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=af772893b856b50697f18c9bb7b1a0fb326cf715 commit af772893b856b50697f18c9bb7b1a0fb326cf715 Author: KWSys Robot kwro...@kitware.com AuthorDate: Sat Oct 22 00:01:21 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sat Oct 22 00:10:10 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index cfec8a6..216edc9 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 10) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 21) +SET(KWSYS_DATE_STAMP_DAY 22) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
