[cmake-developers] Java_INCLUDE_DIRS not populated by FindJava.cmake

2016-10-16 Thread Craig Scott 
Unless I'm missing something, it would seem that even though the
documentation says FindJava.cmake sets Java_INCLUDE_DIRS, I don't see
anything in that file or things it includes which try to set it. Is the
documentation out of date or is the FindJava.cmake implementation missing
some things? Or am I just blind and missed something obvious? ;)

In case anyone is wondering, the use case for me is when implementing a
SWIG custom command to generate java wrappers, the jni.h header needs to be
found by the generated sources.

Cheers

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-226-g0cbe2ed

2016-10-16 Thread Kitware Robot 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  0cbe2edb23d581233c518beafe92a2c9d4f529ac (commit)
  from  5ebba228823ffc96e82f4b6cc1103c2f2ed8cfa7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0cbe2edb23d581233c518beafe92a2c9d4f529ac
commit 0cbe2edb23d581233c518beafe92a2c9d4f529ac
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Mon Oct 17 00:01:03 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Mon Oct 17 00:01:03 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 953fc4c..3640ea8 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 7)
-set(CMake_VERSION_PATCH 20161016)
+set(CMake_VERSION_PATCH 20161017)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] How to configure CMake to add current path to include directive.

2016-10-16 Thread Steve Lorimer 
Thanks Craig

Looks like it did what you intended, but cmake won't allow it

CMake Error in foo/CMakeLists.txt:
  Found relative path while evaluating include directories of "foo":

"."


Bummer! :(



On 16 October 2016 at 18:35, Craig Scott  wrote:

> Something like the following was what I had in mind (untested):
>
> get_target_property(incDirs someTarget INCLUDE_DIRECTORIES)
> list(APPEND incDirs .)
> set_target_properties(someTarget PROPERTIES INCLUDE_DIRECTORIES
> "${incDirs}")
>
>
> On Mon, Oct 17, 2016 at 10:31 AM, Steve Lorimer 
> wrote:
>
>> Thanks Craig
>>
>> Not sure if I'm doing it right, but I couldn't get that to work.
>>
>> Would you be able to give me an example please?
>>
>> Thanks
>> Steve
>>
>>
>>
>> On 16 October 2016 at 17:51, Craig Scott  wrote:
>>
>>> I think if you manipulate the target property INCLUDE_DIRECTORIES
>>> 
>>> directly, you should be able to force a "." in there without having it
>>> substituted for an absolute path. By this I mean use set_property() or
>>> set_target_properties() rather than target_include_directories() or
>>> include_directories(). Note, however, that the documentation for the
>>> INCLUDE_DIRECTORIES property explicitly recommends against adding relative
>>> paths to the property like this (but in your case it sounds like you really
>>> want a relative path, so maybe this is a valid exception to that advice).
>>>
>>>
>>>
>>> On Mon, Oct 17, 2016 at 9:46 AM, Steve Lorimer 
>>> wrote:
>>>
 In makefile parlance, I'm trying to add -I. (ie: the current directory)
 to my include paths

 I tried the following:

 include_directories(".")


 This doesn't work unfortunately, as relative paths are interpreted as
 relative to the current source directory
 

 That is, if this statement is in my top level CMakeLists.txt, located
 in ~/src/project, the include directive added will be "-I ~/src/project/.",
 whereas I'm trying to add "-I ."

 The reason for my wanting this is that we have sources for a single
 library in several subdirs.

 include_directories(${CMAKE_CURRENT_SOURCE_DIR})

 add_library(
 foo
 STATIC
 foo.cpp
 bar/bar.cpp
 )

 In bar/bar.cpp, I have a relative include

 #include "../foo.h"

 With the above setup, this will fail to compile as only
 ~/src/project/foo will be added to the include paths.

 I'm aware that if I explicitly added the path it would work

 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)

 However, if there is a way to get -I. added to my include path, that's
 what I'm after.

 TIA
 Steve


 --

 Powered by www.kitware.com

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ

 Kitware offers various services to support the CMake community. For
 more information on each offering, please visit:

 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html

 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake

>>>
>>>
>>>
>>> --
>>> Craig Scott
>>> Melbourne, Australia
>>> https://crascit.com
>>>
>>
>>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Cannot get automoc to work properly with recommended Qt5 support method

2016-10-16 Thread Alan W. Irwin 

On 2016-10-16 13:43-0700 Alan W. Irwin wrote:


Hi Stephen:

I am addressing you directly (as well as the list) because you have
been so helpful with Qt5 issues in the past.

The PLplot build system (some of whose components depend on Qt5)
currently uses one of the older Qt5 support methods documented at
.  But that method is complex
and we are currently running into troubles with it where it uses the
plain target_link_libraries command which conflicts with the keyworded
version that we prefer for our build system.  So I have attempted to
update our Qt5 support to the latest target_link_libraries method
documented at the above URL, but automoc appears not to be working
correctly.

I follow the advice in the above URL and set

set(CMAKE_AUTOMOC ON)

and also set AUTOMOC_MOC_OPTIONS to the following list:

-DPLD_bmpqt;-DPLD_jpgqt;-DPLD_pngqt;-DPLD_ppmqt;-DPLD_tiffqt;-DPLD_svgqt;-DPLD_pdfqt;-DPLD_qtwidget;-DPLD_extqt;-DPLD_memqt

This list is the same as I use for MOC_OPTIONS in the old working method, and
these various macro definitions _must_ be defined to avoid dropping large
swaths of our code from the compilation.  Instead of using

