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
Re: [cmake-developers] Convention driven CMAKE_USE_PACKAGE macro
Brad King wrote:
>> We can then wrap that macro with some Qt related stuff like this:
>>
>> macro(qt5_use_package _target _package)
>> cmake_use_package(${_target} Qt5${_package} ${ARGN})
>
> For now I suggest keeping everything inside the qt5_use_package macro.
> After it matures there we can always refactor it out later, but you
> need to be able to fix things for Qt without waiting for CMake's
> release schedule.
Yes, currently it is just being developed in a unit test anyway, but we
might eventually be able to make it public API (would require target include
directories, so 2.8.8 anyway).
Trying it out there should be useful, but I'd like to develop in parallel
the ideas for how CMake is going to involve regarding this kind of stuff.
>
>> get_property(_target_type TARGET ${_target} PROPERTY TYPE)
>> if ("${_target_type}" STREQUAL "EXECUTABLE")
>> # TODO: How can I ensure this is done only once?
>> target_link_libraries(${_target} ${Qt5Core_WINMAIN_LIBRARY})
>
> Set a property on the target that records whether it has already
> been done.
>
Thanks! I'll use that technique.
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] Convention driven CMAKE_USE_PACKAGE macro
Brad King wrote: > On 2/24/2012 1:56 PM, Clinton Stimpson wrote: >> What about a more generic approach like the following? >> >> add_library(foo IMPORTED ...) >> set_target_properties(foo PROPERTIES >>DEPENDENT_COMPILE_DEFINITIONS "FOO_DEFINE" >>DEPENDENT_INCLUDE_DIRECTORIES "/path/to/foo/include") >> >> add_executable(bar ...) >> target_link_libraries(foo bar) >> >> And that could automatically add -DFOO_DEFINE and -I/path/to/foo/include >> to the bar executable. >> So basically any DEPENDENT_ can be pushed to on the >> other target. > > Nice. This is exactly the kind of interface I had in mind for the > "usage requirements" approach Alex and I were discussing elsewhere > in this thread. We will have to think about how to define transitive > properties of these requirements though. > Is this kind of thing roadmapped in any way? Can we work on getting it into 2.8.9 (Is it too late for 2.8.8) and start designing or brainstorming more fully? 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 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] Making GUI applications by default
Stephen Kelly 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] Modifying RPATH feature to run tests uninstalled
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
[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
