On 02/17/2013 10:26 AM, Alexander Neundorf wrote:
On Sunday 17 February 2013, Alexander Neundorf wrote:
On Sunday 17 February 2013, Brad King wrote:
to use a directory property and then have the generate-time check
look in the current directory and up. That will avoid problems with
On 02/17/2013 10:00 AM, Alexander Neundorf wrote:
On Sunday 17 February 2013, Brad King wrote:
Just to make sure I understand correctly, you're bringing up a use case
where an imported target's dependencies are not satisfied but it does
not matter when the imported target is not used by the
On 02/17/2013 01:08 PM, Alexander Neundorf wrote:
I haven't yet figured out a good way how to add a test which tests the error
case. Is there a better way than duplicating most of ExportImport/ ?
Testing an error case is often a PITA, but it is important since the
entire point of this feature
Alexander Neundorf wrote:
On Friday 15 February 2013, Stephen Kelly wrote:
Hi,
FindPackageHandleStandardArgs sets an uppercase found variable, but not
an ExactCase_FOUND variable. This is inconsistent with how config files
work. It also imposes on users the necessity that their FOUND
On 02/17/2013 11:20 AM, Alexander Chehovsky wrote:
Also, forgot to note that patch Fixed nested source group handling in
Xcode generator. resolves this bug:
http://public.kitware.com/Bug/view.php?id=12943
I've actually posted a patch there some time ago, but it was not
noticed, apparently.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13932
==
Reported By:Neil Carlson
Assigned To:
On Monday 18 February 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Friday 15 February 2013, Stephen Kelly wrote:
Hi,
FindPackageHandleStandardArgs sets an uppercase found variable, but not
an ExactCase_FOUND variable. This is inconsistent with how config files
work. It
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13933
==
Reported By:Mathias Gaunard
Assigned To:
On Monday 18 February 2013, Brad King wrote:
On 02/17/2013 10:00 AM, Alexander Neundorf wrote:
On Sunday 17 February 2013, Brad King wrote:
Just to make sure I understand correctly, you're bringing up a use case
where an imported target's dependencies are not satisfied but it does
not
On 02/18/2013 12:33 PM, Alexander Neundorf wrote:
Or do we allow broken targets to exist (but not to be used)
Yes, this should be allowed IMO. The target import files are
effectively declarative and evaluation of dependencies should
be lazy.
It wasn't that long ago that we started supporting
On Monday 18 February 2013, Brad King wrote:
On 02/18/2013 12:33 PM, Alexander Neundorf wrote:
Or do we allow broken targets to exist (but not to be used)
Yes, this should be allowed IMO. The target import files are
effectively declarative and evaluation of dependencies should
be lazy.
On Monday 18 February 2013, Brad King wrote:
On 02/17/2013 01:08 PM, Alexander Neundorf wrote:
I haven't yet figured out a good way how to add a test which tests the
error case. Is there a better way than duplicating most of ExportImport/
?
Testing an error case is often a PITA, but it
On 02/18/2013 01:32 PM, Alexander Neundorf wrote:
On Monday 18 February 2013, Brad King wrote:
On 02/18/2013 12:33 PM, Alexander Neundorf wrote:
Or do we allow broken targets to exist (but not to be used)
Yes, this should be allowed IMO. The target import files are
effectively declarative
Alexander Neundorf wrote:
I mean, even if FPHSA would set ExactCase_FOUND always by default, there
still would be no guarantee at all that after a
find_package(Foo)
Foo_FOUND will be set, because as a user of that module I don't know
whether it uses FPHSA or not. I have to read the
On 02/18/2013 04:52 PM, Stephen Kelly wrote:
Anyway, I don't agree with your conclusion, but I guess Brad gets the
casting vote of doing nothing or not. I understand your position and you
understand mine I'm sure. All that's needed is to decide :).
One thing that has always bothered me about
Am Montag, 18. Februar 2013, 17:17:40 schrieb Brad King:
On 02/18/2013 04:52 PM, Stephen Kelly wrote:
Anyway, I don't agree with your conclusion, but I guess Brad gets the
casting vote of doing nothing or not. I understand your position and you
understand mine I'm sure. All that's needed is
Hi there,
I was able to reproduce an earlier build failure on the dashboard:
http://open.cdash.org/viewTest.php?onlyfailedbuildid=2816863
but I've not been able to reproduce this one:
http://open.cdash.org/viewTest.php?onlyfailedbuildid=2817816
I'll not get any chance to fix it this
Hi Neil.
I can only answer your question 3: there are variables like
CMAKE_Fortran_COMPILER and CMAKE_Fortran_COMPILER_ID which you could
use for this purpose. They're documented as CMAKE_LANG_COMPILER etc.
under Variables for Languages.
Petr
On Mon, Feb 18, 2013 at 1:13 AM, Neil Carlson
Hi Neil:
I have no experience with the NAG Fortran compiler, but just to
get the discussion rolling, I think I can guess at the answer to
your principal question below.
On 2013-02-17 17:13-0700 Neil Carlson wrote:
When building a shared library using the NAG Fortran compiler, cmake is
Hi, I am developing an application on windows with VS2012 and CMake (2.8.10.2).
I want to use unicode in my program, so I add UNICODE and _UNICODE with
ADD_DEFINITIONS. However, there is always a _MBCS marco in the generated
project file. The project can be compiled, but I am not happy with
Thanks, I will be using this method:
if (myvar MATCHES ^somestring$)
endif()
Do NOT use ${myvar} because that forces CMake to treat the value of myvar
as a variable name if it exists. That will give you accidentally
indirection that may point to the value of another string.
On Fri, Feb 15,
Thanks Petr, the ID variable was exactly what I needed.
On Mon, Feb 18, 2013 at 1:24 AM, Alan W. Irwin ir...@beluga.phys.uvic.cawrote:
I would also try setting
set(CMAKE_Fortran_COMPILE_**OPTIONS_PIC -PIC)
in Modules/Compiler/NAG-Fortran.**cmake as well to see if that
completely satisfies
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 a4654bb86a47bed11b702e3c09f0d7c77f2d6dff (commit)
via
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 392dbd47ff50d84da14df6096771da0fbf713d1c (commit)
via
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 1732a497c138c358229cde071a333c0ff645ab57 (commit)
via
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 523cf8a7d69df6442bd63023f3925451520bf04a (commit)
via
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 95d2dd810fc97b17a8516f5f6488aae3ee0c3c13 (commit)
via
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 0579f0660dab2bf8743e0ee8ee29b63d5cd5631d (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index bead8fb..384c26b 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
set(CMake_VERSION_MAJOR 2)
set(CMake_VERSION_MINOR 8)
set(CMake_VERSION_PATCH 10)
-set(CMake_VERSION_TWEAK 20130218
29 matches
Mail list logo
