[cmake-developers] [CMake 0013015]: cpack deb generator components specify output names
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13015
==
Reported By:Andrew Aladjev
Assigned To:
==
Project:CMake
Issue ID: 13015
Category: CPack
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-03-04 04:47 EST
Last Modified: 2012-03-04 04:47 EST
==
Summary:cpack deb generator components specify output names
Description:
http://stackoverflow.com/questions/9538642/cpack-deb-generator-components-output-names
Steps to Reproduce:
install (TARGETS ${PROJECT_NAME}_shared DESTINATION ${CMAKE_INSTALL_PREFIX}/lib
COMPONENT runtime)
install (TARGETS ${PROJECT_NAME}_static DESTINATION
${CMAKE_INSTALL_PREFIX}/lib
COMPONENT development)
install (FILES ${INCLUDES} DESTINATION ${CMAKE_INSTALL_PREFIX}/include
COMPONENT development)
...
set (CPACK_PACKAGE_FILE_NAME
lib${CPACK_PACKAGE_NAME}_${CPACK_PACKAGE_VERSION}_${CPACK_DEBIAN_PACKAGE_ARCHITECTURE})
I have 2 deb packages as a result:
libmpreal_0.1.1-1_amd64-development.deb
libmpreal_0.1.1-1_amd64-runtime.deb
But I want to have for debian standarts another names:
libmpreal-dev_0.1.1-1_amd64.deb
libmpreal_0.1.1-1_amd64.deb
Additional Information:
Now I am reading [this][1] at the method **cmCPackDebGenerator::PackageOnePack**
here is a code:
outputFileName(
std::string(this-GetOption(CPACK_PACKAGE_FILE_NAME))
+ - + packageName + this-GetOutputExtension()
);
Does this mean that I cant specify a name for my packages?! I would like to make
a mistake..
[1]:
https://github.com/Kitware/CMake/blob/master/Source/CPack/cmCPackDebGenerator.cxx
==
Issue History
Date ModifiedUsername FieldChange
==
2012-03-04 04:47 Andrew Aladjev 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] Modifying RPATH feature to run tests uninstalled
Brad King brad.king@... writes: That's a good start. However I do not think the logic plays well with BUILD_WITH_INSTALL_RPATH as currently written. If that is set then the build tree should end up with the install-tree rpath which should be empty if SKIP_INSTALL_RPATH is on. Therefore the relink/chrpath paths should not need to return true always when SKIP_INSTALL_RPATH is on. Sorry this took so long. I have updated the branch (It is now e96c16ae23885be2e66d67291344369585ebfece) -- 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] Making GUI applications by default
Stephen Kelly steveire@... writes: Brad King wrote: The implementation is not what I had in mind when I said implies the platform-specific property. This should be its own property that one can set/get normally with no special C++-implemented mapping to the other two properties. The generators should look for this property first and only if not set look for the platform- specific property. If either is set the effect is the same. I see. That's a bit more painful. That will mean touching all generators, and I don't have the easy visual studio or mac access to implement or test them. I happened to read a little bit about CPack recently http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview The recommendation is to not use MACOSX_BUNDLE when using cpack, so I thought maybe that makes it different enough to WIN32_EXECUTABLE that they should be different CMAKE_ properties. set(CMAKE_WIN32_EXECUTABLE ON) set(CMAKE_MACOSX_BUNDLE ON) That would also mean that I can actually submit the patch. I'm not so keen on having to change every generator instead. Actually I think the existing patch is better than touching every generator anyway (that's at least in part why there is an abstraction). Thanks, Steve. -- 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] GenerateExportHeader gcc version test failure?
Stephen Kelly steveire@... writes: Any idea what would cause that? It must be one of these: http://open.cdash.org/viewUpdate.php?buildid=2016288 Note that the GenerateExportHeader_MinorFix makes the problem go away, but doesn't explain why the problem occured in the first place. I noticed that the branch was merged. Was there no interest in finding out why the determination of the GCC version suddenly failed? -- 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] Convention driven CMAKE_USE_PACKAGE macro
Alexander Neundorf wrote: The question whether the standard-conforming name is FOO_INCLUDE_DIRS or Foo_INCLUDE_DIRS, i.e. ExactCase or UPPERCASE, is not decided. readme.txt is ambiguous in this point, since it uses as example FindXXX.cmake, i.e. an UPPERCASE package name. There was a thread here in August 2010: http://www.mail-archive.com/cmake-developers- wchdc6uyxvpytjvyw6y...@public.gmane.org/msg00128.html and results for what casing is used in cmake and in kdelibs here: http://www.mail-archive.com/cmake-developers- wchdc6uyxvpytjvyw6y...@public.gmane.org/msg00157.html The concensus seems to be that ExactCase is used. It also makes a lot more sense to me for several reasons but that's off topic for this thread. It's unfortunate that the ambiguity didn't get resolved in general. For Qt5 and config files I think exact case makes even more sense because using config files sets ExactCase_FOUND to true if found. Thanks, Steve. -- 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
