Re: [cmake-developers] Setting include directories via target_link_libraries() ?

Brad King wrote: > On 12/21/2012 01:08 PM, Stephen Kelly wrote: >> If the target_use_interfaces command did not manipulate a USE_INTERFACES >> property, but instead manipulated the mulitple INTERFACE_* properties in- >> place (not appending) as my branch already does, it would be more clear. >> >

Re: [cmake-developers] Setting include directories via target_link_libraries() ?

On 12/21/2012 01:08 PM, Stephen Kelly wrote: > If the target_use_interfaces command did not manipulate a USE_INTERFACES > property, but instead manipulated the mulitple INTERFACE_* properties in- > place (not appending) as my branch already does, it would be more clear. > > I added a patch to my

Re: [cmake-developers] Setting include directories via target_link_libraries() ?

Brad King wrote: >> Allowing them simplifies the boost case I'm sure. >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5247 >> >> Also as the existing code (for computing the link closure) handles >> cycles, it might be easier to refactor it and keep the cycle h

Re: [cmake-developers] Setting include directories via target_link_libraries() ?

Brad King wrote: > On 12/18/2012 11:09 AM, Stephen Kelly wrote: >>> At generate time that property >>> will be used to accumulate values from INTERFACE_-like properties on >>> the named interfaces and append them to LINK_LIBRARIES, etc. >> >> You wrote before that you don't propose using properti

Re: [cmake-developers] kwsys requests

On 12/21/2012 09:20 AM, Stephen Kelly wrote: > * Make it compile cleanly with -Wundef KWSys has its own dashboard here: http://open.cdash.org/index.php?project=KWSys Most of the submissions come from CMake dashboard clients using cmake_common.cmake which now loads kwsys_common.cmake too. It e

Re: [cmake-developers] kwsys requests

What? You don't like our indentifier? Doesn't help you with all the indentifying you need to do? :-P D On Fri, Dec 21, 2012 at 9:20 AM, Stephen Kelly wrote: > > Hi, > > As the copy of kwsys is updated from time to time, I have two requests for > the next update: > > * Make it compile clean

[cmake-developers] kwsys requests

Hi, As the copy of kwsys is updated from time to time, I have two requests for the next update: * Make it compile cleanly with -Wundef * Add a MakeCidentifier method to SystemTools diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx index 085d988..a8404b0 100644 --- a/So

[cmake-developers] [CMake 0013809]: add_dependencies and --graphviz

The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13809 == Reported By:Vassil Vassilev Assigned To:

[cmake-developers] [CMake 0013808]: Please add 64-Bit ARM endianness defines to cmake

The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13808 == Reported By:Riku Voipio Assigned To:

Re: [cmake-developers] Limitations of IS_ABSOLUTE

On 2012-12-21 09:43+0100 Eric Noulard wrote: 2012/12/21 Alan W. Irwin : Obviously for my use case it does look like a reasonable alternative is to use file(GLOB...) followed by a check of the result variable to see if it is empty. But implementation of an additional IF subcommand called IS_FI

[cmake-developers] [CMake 0013807]: FLTK_WRAP_UI erroneous error message

The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13807 == Reported By:Nicholas Rishel Assigned To:

Re: [cmake-developers] Limitations of IS_ABSOLUTE

2012/12/21 Alan W. Irwin : > My use case is I want to quickly test whether a data file that is external > to the source tree exists or not. So I naively tried to use if(IS_ABSOLUTE > fullpathname) for this purpose, but all that tests at the current time is > whether fullpathname starts with a slas