The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14695
==
Reported By:Juho Frits
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14696
==
Reported By:Gerry Boland
Assigned To:
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14697
==
Reported By:Christian Meyer
Assigned To:
On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
does this require a policy now ?
Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
project(Foo)
call in a subdir, which would now unset Foo_VERSION_MAJOR.
The same for PROJECT_VERSION_MAJOR, but this is maybe less
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14698
==
Reported By:Peter Kuemmel
Assigned To:
On 13/01/14 16:51, Brad King wrote:
On 01/13/2014 10:23 AM, Daniele E. Domenichelli wrote:
Can I store CMAKE_INSTALL_PREFIX in an internal cached variable, check
if it was changed since last run (i.e. CMAKE_INSTALL_PREFIX_OLD !=
CMAKE_INSTALL_PREFIX), check if the value is the default one, and
2014/1/14 Brad King brad.k...@kitware.com:
On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
does this require a policy now ?
Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
project(Foo)
call in a subdir, which would now unset Foo_VERSION_MAJOR.
The same for
On 2014-01-14 10:37, Brad King wrote:
On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
does this require a policy now ?
Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
project(Foo)
call in a subdir, which would now unset Foo_VERSION_MAJOR.
The same for
2014/1/14 Matthew Woehlke mw_tr...@users.sourceforge.net:
On 2014-01-14 10:37, Brad King wrote:
On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
does this require a policy now ?
Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
project(Foo)
call in a subdir, which
On 2014-01-14 14:11, Daniel Pfeifer wrote:
2014/1/14 Matthew Woehlke mw_tr...@users.sourceforge.net:
@Daniel, there is a CMAKE_PROJECT_NAME?
http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:CMAKE_PROJECT_NAME
http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:PROJECT_NAME
The
Hi Folks,
For both Slicer and SimpleITK, there is currently no support for the clang
c++ standard library new implementation [1] that is now used by default on
Maverick.
It means that we currently expect our users to build the project by passing
the flag:
You could call CMAKE_USER_MAKE_RULES_OVERRIDE before the first project
call. Than have that override file set the CXX_INIT flags based on the
compiler/OS/current flags.
On Tue, Jan 14, 2014 at 4:14 PM, Jean-Christophe Fillion-Robin
jchris.filli...@kitware.com wrote:
Hi Folks,
For both Slicer
On Tuesday 14 January 2014, Brad King wrote:
On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
does this require a policy now ?
Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
project(Foo)
call in a subdir, which would now unset Foo_VERSION_MAJOR.
The same for
On Tuesday 14 January 2014, Matthew Woehlke wrote:
On 2014-01-14 10:37, Brad King wrote:
On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
does this require a policy now ?
Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
project(Foo)
call in a subdir, which
On Tue, 14 Jan 2014 16:14:44 -0500, Jean-Christophe Fillion-Robin said:
For both Slicer and SimpleITK, there is currently no support for the clang
c++ standard library new implementation [1] that is now used by default on
Maverick.
It means that we currently expect our users to build the project
On 2014-01-14 18:00, Alexander Neundorf wrote:
On Tuesday 14 January 2014, Matthew Woehlke wrote:
While that sounds good for 99.9% of cases, what about the case of
project A that includes project B, where B is not updated, but A decides
to start using project(...VERSION...). Now if B was using
16 matches
Mail list logo
