[cmake-developers] [CMake 0015518]: PDB_NAME documentation doesn't mention that it uses OUTPUT_NAME if defined
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15518 == Reported By:Paul TBBle Hampson Assigned To: == Project:CMake Issue ID: 15518 Category: CMake Reproducibility:always Severity: text Priority: normal Status: new == Date Submitted: 2015-04-17 04:03 EDT Last Modified: 2015-04-17 04:03 EDT == Summary:PDB_NAME documentation doesn't mention that it uses OUTPUT_NAME if defined Description: The PDB_NAME documentation has always stated: This property specifies the base name for the debug symbols file. If not set, the logical target name is used by default. (since 2.8.10 when it was introduced: http://www.cmake.org/cmake/help/v2.8.10/cmake.html#prop_tgt:PDB_NAME up to 3.2: http://www.cmake.org/cmake/help/v3.2/prop_tgt/PDB_NAME.html) However, examining the original commit (http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f60dbf1#patch7) shows that it actually uses cmTarget::GetFullNameInternal, which honours OUTPUT_NAME. This is also true of the _CONFIG variants. It's correct behaviour, so it's just the documentation that needs updating, hence the given Severity. Steps to Reproduce: * Create a target using OUTPUT_NAME that differs from the logical target name. * Generate a Visual Studio solution * Note that the PDB generated is OUTPUT_NAME.pdb, not logicalName.pdb. Additional Information: The unit tests don't cover this case, but I expect that a unit test setting OUTPUT_NAME and PDB_NAME would trivially demonstrate the actual behaviour. I assume the text was just copied from the OUTPUT_NAME documentation, which is the only other place that this text appears, and it makes sense there. == Issue History Date ModifiedUsername FieldChange == 2015-04-17 04:03 Paul TBBle HampsonNew Issue == -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] ExternalProject_Add: Allow generator expressions in CMAKE_CACHE_ARGS
With this change, does the external project's configure step re-run
when you edit only the CMAKE_CACHE_ARGS for it?
(It did with the *.in / configure_file approach...)
On Fri, Apr 17, 2015 at 12:55 AM, Andrey Pokrovskiy
wonder.m...@gmail.com wrote:
In current implementation of ExternalProject_Add generator expressions
are supported in CMAKE_ARGS (probably by coincidence), but not in
CMAKE_CACHE_ARGS. This patch will enable generators expressions in
CMAKE_CACHE_ARGS.
Use case:
set(LIBEV_LIBRARIES $TARGET_FILE:ev)
ExternalProject_Add(
...
CMAKE_CACHE_ARGS
-DLIBEV_LIBRARIES=${LIBEV_LIBRARIES}
...)
---
Modules/ExternalProject.cmake | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 0c73d41..1c7cf51 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -1126,10 +1126,7 @@ function(_ep_write_initial_cache target_name
script_filename script_initial_cach
# Replace location tags.
_ep_replace_location_tags(${target_name} script_initial_cache)
# Write out the initial cache file to the location specified.
- if(NOT EXISTS ${script_filename}.in)
-file(WRITE ${script_filename}.in \@script_initial_cache\@\n)
- endif()
- configure_file(${script_filename}.in ${script_filename})
+ file(GENERATE OUTPUT ${script_filename} CONTENT
${script_initial_cache})
endfunction()
--
2.3.2 (Apple Git-55)
--
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://public.kitware.com/mailman/listinfo/cmake-developers
--
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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] new cpack tests
On 4/16/2015 6:15 PM, Domen Vrankar wrote:
I'm not certain that trying to squeeze the tests described above into
RunCMake is the right way to go.
[snip]
Would it be OK if I add something like CPackSemanticTests (I'm bad
with names) into Tests directory and implement it similarly to
RunCMake tests?
The RunCMake infrastructure was originally created to run cmake
and check results. It has evolved to run just about anything and
check the results.
One should be able to build RunCPack test infrastructure on top
of RunCMake, similar to Tests/RunCMake/RunCTest.cmake for CTest.
There are already several RunCMake tests that do multiple steps
with a single build tree without wiping it out after the first
step. They tend to have the boilerplate:
set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/Multistep-build)
set(RunCMake_TEST_NO_CLEAN 1)
file(REMOVE_RECURSE ${RunCMake_TEST_BINARY_DIR})
file(MAKE_DIRECTORY ${RunCMake_TEST_BINARY_DIR})
... run_cmake and run_cmake_command calls here...
unset(RunCMake_TEST_BINARY_DIR)
unset(RunCMake_TEST_NO_CLEAN)
One could probably refactor RunCMake a bit to reduce boilerplate
for these cases and re-use it for RunCPack.
-Brad
--
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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 16/04/15 22:31, Brad King a écrit :
On 04/16/2015 04:19 PM, Domen Vrankar wrote:
I've pushed the patch with minor changes to next.
http://www.cmake.org/gitweb?p=cmake.git;h=0779b679
Thanks. The fixup! mark is useful only during incremental
development of an open topic. Once a commit is in 'master'
then it should be explicitly referenced by a later fixup commit
with a normal commit message. I've revised the commit as:
CPack: Fix single component packaging
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed0b0630
I also rebased it back on the original commit and renamed the
topic to match. This makes it look like one topic that was
merged to master in the middle.
-Brad
Ok, here is a patch that shows you the advance. This is not yet a
candidate for merging to anything, but rather a support for some
discussions.
It is based on ed0b063 for this particular topic.
I added the following functionalities:
- set the permissions of the md5sum to RW-R--R--, because lintian complains
- added an option to set the shlibdeps per component
- added an option to set the dependencies per component
- added an option to set the description per component
- enforcing the lower case policy of Debian for package names (in the
file, due to the comment # debian policy enforce lower case for package
name)
On the other hand, I started writing tests based on the one existing for
the CPackComponentsAll, but specific to debian packages:
- added a function for running lintian and checking for some errors. The
md5sum permission change is now covered by that
- added a function for running dpkg-deb and extracting a particular
field of the package metadata. No change I made are currently covered by
this function, this is what I will do next.
- Having one specific check file per configuration, sharing a common
.cmake providing the check functions (linitian and dpkg-deb). This would
prevent the cluttering of the checks that we can observe in the
CPackComponentsAll final test.
Of course, your comments are more than welcome.
Best,
Raffi
From 2681e05c844eee5b77568895b5b1329f1377b05b Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@mines-paris.org
Date: Fri, 17 Apr 2015 15:49:33 +0200
Subject: [PATCH] Debian packaging
- enabling a per component shlibdeps
- enabling a per component dependencies
- enabling a per component description
- fixing the file permissions of the auto-generated md5sum
- new tests specific to CPackDeb.cmake with lintian and dpkg-deb
---
Modules/CPackDeb.cmake | 89 +++--
Source/CPack/cmCPackDebGenerator.cxx | 8 +
Tests/CMakeLists.txt | 35
Tests/CPackComponentsDEB/CMakeLists.txt| 103 ++
...Config-one-file-per-component-no-group.cmake.in | 15 ++
...ifyResult-one-file-per-component-no-group.cmake | 78
.../CPackComponentsDEB/RunCPackVerifyResult.cmake | 217 +
Tests/CPackComponentsDEB/license.txt | 3 +
Tests/CPackComponentsDEB/mylib.cpp | 7 +
Tests/CPackComponentsDEB/mylib.h | 1 +
Tests/CPackComponentsDEB/mylibapp.cpp | 6 +
11 files changed, 550 insertions(+), 12 deletions(-)
create mode 100644 Tests/CPackComponentsDEB/CMakeLists.txt
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-one-file-per-component-no-group.cmake.in
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-one-file-per-component-no-group.cmake
create mode 100644 Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake
create mode 100644 Tests/CPackComponentsDEB/license.txt
create mode 100644 Tests/CPackComponentsDEB/mylib.cpp
create mode 100644 Tests/CPackComponentsDEB/mylib.h
create mode 100644 Tests/CPackComponentsDEB/mylibapp.cpp
diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 8a4fa49..647b2ae 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -104,6 +104,15 @@
# may fail to find your own shared libs.
# See http://www.cmake.org/Wiki/CMake_RPATH_handling.
#
+# .. variable:: CPACK_DEBIAN_comp_PACKAGE_SHLIBDEPS
+#
+# * Mandatory : NO
+# * Default : CPACK_DEBIAN_PACKAGE_SHLIBDEPS
+#
+# Same as `CPACK_DEBIAN_PACKAGE_SHLIBDEPS` but for one specific component.
+# If set (either to ON or OFF) it overrides the default given by
+# `CPACK_DEBIAN_PACKAGE_SHLIBDEPS`.
+#
# .. variable:: CPACK_DEBIAN_PACKAGE_DEBUG
#
# * Mandatory : NO
@@ -229,12 +238,28 @@ if(NOT DEFINED CPACK_DEBIAN_PACKAGE_SHLIBDEPS)
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS OFF)
endif()
+set(_cpack_debian_shlibdeps_local ${CPACK_DEBIAN_PACKAGE_SHLIBDEPS})
+
find_program(FAKEROOT_EXECUTABLE fakeroot)
if(FAKEROOT_EXECUTABLE)
set(CPACK_DEBIAN_FAKEROOT_EXECUTABLE ${FAKEROOT_EXECUTABLE})
endif()
-if(CPACK_DEBIAN_PACKAGE_SHLIBDEPS)
+if(CPACK_DEB_PACKAGE_COMPONENT)
+ set(_component_shlibdeps_var
Re: [cmake-developers] [CMake 0015231]: find_package: should be a simple way to alter the order of the config/module lookups
On 04/16/2015 05:54 AM, Tamás Kenéz wrote: I think the main challenge will be how to format error messages when neither mode finds anything for a REQUIRED package. We can pretend they failed in the usual module;config order. So the wordings of the messages may remain as they are. The current message says: By not providing Findpkg.cmake in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file ... If someone sets CMAKE_FIND_PACKAGE_CONFIG_FIRST then that is what asked CMake to find a package configuration file even if the project does provide Findpkg.cmake in CMAKE_MODULE_PATH. Therefore new wording will be needed in this case. It should still depend on whether the find module was available. We should however think about what to do when CMAKE_FIND_PACKAGE_WARN_NO_MODULE is ON and both modes are enabled (and we're in CONFIG_FIRST mode). Should we check the missing find-module *after* we've found a config-module and print the warning? I think no, because the user has explicitly expressed the preference towards the CONFIG mode by specifying CONFIG_FIRST (either as a find_package option or as CMAKE_FIND_PACKAGE_CONFIG_FIRST). Agreed. We can always add such a warning in the future. About the proposed change: The feature request proposes two ways to enable the CONFIG_FIRST mode: a new option for the find_package and a global variable (which I think should be called CMAKE_FIND_PACKAGE_CONFIG_FIRST). I think the find_package option is less important since the same effect can be achieved by creating a custom find_package_config_first() macro. If the functionality is implemented through either interface it will be easy to add the other, so I think they can just both be added together. Are you interested in working on a patch for this? Thanks, -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 17/04/15 15:50, Raffi Enficiaud a écrit : Le 16/04/15 22:31, Brad King a écrit : On 04/16/2015 04:19 PM, Domen Vrankar wrote: I've pushed the patch with minor changes to next. http://www.cmake.org/gitweb?p=cmake.git;h=0779b679 Thanks. The fixup! mark is useful only during incremental development of an open topic. Once a commit is in 'master' then it should be explicitly referenced by a later fixup commit with a normal commit message. I've revised the commit as: CPack: Fix single component packaging http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed0b0630 I also rebased it back on the original commit and renamed the topic to match. This makes it look like one topic that was merged to master in the middle. -Brad Ok, here is a patch that shows you the advance. This is not yet a candidate for merging to anything, but rather a support for some discussions. It is based on ed0b063 for this particular topic. I added the following functionalities: - set the permissions of the md5sum to RW-R--R--, because lintian complains - added an option to set the shlibdeps per component - added an option to set the dependencies per component - added an option to set the description per component - enforcing the lower case policy of Debian for package names (in the file, due to the comment # debian policy enforce lower case for package name) On the other hand, I started writing tests based on the one existing for the CPackComponentsAll, but specific to debian packages: - added a function for running lintian and checking for some errors. The md5sum permission change is now covered by that - added a function for running dpkg-deb and extracting a particular field of the package metadata. No change I made are currently covered by this function, this is what I will do next. - Having one specific check file per configuration, sharing a common .cmake providing the check functions (linitian and dpkg-deb). This would prevent the cluttering of the checks that we can observe in the CPackComponentsAll final test. Of course, your comments are more than welcome. Sorry that was too quick. Here are the open questions: - if a component depends on another component, should we add the dependency automatically? - What about the version of this dependency? Let's say I have components A and B, and B depends on A. I am at version X. Dependencies of A are d11, d12, d1N, Dependencies of B are d21, d22, d2P Should the generation of the package B include d2(P+1)= A (= versionX) ? Best, Raffi -- 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://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015519]: Support auto-complete for CodeLite generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15519 == Reported By:chenliang xu Assigned To: == Project:CMake Issue ID: 15519 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-04-17 15:41 EDT Last Modified: 2015-04-17 15:41 EDT == Summary:Support auto-complete for CodeLite generator Description: The generated CodeLite would be more useful if the auto-complete is supported. To do that, the completion and search paths should be configured in the .projct file, such as, Completion EnableCpp11=no ClangCmpFlagsC/ ClangCmpFlags/ ClangPP/SearchPaths /foo/bar /something /SearchPaths /Completion To get a full xml file, you can generate project with cmake, edit include path in CodeLite and check the .project file. I believe some other IDEs such as Eclipse need something similar. == Issue History Date ModifiedUsername FieldChange == 2015-04-17 15:41 chenliang xu New Issue == -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0015231]: find_package: should be a simple way to alter the order of the config/module lookups
Are you interested in working on a patch for this? Yes, I'd give it a try. I signed up to Mantis, account: tamas.kenez so you can assign it to me. I guess that's the next step. Thanks, Tamas On Fri, Apr 17, 2015 at 2:01 PM, Brad King brad.k...@kitware.com wrote: On 04/16/2015 05:54 AM, Tamás Kenéz wrote: I think the main challenge will be how to format error messages when neither mode finds anything for a REQUIRED package. We can pretend they failed in the usual module;config order. So the wordings of the messages may remain as they are. The current message says: By not providing Findpkg.cmake in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file ... If someone sets CMAKE_FIND_PACKAGE_CONFIG_FIRST then that is what asked CMake to find a package configuration file even if the project does provide Findpkg.cmake in CMAKE_MODULE_PATH. Therefore new wording will be needed in this case. It should still depend on whether the find module was available. We should however think about what to do when CMAKE_FIND_PACKAGE_WARN_NO_MODULE is ON and both modes are enabled (and we're in CONFIG_FIRST mode). Should we check the missing find-module *after* we've found a config-module and print the warning? I think no, because the user has explicitly expressed the preference towards the CONFIG mode by specifying CONFIG_FIRST (either as a find_package option or as CMAKE_FIND_PACKAGE_CONFIG_FIRST). Agreed. We can always add such a warning in the future. About the proposed change: The feature request proposes two ways to enable the CONFIG_FIRST mode: a new option for the find_package and a global variable (which I think should be called CMAKE_FIND_PACKAGE_CONFIG_FIRST). I think the find_package option is less important since the same effect can be achieved by creating a custom find_package_config_first() macro. If the functionality is implemented through either interface it will be easy to add the other, so I think they can just both be added together. Are you interested in working on a patch for this? Thanks, -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers -- 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://public.kitware.com/mailman/listinfo/cmake-developers
