Thanks Matt.
I just +1 the issue.
Jc
On Tue, Jun 10, 2014 at 7:39 PM, wrote:
> I raised an issue in the Qt bug tracker for this
> https://bugreports.qt-project.org/browse/QTBUG-39457 - everyone should go
> vote for it J
>
>
>
> Matt
>
>
>
> *From:* CMake [mailto:cmake-boun...@cmake.org] *On Be
I raised an issue in the Qt bug tracker for this
https://bugreports.qt-project.org/browse/QTBUG-39457 - everyone should go vote
for it ☺
Matt
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Andrew Maclean
Sent: Wednesday, 11 June 2014 9:20 AM
To: VTK Developers; vtk; cmake@cmake.org
S
Hi All,
Just a quick note about Policy CMP0043.
When using CMake 3.0 and Qt5.3 these two files will generate the CMake
Warning:
"Policy CMP0043 is not set: Ignore COMPILE_DEFINITIONS_ properties."
$QTDIR/lib/cmake/Qt5Core/Qt5CoreMacros.cmake
$QTDIR/../Src/qtbase/src/corelib/Qt5CoreMacros.cmake
T
On behalf of myself, Ken, Bill, Brad, David, Alex, Eike, Steve, Zach, Ben,
Peter, Nils, and the rest of the CMake team from all around the world, we are
pleased to announce that CMake 3.0.0 is now available for download at:
http://www.cmake.org/files/v3.0/?C=M;O=D
Documentation is available at:
I'm not the author of the libraries, and none of them are cmake friendly. So
it doesn't make sense to create FOOconfig.cmake files for them. Using the
command line -D or adding env variables to add new search directories,
seems like an unnecessary headache for the user (our windows users esp
would
On 10.06.2014 19:48, jmerkow wrote:
Basically, the scenario I'm using this is when libraries are in some unknown
location, but the location can be set during the configure step.
In our case we have a number of external libraries that aren't (and
shouldn't be) installed, so there not going to be
Basically, the scenario I'm using this is when libraries are in some unknown
location, but the location can be set during the configure step.
In our case we have a number of external libraries that aren't (and
shouldn't be) installed, so there not going to be in any of the standard
locations (I.e
That work around seems to only be useful if you wish to modify all the find
modules you wish to use.
Is there a CMake variable you could set that would allow all the
find_{include,library,path} functions within modules to pick up the HINT'ed
path first then search the system paths?
On Tue, Jun 1
On 10.06.2014 19:09, jmerkow wrote:
Is there a generally accepted method to pass extra paths to find_package in
module mode? To get around this, I have been doing something like this:
set(FOO_EXTRA_PATHS path1 path2)
Find_package(FOO)
In FindFOO.cmake:
...
set(FOO_LIB_POSSIBLE_PATHS ${FOO_EXT
Is there a generally accepted method to pass extra paths to find_package in
module mode? To get around this, I have been doing something like this:
set(FOO_EXTRA_PATHS path1 path2)
Find_package(FOO)
In FindFOO.cmake:
...
set(FOO_LIB_POSSIBLE_PATHS ${FOO_EXTRA_PATHS} /path3/)
...
(Use the possib
I was trying to get automoc to work with my Qt4.8 project in cmake-2.812,
and found out that the .h and the .cpp need to be in the same directory.
so this works:
source/main.cpp
source/MyWidget.cpp
source/MyWidget.h
where MyWidget.h contains
class MyWidget : public QWidget {
11 matches
Mail list logo
