[cmake-developers] [CMake 0014123]: .dll.a files should not be stripped by cmake when using mingw toolchain

2013-05-02 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14123 == Reported By:Gregoire Assigned To:

Re: [cmake-developers] [CMake] 2.8.11-rc3 generator expression error

2013-05-02 Thread Brad King
On 05/02/2013 02:46 AM, Stephen Kelly wrote: > Brad King wrote: >> On 04/30/2013 07:38 PM, Stephen Kelly wrote: >> I'm saying that even after the current version of the topic the >> caching is still accumulating across configurations in multi-config >> generators. AFAICT that part is not yet fixed

[cmake-developers] [CMake 0014124]: NSIS installer uninstalls from incorrect directory

2013-05-02 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14124 == Reported By:David Golub Assigned To:

Re: [cmake-developers] [CMake] 2.8.11-rc3 generator expression error

2013-05-02 Thread Stephen Kelly
Brad King wrote: > On 05/02/2013 02:46 AM, Stephen Kelly wrote: >> Brad King wrote: >>> On 04/30/2013 07:38 PM, Stephen Kelly wrote: >>> I'm saying that even after the current version of the topic the >>> caching is still accumulating across configurations in multi-config >>> generators. AFAICT t

Re: [cmake-developers] Arbitrary content in JOIN genex separator

2013-05-02 Thread Stephen Kelly
Brad King wrote: > On 04/23/2013 03:26 PM, Stephen Kelly wrote: >> The $ branch is almost ready, but I thought something worth >> bringing up is the use of a comma as a separator. > [snip] >> $ # results in one,two,three >> >> Do you think that's more or less confusing? Should I implement it? >

Re: [cmake-developers] Generating files at generate-time

2013-05-02 Thread Stephen Kelly
Brad King wrote: > On 04/23/2013 03:07 PM, Stephen Kelly wrote: >> file(EVALUATE "${CMAKE_CURRENT_SOURCE_DIR}/input.txt" >>"${CMAKE_CURRENT_BINARY_DIR}/output.txt" >> ) > [snip] >> file(EVALUATE "${CMAKE_CURRENT_BINARY_DIR}/input.txt" >>"${CMAKE_CURRENT_BINARY_DI

Re: [cmake-developers] INTERFACE_LIBRARY target type

2013-05-02 Thread Stephen Kelly
Brad King wrote: >> Having said that, would IMPORTED targets actually be good enough for all >> the things you list, maybe with some wrapper macros ? > > The IMPORTED targets still need to have an IMPORTED_LOCATION that refers > to a real file, so they are not quite equivalent to the proposed INT

Re: [cmake-developers] Generating files at generate-time

2013-05-02 Thread Brad King
On 05/02/2013 11:07 AM, Stephen Kelly wrote: > How do you generate a file only once with non-config-dependent content in a > simple case? > > file(GENERATE > OUTPUT "the_output.txt" > CONTENT "The content" > CONDITION 1 >) > > That will be generated N times in multi-config

Re: [cmake-developers] [CMake] 2.8.11-rc3 generator expression error

2013-05-02 Thread Brad King
On 05/02/2013 10:57 AM, Stephen Kelly wrote: > I've added a patch to fix-per-config-tll-include-dirs in my clone. Is that > what you're looking for? Yes. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Re: [cmake-developers] Generating files at generate-time

2013-05-02 Thread Stephen Kelly
Brad King wrote: > On 05/02/2013 11:07 AM, Stephen Kelly wrote: >> How do you generate a file only once with non-config-dependent content in >> a simple case? >> >> file(GENERATE >> OUTPUT "the_output.txt" >> CONTENT "The content" >> CONDITION 1 >>) >> >> That will be gene

Re: [cmake-developers] Generating files at generate-time

2013-05-02 Thread Brad King
On 05/02/2013 01:44 PM, Stephen Kelly wrote: > Brad King wrote: >> Make it an error if different *content* will be written to the same >> file name by different configurations. Generate for all configs into >> per-config temp files. Then identify all files that map to a single >> name according t

Re: [cmake-developers] INTERFACE_LIBRARY target type

2013-05-02 Thread Brad King
On 05/02/2013 11:26 AM, Stephen Kelly wrote: > Perhaps we could do aliasing with a target property instead? > > add_library(foo SHARED foo.cpp) > set_property(TARGET foo APPEND PROPERTY ALIAS_NAME KF5::foo) No, I like to be able to say that all logical target names are created by an add_* call.

[cmake-developers] [CMake 0014126]: Please package cmake scripts for SFML and CSFML.

2013-05-02 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14126 == Reported By:Sylvain Boilard Assigned To:

Re: [cmake-developers] INTERFACE_LIBRARY target type

2013-05-02 Thread Alexander Neundorf
On Thursday 02 May 2013, Stephen Kelly wrote: > Brad King wrote: > >> Having said that, would IMPORTED targets actually be good enough for all > >> the things you list, maybe with some wrapper macros ? > > > > The IMPORTED targets still need to have an IMPORTED_LOCATION that refers > > to a real f

Re: [cmake-developers] ADDITIONAL_MAKE_CLEAN_FILES only works in Makefile generators / automoc cleaning problem

2013-05-02 Thread Alexander Neundorf
On Tuesday 30 April 2013, Brad King wrote: > On 04/29/2013 05:44 PM, Alexander Neundorf wrote: > > On Monday 29 April 2013, Brad King wrote: > >> VS needs to know that the file is the output of a custom command. > >> In order for CMake to tell VS about this, the file needs to be > >> listed as an O