Hi,
To CMake maintainers,
what do you think about creating new repository at
https://github.com/Kitware/CMakeModules
as incubator for contributed CMake modules?
Here is outline of the process I'm thinking of:
1. I have developed new module for find_package
2. I submit pull request adding this
On 3/27/2013 9:48 PM, William Clodius wrote:
I have been developing Fortran 2003 code on a Mac system. Because
Xcode comes with a very old version of gcc its Fortran compiler has
poor support for newer versions of Fortran, so I have been using
newer versions of gcc installed using Mac Fink, and
I am trying to migrate a fairly large project from VS 2008 to VS 2010.
However, when I use CMake to generate the Visual Studio 10 Win64 solution
(my target platform is Windows 7, x64) and try to open the solution in VS
2010, I am prompted by the conversion wizard, which I assume should not
happen.
Hi Zkhan,
Do you confirm that you configured your project in an empty new directory ?
Hth
Jc
On Thu, Mar 28, 2013 at 10:00 AM, zkhan zamir.k...@gmail.com wrote:
I am trying to migrate a fairly large project from VS 2008 to VS 2010.
However, when I use CMake to generate the Visual Studio 10
I re-did this just to confirm and yes, I start with a new, empty directory
and choose Visual Studio 10 Win64 as the generator and Use default native
compilers. If I choose Visual Studio 9 Win64, I can open the solution in
VS2008 without issues.
--
View this message in context:
Yes, with all due respect, that is pretty basic (although I understand that
there could easily be something basic going wrong here). To open the
solution file, I open Visual Studio 2010 from the windows start menu and
then use the File Open Project / Solution option to select the
generated sln
Hi,
By default solution files are probably associated with VS2008, did you make
sure you were starting VS2010, then doing File - Open and selecting the
generated solution files ?
Hth
Jc
On Thu, Mar 28, 2013 at 10:18 AM, Zamir Khan zamir.k...@gmail.com wrote:
I re-did this just to confirm and
You could try to generate the 32-bit version of your project and see if
VS2010 works as expected. Do you confirm you have the Pro version of VS2010
?
Hth
Jc
On Thu, Mar 28, 2013 at 10:37 AM, Zamir Khan zamir.k...@gmail.com wrote:
Yes, with all due respect, that is pretty basic (although I
Good idea, but unfortunately the same results with the 32-bit version. And
yes, it is VS 2010 Professional. CMake is version 2.8.10.2.
--
View this message in context:
http://cmake.3232098.n2.nabble.com/Conversion-Wizard-for-VS-2010-tp7583820p7583826.html
Sent from the CMake mailing list
What about trying CMake 2.8.11rc1 ?
See http://www.kitware.com/blog/home/post/462
On Thu, Mar 28, 2013 at 10:47 AM, Zamir Khan zamir.k...@gmail.com wrote:
Good idea, but unfortunately the same results with the 32-bit version. And
yes, it is VS 2010 Professional. CMake is version 2.8.10.2.
I upgraded, but no luck. Fortunately, I figured it out and it was fairly
simple (I really should have thought of this before posting to the mailing
list!).
I decided to go through with the conversion to see what VS 2010 was having
problems with. It turns out that only one of the projects required
CMake needs no new Find modules.
All projects should provide a project config file .cmake script
readable by CMake's find_package, and installed in a location where
CMake can find it, so that a CMake find module is completely
unnecessary.
For other types of module improvements, I think
+1
On Thu, Mar 28, 2013 at 12:25 PM, David Cole dlrd...@aol.com wrote:
CMake needs no new Find modules.
All projects should provide a project config file .cmake script readable
by CMake's find_package, and installed in a location where CMake can find
it, so that a CMake find module is
On 2013-03-28 12:25-0400 David Cole wrote:
CMake needs no new Find modules.
All projects should provide a project config file .cmake script readable by
CMake's find_package, and installed in a location where CMake can find it, so
that a CMake find module is completely unnecessary.
Hi
Hi Alan,
You could look at: https://github.com/davidsansome/python-cmake-buildsystem
More particularly this commit:
- Export targets from both the installed and build tree [1]
- Add generation of PROJECT_NAMEConfig.cmake [2]
[1]
Nice theory, but I have to deal with the real world where many projects don't
provide a project config .cmake script. They see no reason to: they don't build
with cmake, other downstreams don't build with cmake. It seems to them that
they are supporting one system, and there are hundreds. I do
On 3/28/2013 1:17 PM, Alan W. Irwin wrote:
All projects should provide a project config file .cmake script
readable by CMake's find_package, and installed in a location where
CMake can find it, so that a CMake find module is completely unnecessary.
Hi David:
Your idea sounds like a good one,
On Wednesday 27 March 2013 10:37:12 Nicola Mori wrote:
Hello, for my project I'd like to be able to configure a 32 bit build
with GCC in a 64 bit Linux environment by setting variables from command
line interface. As far as I understand of CMake, this can be
accomplished by setting
On 3/28/2013 2:19 PM, Martin Koller wrote:
I'm doing this with a toolchain file, so that cmake sees this as
cross-compiling.
E.g. I have the following toolchain file linux_i686.toolchain.cmake:
# toolchain file for building a 32bit version on a 64bit host
# use it like this:
# cmake
On 2013-03-28 13:26-0400 Jean-Christophe Fillion-Robin wrote:
Hi Alan,
You could look at: https://github.com/davidsansome/python-cmake-buildsystem
More particularly this commit:
- Export targets from both the installed and build tree [1]
- Add generation of PROJECT_NAMEConfig.cmake [2]
[1]
On Tue, Mar 19, 2013 at 3:13 AM, Ansis Māliņš ansis.mal...@gmail.com wrote:
Q: Can cmake automatically not build b when a is not available?
find_package(a)
if(a_FOUND)
ExternalProject_Add(b PREFIX blabla ...)
endif()
Hello,
If I understand correctly, this is what just happened:
Hi Folks,
I would like to discussed the usable of export(PACKAGE ...) statement.
Based on my experience, it turns out that exporting the build tree in the
system package registry is a bad idea when building the same package
multiple time as it is done on a dashboard client or a developer
On 2013-03-28 16:02, Chris Stankevitz wrote:
On Tue, Mar 19, 2013 at 3:13 AM, Ansis Māliņš wrote:
Q: Can cmake automatically not build b when a is not available?
find_package(a)
if(a_FOUND)
ExternalProject_Add(b PREFIX blabla ...)
endif()
Hello,
If I understand correctly, this is
Jean-Christophe Fillion-Robin wrote:
Hi Folks,
I would like to discussed the usable of export(PACKAGE ...) statement.
Based on my experience, it turns out that exporting the build tree in the
system package registry is a bad idea when building the same package
multiple time as it is done
On 2013-03-28 16:41- Miller Henry wrote:
[...] I have to deal with the real world where many projects don't
provide a project config .cmake script. They see no reason to: they
don't build with cmake, other downstreams don't build with cmake. It
seems to them that they are supporting one
If PROJECT_NAME_DIR is given and has a correct value, it is a bug if
find_package finds the project anywhere else. Whether that's generally
true or not, I sort of doubt it. It probably depends on the project
itself, and the find and/or config files involved.
I second Stephen's request for
I, too, live in the real world, in addition to having my theories about
it... :-)
And, for what it's worth, I'd rather add a project config file to any
project out there that would accept code contributions from me than add
yet another find module into CMake.
Obviously, there will be cases
On 3/28/2013 5:28 PM, David Cole wrote:
I, too, live in the real world, in addition to having my theories about
it... :-)
And, for what it's worth, I'd rather add a project config file to any
project out there that would accept code contributions from me than add
yet another find module into
Qt is actually the perfect example of this. Stephen Kelly has done a
superb job getting project config files working with Qt 5. That's right
-- you can actually do a find_package of Qt for Qt 5 with an existing
CMake release, *without* having a FindQt5.cmake file in CMake itself.
It's awesome!
Hello,
On 28/03/13 22:28, David Cole wrote:
I, too, live in the real world, in addition to having my theories about
it... :-)
And, for what it's worth, I'd rather add a project config file to any
project out there that would accept code contributions from me than add
yet another find
Hi Folks,
It turns out the export(PACKAGE ..) does NOT have issue, the problem was
that the value I associated with PROJECT_NAME_DIR was incorrect and since
a PROJECT_NAME package had been exported earlier, CMake found one despite
the fact an error would have been expected.
I guess it would make
Hi Yan,
Thanks much for your feedback.
However I am currently lacking time to fill in my cmake duties.
Please log that as a bug report at cmake.org/Bug.
On a related subject, I'd like to step back from my currently
maintained cmake's modules. Paraphrasing debian's vocabulary, I'd like
to
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14046
==
Reported By:Heiko Nardmann
Assigned To:
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 eb51de867ca9086a79735ae1c8eafe314f9a8ad9 (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 b86bc49fc35d68858356c5116f7073e0acf5bd09 (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 1553ae1afadad4f8f30a7c6769f2613d2f4bce98 (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, master has been updated
via 91461b48c8ff53b227ad3d0b4f59879dee130aa1 (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, master has been updated
via 9852d8f42b69bafe20055fde55ae6b2988998e2c (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, master has been updated
via 1c7833e7ae39f5145ab753492659bb73db5514f6 (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, master has been updated
via 2afcbe3090d73a7d5c81a726cb9be0efaedb858c (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, master has been updated
via 4ce263288aeb1e32f4942045be7cbc92b7daa6b8 (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, master has been updated
via 1f16bd24ee00bfdb5d50e24eaa46da2cdfa1b129 (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 acf53aede78b41dd1660e1159e28a5313bd9bead (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 2587fa8..224d5d7 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 20130328
44 matches
Mail list logo