set(CMAKE_INCLUDE_CURRENT_DIR ON)

I use instead (in the directory where the plplotqt library is built)

include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ...)

Furthermore, in that same directory I use

target_link_libraries(plplotqt PRIVATE plplot ${MATH_LIB} Qt5::Svg Qt5::Gui 
Qt5::PrintSupport)


for the build.  Although that build apparently works with no obvious
issues, there is no sign of any of the above macros in the
VERBOSE=1 output.  Furthermore, I get the following near-empty result
for the generated bindings/qt_gui/plplotqt_automoc.cpp file which
consists just of the following two lines:

/* This file is autogenerated, do not edit*/
enum some_compilers { need_more_than_nothing };

Finally,

"ldd -r bindings/qt_gui/libplplotqt.st"

shows missing symbols that should be defined if the above macros are
defined.

What am I missing?


I have now looked further, and the missing symbols in the library
correspond exactly to classes in an included header (in a different
PLplot source-tree directory, see below) that have a reference to Q_OBJECT.
Furthermore, when I exclude some of those classes by manipulating
AUTOMOC_MOC_OPTIONS, the corresponding missing symbols disappear from
the library so it appears AUTOMOC_MOC_OPTIONS is actually working
despite no visible sign of that in the "make VERBOSE=1 ..." results.

So I am now looking at something else which is referred to in the
following (from CMake 3.6) automoc documentation (where I have
interpolated questions concerning the ambiguities in that
documentation):

When this property is set ON, CMake will scan the source files at build time 
and invoke moc accordingly.



If an #include statement like #include "moc_foo.cpp" is found,



the
Q_OBJECT class declaration is expected in the header, and moc is run
on the header file. A moc_foo.cpp file will be generated from the
source’s header into the CMAKE_CURRENT_BINARY_DIR directory. This
allows the compiler to find the included moc_foo.cpp file regardless
of the location the original source. []

If an #include statement like #include "foo.moc" is found,



then a
Q_OBJECT is expected in the current source file and moc is run on the
file itself. Additionally, header files with the same base name (like
foo.h) or _p appended to the base name (like foo_p.h) are parsed for
Q_OBJECT macros, and if found, moc is also executed on those files.
AUTOMOC checks multiple header alternative extensions, such as hpp,
hxx etc when searching for headers.



The resulting moc files, which are
not included as shown above in any of the source files are included in
a generated _automoc.cpp file, which is compiled as part
of the target.

I have no such #includes which is probably the entire source of the
issue, but I cannot figure out exactly what to do because of ambiguities
in the above documentation concerning what should be in the header
and what should be in the source file.

To be explicit suppose you have some source code named fooqt.cpp
which contains

#include "barqt.h"

which declares some classes for the software package that refer to Q_OBJECT
and some classes that do not refer to Q_OBJECT.

What is the #include recipe to get automoc to work for this specific case?

In the next few hours I plan to try some #include variations allowed
by the ambiguities of the above documentation so I may eventually
answer my own question by these experiments.  But it would be nice to
get a definitive answer.

@CMake developers: It would be nice to also have an automoc
documentation fix for those ambiguities since the #include pattern in
the source code must be different than what works for older Qt5
support methods that do not use automoc.

Alan

__
Alan W. Irwin

Astronomical research affiliation with Department of Physics

Re: [CMake] How to configure CMake to add current path to include directive.

2016-10-16 Thread Craig Scott 
Something like the following was what I had in mind (untested):

get_target_property(incDirs someTarget INCLUDE_DIRECTORIES)
list(APPEND incDirs .)
set_target_properties(someTarget PROPERTIES INCLUDE_DIRECTORIES
"${incDirs}")


On Mon, Oct 17, 2016 at 10:31 AM, Steve Lorimer 
wrote:

> Thanks Craig
>
> Not sure if I'm doing it right, but I couldn't get that to work.
>
> Would you be able to give me an example please?
>
> Thanks
> Steve
>
>
>
> On 16 October 2016 at 17:51, Craig Scott  wrote:
>
>> I think if you manipulate the target property INCLUDE_DIRECTORIES
>> 
>> directly, you should be able to force a "." in there without having it
>> substituted for an absolute path. By this I mean use set_property() or
>> set_target_properties() rather than target_include_directories() or
>> include_directories(). Note, however, that the documentation for the
>> INCLUDE_DIRECTORIES property explicitly recommends against adding relative
>> paths to the property like this (but in your case it sounds like you really
>> want a relative path, so maybe this is a valid exception to that advice).
>>
>>
>>
>> On Mon, Oct 17, 2016 at 9:46 AM, Steve Lorimer 
>> wrote:
>>
>>> In makefile parlance, I'm trying to add -I. (ie: the current directory)
>>> to my include paths
>>>
>>> I tried the following:
>>>
>>> include_directories(".")
>>>
>>>
>>> This doesn't work unfortunately, as relative paths are interpreted as
>>> relative to the current source directory
>>> 
>>>
>>> That is, if this statement is in my top level CMakeLists.txt, located in
>>> ~/src/project, the include directive added will be "-I ~/src/project/.",
>>> whereas I'm trying to add "-I ."
>>>
>>> The reason for my wanting this is that we have sources for a single
>>> library in several subdirs.
>>>
>>> include_directories(${CMAKE_CURRENT_SOURCE_DIR})
>>>
>>> add_library(
>>> foo
>>> STATIC
>>> foo.cpp
>>> bar/bar.cpp
>>> )
>>>
>>> In bar/bar.cpp, I have a relative include
>>>
>>> #include "../foo.h"
>>>
>>> With the above setup, this will fail to compile as only
>>> ~/src/project/foo will be added to the include paths.
>>>
>>> I'm aware that if I explicitly added the path it would work
>>>
>>> include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)
>>>
>>> However, if there is a way to get -I. added to my include path, that's
>>> what I'm after.
>>>
>>> TIA
>>> Steve
>>>
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>>
>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to configure CMake to add current path to include directive.

