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
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 ca
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
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
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. Th
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/
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13015
==
Reported By:Andrew Aladjev
Assigned To:
