Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake

On 2015-04-28 14:54-0700 Alan W. Irwin wrote: Also, a spurious warning is probably not that big a deal, but if you think the incorrect order of project(...) before cmake_minimum_required(...) could lead to more serious issues now or in the future as Platform code gets more and more complex, then

Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake

On 2015-04-28 16:44-0400 Brad King wrote: On 04/28/2015 04:15 PM, Alan W. Irwin wrote: The problem is I am reporting the problem second-hand, and I don't have access to a Cygwin platform myself. But from the report I received the incorrect warning message occurs each time a different compiler

Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add

Andrey Pokrovskiy wrote: > Hi, > > I'm using cmake and CMAKE_TOOLCHAIN_FILE to build the project and it's > dependencies. Some toolchain files have additional options (like API > version, target architecture, linker type, etc.) which you need to > pass to cmake command with "-D" in addition to th

Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?

Nils Gladitz wrote: > On 04/28/2015 09:30 AM, Alan W. Irwin wrote: >> OK. Thanks, for pointing that out. Could you make that more obvious >> in , i.e. >> change the summary line from >> >> Disallow use of the LOCATION target property. >>

Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake

On 04/28/2015 04:15 PM, Alan W. Irwin wrote: > The problem is I am reporting the problem second-hand, and I don't > have access to a Cygwin platform myself. But from the report I > received the incorrect warning message occurs each time a different > compiler is enabled. The patch to plplot below

Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake

On 2015-04-28 14:22-0400 Brad King wrote: On 04/27/2015 05:53 PM, Alan W. Irwin wrote: Anybody here got a clue about what is going on? Please strip it down to a minimal example. That will either find the culprit or provide a test case we can use independently. Hi Brad: The problem is I am

Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake

On 04/27/2015 05:53 PM, Alan W. Irwin wrote: > Anybody here got a clue about what is going on? Please strip it down to a minimal example. That will either find the culprit or provide a test case we can use independently. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-top

[cmake-developers] [CMake 0015538]: set_property(SOURCE ) not working for MASM assembly files within Visual Studio 2014 generator

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15538 == Reported By:Wolfgang Assigned To:

Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY

Why are we making the restriction more restrictive than it needs to be? We only need this for multiple targets and not within a single target. This is how I see it. 1. Using MAIN DEPENDENCY is a useful and desirable feature of FindCUDA. 2. A single input file can be used multiple time to generate

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

Le 28/04/15 12:23, Domen Vrankar a écrit : Hi, Sorry for not replying sooner. Please find attached a patch for the reworked documentation. I tried to make the doc more consistent with the CPackRPM (doc right after the variable declaration and options afterwards). I also put links for the varia

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

> Hi, > > Would you please add > set( CPACK_DEBIAN_PACKAGE_DEBUG ON) > > to the file > MyLibCPackConfig-splitted-components-depend2.cmake.in > > so that we also have the debug logs? I currently don't have access to my computer so I'll send you that in about a week. > BTW, I do not know what CPack

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

> I am having a look now at the changes you made on the first patch (say > 75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06), file > RunCPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake > > Instead of finding lintian and dpkg-deb in the check file > find_program(LINTIAN_EXECUT

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

Hi, Sorry for not replying sooner. > Please find attached a patch for the reworked documentation. I tried to make > the doc more consistent with the CPackRPM (doc right after the variable > declaration and options afterwards). > I also put links for the variables and changed the formatting a bit.

Re: [cmake-developers] Generator Expressions in CPack (Module) variables

2015-04-28 10:57 GMT+02:00 Gregor Jasny : > Hello Nils, > > thank you for the pointers. > > On 24/04/15 21:30, Nils Gladitz wrote: > >> On 24.04.2015 20:55, Gregor Jasny wrote: >> >>> Hello, >>> >>> would it be possible to add generator expression support to CPack >>> so that I can use $ within CP

Re: [cmake-developers] Generator Expressions in CPack (Module) variables

On 04/28/2015 10:57 AM, Gregor Jasny wrote: Unfortunately the CPACK_BUILD_CONFIG approach does only work for multi-config generators. As far as I understand CPACK_BUILD_CONFIG gets only set if the -C command line option was given to cpack. But this option is only added conditionally and omitted f

Re: [cmake-developers] Generator Expressions in CPack (Module) variables

Hello Nils, thank you for the pointers. On 24/04/15 21:30, Nils Gladitz wrote: On 24.04.2015 20:55, Gregor Jasny wrote: Hello, would it be possible to add generator expression support to CPack so that I can use $ within CPACK_PACKAGE_FILE_NAME? I'm using the CPack module from within my CMakeL

Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?

On 04/28/2015 09:30 AM, Alan W. Irwin wrote: OK. Thanks, for pointing that out. Could you make that more obvious in , i.e. change the summary line from Disallow use of the LOCATION target property. ==> Disallow use of the LOCATION pro

Re: [cmake-developers] Identify used source files

If someone is interessted in this solution: set(FilenameUsedFiles ${CMAKE_BINARY_DIR}/UsedFiles.lst) file(WRITE ${FilenameUsedFiles} "") function (parseArguments) set(options) set(oneValueArgs) set(multiValueArgs) cmake_parse_arguments(CFG "${options}""${oneValueArgs}" "${mult

Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?

On 04/28/2015 09:30 AM, Alan W. Irwin wrote: I don't understand exactly what you mean by "configuration LOCATION returns". From what you said that term means something different from LOCATION_ and in any case is not relevant to my use case of generating pkg-config *.pc files with our build syste

Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?

many places that you would use LOCATION you can use generator expressions http://www.cmake.org/cmake/help/v3.0/manual/cmake-generator-expressions.7.html $ On Tue, Apr 28, 2015 at 12:30 AM, Alan W. Irwin wrote: > Hi Nils: > > Thanks for your quick reply. More below in context. > > > On 2015-04-

Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?

Hi Nils: Thanks for your quick reply. More below in context. On 2015-04-28 08:45+0200 Nils Gladitz wrote: On 04/28/2015 08:00 AM, Alan W. Irwin wrote: The Qt5 cmake documentation at which Steve has referred me to before states you should use the LOC

Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY

On 04/27/2015 11:48 PM, James Bigler wrote: The problem is the current detection only barfs (unless I missed something - please correct if I'm wrong). What we need is detection and adaptation. Rather than telling the user, "DON'T DO THAT!" we should be helping the user out by saying, "I know yo