2016-10-16 Thread Steve Lorimer 
Thanks Craig

Not sure if I'm doing it right, but I couldn't get that to work.

Would you be able to give me an example please?

Thanks
Steve



On 16 October 2016 at 17:51, Craig Scott  wrote:

> I think if you manipulate the target property INCLUDE_DIRECTORIES
> 
> directly, you should be able to force a "." in there without having it
> substituted for an absolute path. By this I mean use set_property() or
> set_target_properties() rather than target_include_directories() or
> include_directories(). Note, however, that the documentation for the
> INCLUDE_DIRECTORIES property explicitly recommends against adding relative
> paths to the property like this (but in your case it sounds like you really
> want a relative path, so maybe this is a valid exception to that advice).
>
>
>
> On Mon, Oct 17, 2016 at 9:46 AM, Steve Lorimer 
> wrote:
>
>> In makefile parlance, I'm trying to add -I. (ie: the current directory)
>> to my include paths
>>
>> I tried the following:
>>
>> include_directories(".")
>>
>>
>> This doesn't work unfortunately, as relative paths are interpreted as
>> relative to the current source directory
>> 
>>
>> That is, if this statement is in my top level CMakeLists.txt, located in
>> ~/src/project, the include directive added will be "-I ~/src/project/.",
>> whereas I'm trying to add "-I ."
>>
>> The reason for my wanting this is that we have sources for a single
>> library in several subdirs.
>>
>> include_directories(${CMAKE_CURRENT_SOURCE_DIR})
>>
>> add_library(
>> foo
>> STATIC
>> foo.cpp
>> bar/bar.cpp
>> )
>>
>> In bar/bar.cpp, I have a relative include
>>
>> #include "../foo.h"
>>
>> With the above setup, this will fail to compile as only ~/src/project/foo
>> will be added to the include paths.
>>
>> I'm aware that if I explicitly added the path it would work
>>
>> include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)
>>
>> However, if there is a way to get -I. added to my include path, that's
>> what I'm after.
>>
>> TIA
>> Steve
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to configure CMake to add current path to include directive.

2016-10-16 Thread Craig Scott 
I think if you manipulate the target property INCLUDE_DIRECTORIES

directly, you should be able to force a "." in there without having it
substituted for an absolute path. By this I mean use set_property() or
set_target_properties() rather than target_include_directories() or
include_directories(). Note, however, that the documentation for the
INCLUDE_DIRECTORIES property explicitly recommends against adding relative
paths to the property like this (but in your case it sounds like you really
want a relative path, so maybe this is a valid exception to that advice).



On Mon, Oct 17, 2016 at 9:46 AM, Steve Lorimer 
wrote:

> In makefile parlance, I'm trying to add -I. (ie: the current directory) to
> my include paths
>
> I tried the following:
>
> include_directories(".")
>
>
> This doesn't work unfortunately, as relative paths are interpreted as
> relative to the current source directory
> 
>
> That is, if this statement is in my top level CMakeLists.txt, located in
> ~/src/project, the include directive added will be "-I ~/src/project/.",
> whereas I'm trying to add "-I ."
>
> The reason for my wanting this is that we have sources for a single
> library in several subdirs.
>
> include_directories(${CMAKE_CURRENT_SOURCE_DIR})
>
> add_library(
> foo
> STATIC
> foo.cpp
> bar/bar.cpp
> )
>
> In bar/bar.cpp, I have a relative include
>
> #include "../foo.h"
>
> With the above setup, this will fail to compile as only ~/src/project/foo
> will be added to the include paths.
>
> I'm aware that if I explicitly added the path it would work
>
> include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)
>
> However, if there is a way to get -I. added to my include path, that's
> what I'm after.
>
> TIA
> Steve
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] How to configure CMake to add current path to include directive.

2016-10-16 Thread Steve Lorimer 
In makefile parlance, I'm trying to add -I. (ie: the current directory) to
my include paths

I tried the following:

include_directories(".")


This doesn't work unfortunately, as relative paths are interpreted as
relative to the current source directory


That is, if this statement is in my top level CMakeLists.txt, located in
~/src/project, the include directive added will be "-I ~/src/project/.",
whereas I'm trying to add "-I ."

The reason for my wanting this is that we have sources for a single library
in several subdirs.

include_directories(${CMAKE_CURRENT_SOURCE_DIR})

add_library(
foo
STATIC
foo.cpp
bar/bar.cpp
)

In bar/bar.cpp, I have a relative include

#include "../foo.h"

With the above setup, this will fail to compile as only ~/src/project/foo
will be added to the include paths.

I'm aware that if I explicitly added the path it would work

include_directories(${CMAKE_CURRENT_SOURCE_DIR}/bar)

However, if there is a way to get -I. added to my include path, that's what
I'm after.

TIA
Steve
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Cannot get automoc to work properly with recommended Qt5 support method

2016-10-16 Thread Alan W. Irwin 

On 2016-10-16 13:43-0700 Alan W. Irwin wrote:


To move to a related topic, the above URL has a tutorial example for
the recommended support method which builds the helloworld target from
main.cpp.  It would be nice for Qt5 users to learn from that tutorial
example by building it themselves, but that example is incomplete
since no main.cpp (presumably Qt5-related) is provided (as far as I
can discover).  Any chance you could provide that simple example for
developers like me who don't have a lot of Qt5 or C++ expertise but
who just want to build other's Qt5-related work using the best
CMake-related methods?


Hi Stephen:

Further to this particular subtopic, a google search found me several
qt hello world examples.  The most prominent one does not work (it
uses an ancient method which is no longer supported by Qt!), but
I found that the one in  does work
perfectly with the tutorial Qt5 cmake example.  So I request you
make that hello world routine (or something closely related) available
at  to make that tutorial
more self-contained.

That said, there are no issues with setting macros in this simple
hello world case so it doesn't help with the principal issue covered
in my e-mail where I cannot seem to set the macros needed for automoc
to work properly.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Cannot get automoc to work properly with recommended Qt5 support method

2016-10-16 Thread Alan W. Irwin 

Hi Stephen:

I am addressing you directly (as well as the list) because you have
been so helpful with Qt5 issues in the past.

The PLplot build system (some of whose components depend on Qt5)
currently uses one of the older Qt5 support methods documented at
.  But that method is complex
and we are currently running into troubles with it where it uses the
plain target_link_libraries command which conflicts with the keyworded
version that we prefer for our build system.  So I have attempted to
update our Qt5 support to the latest target_link_libraries method
documented at the above URL, but automoc appears not to be working
correctly.

I follow the advice in the above URL and set

set(CMAKE_AUTOMOC ON)

and also set AUTOMOC_MOC_OPTIONS to the following list:

-DPLD_bmpqt;-DPLD_jpgqt;-DPLD_pngqt;-DPLD_ppmqt;-DPLD_tiffqt;-DPLD_svgqt;-DPLD_pdfqt;-DPLD_qtwidget;-DPLD_extqt;-DPLD_memqt

This list is the same as I use for MOC_OPTIONS in the old working method, and
these various macro definitions _must_ be defined to avoid dropping large
swaths of our code from the compilation.  Instead of using

set(CMAKE_INCLUDE_CURRENT_DIR ON)

I use instead (in the directory where the plplotqt library is built)

include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ...)

Furthermore, in that same directory I use

target_link_libraries(plplotqt PRIVATE plplot ${MATH_LIB} Qt5::Svg Qt5::Gui 
Qt5::PrintSupport)

for the build.  Although that build apparently works with no obvious
issues, there is no sign of any of the above macros in the
VERBOSE=1 output.  Furthermore, I get the following near-empty result
for the generated bindings/qt_gui/plplotqt_automoc.cpp file which
consists just of the following two lines:

/* This file is autogenerated, do not edit*/
enum some_compilers { need_more_than_nothing };

Finally,

"ldd -r bindings/qt_gui/libplplotqt.st"

shows missing symbols that should be defined if the above macros are
defined.

What am I missing?

To move to a related topic, the above URL has a tutorial example for
the recommended support method which builds the helloworld target from
main.cpp.  It would be nice for Qt5 users to learn from that tutorial
example by building it themselves, but that example is incomplete
since no main.cpp (presumably Qt5-related) is provided (as far as I
can discover).  Any chance you could provide that simple example for
developers like me who don't have a lot of Qt5 or C++ expertise but
who just want to build other's Qt5-related work using the best
CMake-related methods?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-549-ga23f4f0

2016-10-16 Thread Gregor Jasny via Cmake-commits 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  a23f4f0666fdbfb7ab75635f62e216b5d5d158d0 (commit)
   via  9ce8fbf522e84f3f596e90453b4c652514a00099 (commit)
  from  54379cab91d6b2d6940d65fa8dd31530bd30ae52 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a23f4f0666fdbfb7ab75635f62e216b5d5d158d0
commit a23f4f0666fdbfb7ab75635f62e216b5d5d158d0
Merge: 54379ca 9ce8fbf
Author: Gregor Jasny 
AuthorDate: Sun Oct 16 15:32:13 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Sun Oct 16 15:32:13 2016 -0400

Merge topic 'refactor-folder-name-retrieval' into next

9ce8fbf5 Refactor IDE folder name retrieval into GetEffectiveFolderName()


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ce8fbf522e84f3f596e90453b4c652514a00099
commit 9ce8fbf522e84f3f596e90453b4c652514a00099
Author: Gregor Jasny 
AuthorDate: Tue Aug 30 20:55:37 2016 +0200
Commit: Gregor Jasny 
CommitDate: Sun Oct 16 21:27:47 2016 +0200

Refactor IDE folder name retrieval into GetEffectiveFolderName()

diff --git a/Source/cmGeneratorTarget.cxx b/Source/cmGeneratorTarget.cxx
index 7eb0ebf..eb9f419 100644
--- a/Source/cmGeneratorTarget.cxx
+++ b/Source/cmGeneratorTarget.cxx
@@ -1767,6 +1767,22 @@ std::string cmGeneratorTarget::GetMacContentDirectory(
   return fpath;
 }
 
+std::string cmGeneratorTarget::GetEffectiveFolderName() const
+{
+std::string effectiveFolder;
+
+if (!this->GlobalGenerator->UseFolderProperty()) {
+return effectiveFolder;
+}
+
+const char* targetFolder = this->GetProperty("FOLDER");
+if (targetFolder) {
+effectiveFolder += targetFolder;
+}
+
+return effectiveFolder;
+}
+
 cmGeneratorTarget::CompileInfo const* cmGeneratorTarget::GetCompileInfo(
   const std::string& config) const
 {
diff --git a/Source/cmGeneratorTarget.h b/Source/cmGeneratorTarget.h
index 68ffd5c..9382726 100644
--- a/Source/cmGeneratorTarget.h
+++ b/Source/cmGeneratorTarget.h
@@ -220,6 +220,9 @@ public:
   std::string GetMacContentDirectory(const std::string& config = CM_NULLPTR,
  bool implib = false) const;
 
+  /** @return folder prefix for IDEs. */
+  std::string GetEffectiveFolderName() const;
+
   cmTarget* Target;
   cmMakefile* Makefile;
   cmLocalGenerator* LocalGenerator;
diff --git a/Source/cmGhsMultiTargetGenerator.cxx 
b/Source/cmGhsMultiTargetGenerator.cxx
index 5fbaea4..3154f8d 100644
--- a/Source/cmGhsMultiTargetGenerator.cxx
+++ b/Source/cmGhsMultiTargetGenerator.cxx
@@ -44,9 +44,7 @@ cmGhsMultiTargetGenerator::~cmGhsMultiTargetGenerator()
 std::string cmGhsMultiTargetGenerator::GetRelBuildFilePath(
   const cmGeneratorTarget* target)
 {
-  std::string output;
-  char const* folderProp = target->GetProperty("FOLDER");
-  output = NULL == folderProp ? "" : folderProp;
+  std::string output = target->GetEffectiveFolderName();
   cmSystemTools::ConvertToUnixSlashes(output);
   if (!output.empty()) {
 output += "/";
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 1aa6af1..7d0c2da 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -2377,7 +2377,7 @@ const char* 
cmGlobalGenerator::GetPredefinedTargetsFolder()
   return "CMakePredefinedTargets";
 }
 
-bool cmGlobalGenerator::UseFolderProperty()
+bool cmGlobalGenerator::UseFolderProperty() const
 {
   const char* prop =
 this->GetCMakeInstance()->GetState()->GetGlobalProperty("USE_FOLDERS");
diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index 38eaa76..c3498e0 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -334,6 +334,8 @@ public:
   i.e. "Can I build Debug and Release in the same tree?" */
   virtual bool IsMultiConfig() const { return false; }
 
+  virtual bool UseFolderProperty() const;
+
   std::string GetSharedLibFlagsForLanguage(std::string const& lang) const;
 
   /** Generate an .rule file path for a given command output.  */
@@ -463,7 +465,6 @@ protected:
 std::string const& name) const;
 
   const char* GetPredefinedTargetsFolder();
-  virtual bool UseFolderProperty();
 
 private:
 #if defined(CMAKE_BUILD_WITH_CMAKE)
diff --git a/Source/cmGlobalGhsMultiGenerator.cxx 
b/Source/cmGlobalGhsMultiGenerator.cxx
index 0eac338..d4ae677 100644
--- a/Source/cmGlobalGhsMultiGenerator.cxx
+++ b/Source/cmGlobalGhsMultiGenerator.cxx
@@ -439,11 +439,7 @@ void cmGlobalGhsMultiGenerator::UpdateBuildFiles(
tgtsI != tgts.end(); ++tgtsI) {
 const cmGeneratorTarget* tgt =

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-547-g54379ca

2016-10-16 Thread Gregor Jasny via Cmake-commits 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  54379cab91d6b2d6940d65fa8dd31530bd30ae52 (commit)
   via  25dbc485565649f54d64b57f6a35b651b8a15165 (commit)
   via  5ebba228823ffc96e82f4b6cc1103c2f2ed8cfa7 (commit)
   via  ac5b80e76c102d43749555c9bc888f9ac9b7436e (commit)
  from  1ebf57341d671befa62b4065b7565a01f1fe06aa (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=54379cab91d6b2d6940d65fa8dd31530bd30ae52
commit 54379cab91d6b2d6940d65fa8dd31530bd30ae52
Merge: 1ebf573 25dbc48
Author: Gregor Jasny 
AuthorDate: Sun Oct 16 15:24:51 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Sun Oct 16 15:24:51 2016 -0400

Merge topic '16355-osx-deployment-target-on-cross-compile' into next

25dbc485 Darwin: Do not try to set deployment target when crosscompiling 
(#16355)
5ebba228 CMake Nightly Date Stamp
ac5b80e7 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=25dbc485565649f54d64b57f6a35b651b8a15165
commit 25dbc485565649f54d64b57f6a35b651b8a15165
Author: Gregor Jasny 
AuthorDate: Sun Oct 16 20:56:36 2016 +0200
Commit: Gregor Jasny 
CommitDate: Sun Oct 16 20:59:27 2016 +0200

Darwin: Do not try to set deployment target when crosscompiling (#16355)

diff --git a/Modules/Platform/Darwin-Initialize.cmake 
b/Modules/Platform/Darwin-Initialize.cmake
index 427909d..39374e1 100644
--- a/Modules/Platform/Darwin-Initialize.cmake
+++ b/Modules/Platform/Darwin-Initialize.cmake
@@ -90,7 +90,7 @@ elseif("${CMAKE_GENERATOR}" MATCHES Xcode
   endif()
 endforeach()
 
-if(NOT CMAKE_OSX_DEPLOYMENT_TARGET AND _CURRENT_OSX_VERSION VERSION_LESS 
_CMAKE_OSX_DEPLOYMENT_TARGET)
+if(NOT CMAKE_CROSSCOMPILING AND NOT CMAKE_OSX_DEPLOYMENT_TARGET AND 
_CURRENT_OSX_VERSION VERSION_LESS _CMAKE_OSX_DEPLOYMENT_TARGET)
   set(CMAKE_OSX_DEPLOYMENT_TARGET ${_CURRENT_OSX_VERSION} CACHE STRING
 "Minimum OS X version to target for deployment (at runtime); newer 
APIs weak linked. Set to empty string for default value." FORCE)
 endif()

---

Summary of changes:
 Modules/Platform/Darwin-Initialize.cmake |2 +-
 Source/CMakeVersion.cmake|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Editing IMPORTED targets

2016-10-16 Thread Stephen Kelly 
Ivan Shapovalov wrote:

> On 2016-10-03 at 14:43 +0200, Stephen Kelly wrote:
>> Ivan Shapovalov wrote:
>> 
>> > Hello!
>> > 
>> > Using find modules to detect dependencies has a nice feature: it is
>> > then possible to edit the resulting cache entries to link to
>> > different
>> > libraries (or add other libraries along the found ones, for
>> > whatever
>> > purposes), or change directories, or flags, or whatever.
>> > 
>> > Using find configs and IMPORTED targets, however, prevents doing
>> > this,
>> > because IMPORTED targets are not stored in CMake cache. This can be
>> > a
>> > significant disadvantage at times.
>> 
>> Can you be more specific?
>> 
>> Why can the user provide better information than the supplier of the
>> IMPORTED target?
>> 
>> Thanks,
>> 
>> Steve.
>> 
>> 
> 
> Well, sometimes you need to do certain "maintainer-specific" overrides:
> include custom headers before everything, link to custom libraries
> before everything and so on. Think LD_PRELOAD, but at link time.

What is a 'maintainer' in that sentence? A 'maintainer' can change the 
buildsystem CMake files. I suspect that's not an actor you mean. If you can 
be more specific maybe I will understand.

Would 'wrapping' be a good solution?

 add_library(foo_wrapper INTERFACE)
 target_include_directories(foo_wrapper INTERFACE
   ${custom_includes}
   $
 )
 target_link_libraries(foo_wrapper INTERFACE
   ${custom_libraries}
   Foo::foo
 )


Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Editing IMPORTED targets

2016-10-16 Thread Ivan Shapovalov 
On 2016-10-03 at 14:43 +0200, Stephen Kelly wrote:
> Ivan Shapovalov wrote:
> 
> > Hello!
> > 
> > Using find modules to detect dependencies has a nice feature: it is
> > then possible to edit the resulting cache entries to link to
> > different
> > libraries (or add other libraries along the found ones, for
> > whatever
> > purposes), or change directories, or flags, or whatever.
> > 
> > Using find configs and IMPORTED targets, however, prevents doing
> > this,
> > because IMPORTED targets are not stored in CMake cache. This can be
> > a
> > significant disadvantage at times.
> 
> Can you be more specific?
> 
> Why can the user provide better information than the supplier of the 
> IMPORTED target?
> 
> Thanks,
> 
> Steve.
> 
> 

Well, sometimes you need to do certain "maintainer-specific" overrides:
include custom headers before everything, link to custom libraries
before everything and so on. Think LD_PRELOAD, but at link time.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-539-g0e69f51

2016-10-16 Thread Stephen Kelly 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  0e69f517951fefc4f4917d3101259c8a7a7fbc66 (commit)
   via  75ace0a67d0b57eecaf1862e8a5dc68efa0a724b (commit)
  from  d1f0e3064827cbaa929e8d55ae69ec40fda43a45 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e69f517951fefc4f4917d3101259c8a7a7fbc66
commit 0e69f517951fefc4f4917d3101259c8a7a7fbc66
Merge: d1f0e30 75ace0a
Author: Stephen Kelly 
AuthorDate: Sun Oct 16 07:54:59 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Sun Oct 16 07:54:59 2016 -0400

Merge topic 'extract-computed-target-properties' into next

75ace0a6 fixup! cmTarget: Move sanity checks and computed property access 
to callers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=75ace0a67d0b57eecaf1862e8a5dc68efa0a724b
commit 75ace0a67d0b57eecaf1862e8a5dc68efa0a724b
Author: Stephen Kelly 
AuthorDate: Sun Oct 16 13:54:29 2016 +0200
Commit: Stephen Kelly 
CommitDate: Sun Oct 16 13:54:29 2016 +0200

fixup! cmTarget: Move sanity checks and computed property access to callers

diff --git a/Source/cmGetPropertyCommand.cxx b/Source/cmGetPropertyCommand.cxx
index 0a59933..39445dd 100644
--- a/Source/cmGetPropertyCommand.cxx
+++ b/Source/cmGetPropertyCommand.cxx
@@ -10,16 +10,6 @@
 #include "cmTest.h"
 #include "cmake.h"
 
-#ifdef __clang__
-extern template const char* cmTargetPropertyComputer::ComputeLocationForBuild(
-  cmTarget const* tgt);
-extern template const char* cmTargetPropertyComputer::ComputeLocation(
-  cmTarget const* tgt, std::string const& config);
-extern template const char* cmTargetPropertyComputer::GetSources(
-  cmTarget const* tgt, cmMessenger* messenger,
-  cmListFileBacktrace const& context);
-#endif
-
 cmGetPropertyCommand::cmGetPropertyCommand()
 {
   this->InfoType = OutValue;
@@ -262,8 +252,8 @@ bool cmGetPropertyCommand::HandleTargetMode()
 cmMessenger* messenger = this->Makefile->GetMessenger();
 if (cmTargetPropertyComputer::PassesWhitelist(
   target->GetType(), this->PropertyName, messenger, bt)) {
-  prop_cstr = cmTargetPropertyComputer::GetProperty(
-target, this->PropertyName, messenger, bt);
+  prop_cstr =
+target->GetComputedProperty(this->PropertyName, messenger, bt);
   if (!prop_cstr) {
 prop_cstr = target->GetProperty(this->PropertyName);
   }
diff --git a/Source/cmGetTargetPropertyCommand.cxx 
b/Source/cmGetTargetPropertyCommand.cxx
index d009bc3..6a816d8 100644
--- a/Source/cmGetTargetPropertyCommand.cxx
+++ b/Source/cmGetTargetPropertyCommand.cxx
@@ -4,16 +4,6 @@
 
 #include "cmTargetPropertyComputer.h"
 
-#ifdef __clang__
-extern template const char* cmTargetPropertyComputer::ComputeLocationForBuild(
-  cmTarget const* tgt);
-extern template const char* cmTargetPropertyComputer::ComputeLocation(
-  cmTarget const* tgt, std::string const& config);
-extern template const char* cmTargetPropertyComputer::GetSources(
-  cmTarget const* tgt, cmMessenger* messenger,
-  cmListFileBacktrace const& context);
-#endif
-
 // cmSetTargetPropertyCommand
 bool cmGetTargetPropertyCommand::InitialPass(
   std::vector const& args, cmExecutionStatus&)
@@ -39,8 +29,7 @@ bool cmGetTargetPropertyCommand::InitialPass(
   cmMessenger* messenger = this->Makefile->GetMessenger();
   if (cmTargetPropertyComputer::PassesWhitelist(tgt->GetType(), args[2],
 messenger, bt)) {
-prop_cstr =
-  cmTargetPropertyComputer::GetProperty(tgt, args[2], messenger, bt);
+prop_cstr = tgt->GetComputedProperty(args[2], messenger, bt);
 if (!prop_cstr) {
   prop_cstr = tgt->GetProperty(args[2]);
 }
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index b2b7cd6..3a22309 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -1129,6 +1129,13 @@ void cmTarget::CheckProperty(const std::string& prop,
   }
 }
 
+const char* cmTarget::GetComputedProperty(
+  const std::string& prop, cmMessenger* messenger,
+  cmListFileBacktrace const& context) const
+{
+  return cmTargetPropertyComputer::GetProperty(this, prop, messenger, context);
+}
+
 const char* cmTarget::GetProperty(const std::string& prop) const
 {
   static UNORDERED_SET specialProps;
diff --git a/Source/cmTarget.h b/Source/cmTarget.h
index d48e7e2..bd00b3d 100644
--- a/Source/cmTarget.h
+++ b/Source/cmTarget.h
@@ -202,6 +202,9 @@ public:
   const char* GetProperty(const std::string& prop) const;
   bool GetPropertyAsBool(const std::string& prop) const;

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-537-gd1f0e30

2016-10-16 Thread Stephen Kelly 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  d1f0e3064827cbaa929e8d55ae69ec40fda43a45 (commit)
   via  d94460ce3ff089c7746d24378f899008a2e5385d (commit)
   via  4b9292a9458d25a9394190de5ac9d9d056768070 (commit)
   via  a89dc5374b8798e6dbe699b7a074ec7cd9be36e8 (commit)
  from  0fde927b36aa8972da15fefa3e0f01ee22c6bcef (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1f0e3064827cbaa929e8d55ae69ec40fda43a45
commit d1f0e3064827cbaa929e8d55ae69ec40fda43a45
Merge: 0fde927b d94460c
Author: Stephen Kelly 
AuthorDate: Sun Oct 16 06:09:54 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Sun Oct 16 06:09:54 2016 -0400

Merge topic 'extract-computed-target-properties' into next

d94460ce cmTarget: Implement GetProperty in terms of cmState::Snapshot
4b9292a9 cmTarget: Group code for checking written properties together
a89dc537 cmTarget: Move sanity checks and computed property access to 
callers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d94460ce3ff089c7746d24378f899008a2e5385d
commit d94460ce3ff089c7746d24378f899008a2e5385d
Author: Stephen Kelly 
AuthorDate: Thu Oct 13 00:18:26 2016 +0200
Commit: Stephen Kelly 
CommitDate: Sun Oct 16 12:09:43 2016 +0200

cmTarget: Implement GetProperty in terms of cmState::Snapshot

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index d8bc64a..b2b7cd6 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -1215,10 +1215,16 @@ const char* cmTarget::GetProperty(const std::string& 
prop) const
   return this->GetName().c_str();
 }
 if (prop == propBINARY_DIR) {
-  return this->GetMakefile()->GetCurrentBinaryDirectory();
+  return this->GetMakefile()
+->GetStateSnapshot()
+.GetDirectory()
+.GetCurrentBinary();
 }
 if (prop == propSOURCE_DIR) {
-  return this->GetMakefile()->GetCurrentSourceDirectory();
+  return this->GetMakefile()
+->GetStateSnapshot()
+.GetDirectory()
+.GetCurrentSource();
 }
   }
 
@@ -1227,7 +1233,8 @@ const char* cmTarget::GetProperty(const std::string& 
prop) const
 const bool chain = this->GetMakefile()->GetState()->IsPropertyChained(
   prop, cmProperty::TARGET);
 if (chain) {
-  return this->Makefile->GetProperty(prop, chain);
+  return this->Makefile->GetStateSnapshot().GetDirectory().GetProperty(
+prop, chain);
 }
   }
   return retVal;

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b9292a9458d25a9394190de5ac9d9d056768070
commit 4b9292a9458d25a9394190de5ac9d9d056768070
Author: Stephen Kelly 
AuthorDate: Thu Oct 13 00:18:26 2016 +0200
Commit: Stephen Kelly 
CommitDate: Sun Oct 16 12:09:42 2016 +0200

cmTarget: Group code for checking written properties together

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index ef13b26..d8bc64a 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -852,7 +852,20 @@ void cmTarget::SetProperty(const std::string& prop, const 
char* value)
 e << "NAME property is read-only\n";
 this->Makefile->IssueMessage(cmake::FATAL_ERROR, e.str());
 return;
+  } else if (prop == "EXPORT_NAME" && this->IsImported()) {
+std::ostringstream e;
+e << "EXPORT_NAME property can't be set on imported targets (\""
+  << this->Name << "\")\n";
+this->Makefile->IssueMessage(cmake::FATAL_ERROR, e.str());
+return;
+  } else if (prop == "SOURCES" && this->IsImported()) {
+std::ostringstream e;
+e << "SOURCES property can't be set on imported targets (\"" << this->Name
+  << "\")\n";
+this->Makefile->IssueMessage(cmake::FATAL_ERROR, e.str());
+return;
   }
+
   if (prop == "INCLUDE_DIRECTORIES") {
 this->Internal->IncludeDirectoriesEntries.clear();
 this->Internal->IncludeDirectoriesBacktraces.clear();
@@ -885,11 +898,6 @@ void cmTarget::SetProperty(const std::string& prop, const 
char* value)
   cmListFileBacktrace lfbt = this->Makefile->GetBacktrace();
   this->Internal->CompileDefinitionsBacktraces.push_back(lfbt);
 }
-  } else if (prop == "EXPORT_NAME" && this->IsImported()) {
-std::ostringstream e;
-e << "EXPORT_NAME property can't be set on imported targets (\""
-  << this->Name << "\")\n";
-this->Makefile->IssueMessage(cmake::FATAL_ERROR, e.str());
   } else if (prop == "LINK_LIBRARIES") {
 this->Internal->LinkImplementationPropertyEntries.clear();

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-533-g0fde927b

2016-10-16 Thread Stephen Kelly 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  0fde927b36aa8972da15fefa3e0f01ee22c6bcef (commit)
   via  d1e7a46ad99e411a20740ffa651f9affee9ae427 (commit)
  from  2c0f3a34e5bd163b5194da61c9d1c0d89dc4f68d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0fde927b36aa8972da15fefa3e0f01ee22c6bcef
commit 0fde927b36aa8972da15fefa3e0f01ee22c6bcef
Merge: 2c0f3a3 d1e7a46
Author: Stephen Kelly 
AuthorDate: Sun Oct 16 06:09:30 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Sun Oct 16 06:09:30 2016 -0400

Merge topic 'extract-computed-target-properties' into next

d1e7a46a fixup! cmTarget: Move sanity checks and computed property access 
to callers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1e7a46ad99e411a20740ffa651f9affee9ae427
commit d1e7a46ad99e411a20740ffa651f9affee9ae427
Author: Stephen Kelly 
AuthorDate: Sun Oct 16 12:08:55 2016 +0200
Commit: Stephen Kelly 
CommitDate: Sun Oct 16 12:08:55 2016 +0200

fixup! cmTarget: Move sanity checks and computed property access to callers

diff --git a/Source/cmGetPropertyCommand.cxx b/Source/cmGetPropertyCommand.cxx
index b38950a..0a59933 100644
--- a/Source/cmGetPropertyCommand.cxx
+++ b/Source/cmGetPropertyCommand.cxx
@@ -10,6 +10,16 @@
 #include "cmTest.h"
 #include "cmake.h"
 
+#ifdef __clang__
+extern template const char* cmTargetPropertyComputer::ComputeLocationForBuild(
+  cmTarget const* tgt);
+extern template const char* cmTargetPropertyComputer::ComputeLocation(
+  cmTarget const* tgt, std::string const& config);
+extern template const char* cmTargetPropertyComputer::GetSources(
+  cmTarget const* tgt, cmMessenger* messenger,
+  cmListFileBacktrace const& context);
+#endif
+
 cmGetPropertyCommand::cmGetPropertyCommand()
 {
   this->InfoType = OutValue;
diff --git a/Source/cmGetTargetPropertyCommand.cxx 
b/Source/cmGetTargetPropertyCommand.cxx
index 94f8942..d009bc3 100644
--- a/Source/cmGetTargetPropertyCommand.cxx
+++ b/Source/cmGetTargetPropertyCommand.cxx
@@ -4,6 +4,16 @@
 
 #include "cmTargetPropertyComputer.h"
 
+#ifdef __clang__
+extern template const char* cmTargetPropertyComputer::ComputeLocationForBuild(
+  cmTarget const* tgt);
+extern template const char* cmTargetPropertyComputer::ComputeLocation(
+  cmTarget const* tgt, std::string const& config);
+extern template const char* cmTargetPropertyComputer::GetSources(
+  cmTarget const* tgt, cmMessenger* messenger,
+  cmListFileBacktrace const& context);
+#endif
+
 // cmSetTargetPropertyCommand
 bool cmGetTargetPropertyCommand::InitialPass(
   std::vector const& args, cmExecutionStatus&)

---

Summary of changes:
 Source/cmGetPropertyCommand.cxx   |   10 ++
 Source/cmGetTargetPropertyCommand.cxx |   10 ++
 2 files changed, 20 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits