From: Yury G. Kudryashov urkud.ur...@gmail.com
install(TARGETS ...) documentation described twice what happens on non-DLL
systems.
---
Source/cmInstallCommand.h |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Source/cmInstallCommand.h b/Source/cmInstallCommand.h
index
On 1/17/2012 9:53 AM, Yury G. Kudryashov wrote:
From: Yury G. Kudryashovurkud.ur...@gmail.com
A large block of code was indented 2 spaces less than it should.
Applied with minor adjustments:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=01ddef87
Thanks,
-Brad
--
Powered by
On 1/17/2012 9:54 AM, Yury G. Kudryashov wrote:
From: Yury G. Kudryashovurkud.ur...@gmail.com
install(TARGETS ...) documentation described twice what happens on non-DLL
systems.
Applied with s/sentense/sentence/ in commit message:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a64b6185
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12878
==
Reported By:Dan Kegel
Assigned To:
The current comments in
Modules/CMakeRCInformation.cmake
looks like copy/paste from another file.
# This file sets the basic flags for the Fortran language in CMake.
# It also loads the available platform file for the system-compiler
# if it exists.
How would the seek for windres be related to
On 1/17/2012 1:50 PM, Rolf Eike Beer wrote:
Commit 20980ef56a847fec7922983257fd5be467b689bd changed the FindPythonInterp
For reference:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20980ef5
Today a user was in #cmake that had a system default python that was some 3.x
version, and
On 1/17/2012 2:13 PM, Eric Noulard wrote:
The current comments in Modules/CMakeRCInformation.cmake
looks like copy/paste from another file.
# This file sets the basic flags for the Fortran language in CMake.
# It also loads the available platform file for the system-compiler
# if it exists.
Brad King wrote:
On 1/17/2012 1:50 PM, Rolf Eike Beer wrote:
Today a user was in #cmake that had a system default python that was
some 3.x version, and therefore /usr/bin/python was a symlink to
/usr/bin/python3. The current module has no possiblity for a developer
to specify that
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12879
==
Reported By:Thomas Fischer
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12880
==
Reported By:Dan Kegel
Assigned To:
Yes but I'm using MinGW make (on Windows machine), the interpreter is
GNU Make 3.82
Built for i386-pc-mingw32
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and
Hi All!
Recently we've moved all our packaging to CMake. For historical
reasons however, we need to have directory entries in our zip files.
CPack unfortunately generates archives with only file entries
included. Is possible to get desired behaviour by setting some
variables or changing some
We've got this section in our CMakeLists.txt:
#--copy pattern files to build
folder-
file( GLOB_RECURSE pattern_files RELATIVE
${CMAKE_CURRENT_SOURCE_DIR}/ patterns/*.vti )
foreach( pattern_file ${pattern_files} )
add_custom_command(
On 17.01.12 12:54:28, Tim Hutton wrote:
We've got this section in our CMakeLists.txt:
#--copy pattern files to build
folder-
file( GLOB_RECURSE pattern_files RELATIVE
${CMAKE_CURRENT_SOURCE_DIR}/ patterns/*.vti )
foreach(
Thanks Andreas, but that leaves us with having to edit the
CMakeLists.txt every time we add a pattern file. There must be a
better way?
On 17 January 2012 13:02, Andreas Pakulat ap...@gmx.de wrote:
On 17.01.12 12:54:28, Tim Hutton wrote:
We've got this section in our CMakeLists.txt:
AFAICS these files are considered to be source files, right? So they
should be explicitly listed in the CMakeLists.txt file. If your
CMakeLists.txt file gets too big, you can put the relevant code into
another file and then include() it from the CMakeLists.txt.
Doing this also helps you detecting
You could instead have a custom command that operates against a file
that contains an explicit list of the pattern files, and then just
edit that file when you add or remove a pattern. Then your custom
command would depend on that file, and it would re-run when that file
changes, and there's no
Thanks Andreas, but that leaves us with having to edit the
CMakeLists.txt every time we add a pattern file. There must be a
better way?
How should CMake find out that it needs to update it's file list then?
Citing from the FILE(GLOB) documentation:
(We do not recommend using GLOB to collect
HelloI am trying to create a multiproject containing several projects libraries with KDEvelop4 and CMakeyesterday I was helped from the mailing list to execute a single library.I don't know the exact rules to follow in order to set up a multi project library with KDEvelop and CMake: the problem
On 17 January 2012 13:21, David Cole david.c...@kitware.com wrote:
If you want to use file GLOB at CMake time, then you have to re-run
CMake manually when you add or remove a file. There's no way around
that, because we are not going to monitor your hard drive for
arbitrary file changes on a
I think cmake's find_package is only a first order approximation to
premake's usages. What usage library targets have that find_package
doesn't is the ability to cleanly inject dependency info (like include
dirs or link libraries) into any target that claims to be dependent on
the library.
I have just installed cmake 2.8.7 on ubuntu 11.10 amd64 via a build from
source. I am having exactly the same issue. When I ran make test there
were 4 failures as follows:
25:FindPackageTest
73:Simple_EclipseGenerator
74:Simple_CodeBlocksGenerator
75:Simple_KDevelop3Generator
I ran cmake . from
On 01/17/2012 03:25 PM, Tim Hutton wrote:
On 17 January 2012 13:21, David Cole david.c...@kitware.com wrote:
If you want to use file GLOB at CMake time, then you have to re-run
CMake manually when you add or remove a file. There's no way around
that, because we are not going to monitor your
2011/5/15 Eduardo Sánchez Muñoz eduardosanchezmu...@gmail.com:
I get the following error when I use a toolchain file to cross-compile with
mingw32:
$ cmake -DCMAKE_TOOLCHAIN_FILE=~/Documentos/mingw32.cmake
-DCMAKE_INSTALL_PREFIX=/usr/i486-mingw32 .
-- The C compiler identification is GNU
--
For the recommended approach of including an explicit list of pattern
files, is this the right way to do it?
...
set(PATTERN_FILES# (found in the patterns folder)
example1.vti
example2.vti
subfolder1/example3.vti
)
...
#--copy pattern files to build
On Tuesday 17 January 2012, Lance Luvaul wrote:
I think cmake's find_package is only a first order approximation to
premake's usages. What usage library targets have that find_package
doesn't is the ability to cleanly inject dependency info (like include
dirs or link libraries) into any
Thanks very much for the quick reply. I was under the seemingly mistaken
impression that the CMakeRCInformation.cmake module should automatically take
care of this. I will try your toolchain file with the suggested ammendments.
Cheers, Martin.
On Tuesday 17 January 2012 16:14:39 Eric Noulard
Is it a bug that project() does not append to the user-specified
configurations? Sure seems like one...
-
Robert Dailey
On Fri, Jan 13, 2012 at 4:52 PM, Michael Hertling mhertl...@online.dewrote:
On 01/13/2012 05:06 PM, David Cole wrote:
On Fri, Jan 13, 2012 at 10:22 AM, Michael
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 61d41e513cdc82162553680c9d4801537320e0d7 (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 133dceb1aea03c2e5647271d9c3d94dafe5c72ea (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 9f8d64614c13ebf898b1a5d45b2ea430ce528d88 (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 d9d24e2196a76dc6606d5972d382467c010c9f4e (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 4dd47eb6c394c54bde00ebd0d99a8c01c7128b9f (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 f1f66c95ad9b35e74547a9c3af1e7315eb0b738b (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 a6bc62c5acd1093b11ddd51e65b8725bf226c1a7 (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 2c9cc252cf1bc5aa9300f4635c0420385c0b34b2 (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 dafd511199906506f4a84280de6359651da9b498 (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 4cfaa91ef0ca4a85a7c39e4a9ef07eb299d5a7bf (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 05fbfd494eb3fb343e316808d390b22d8b71c7a0 (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 95dd0f279c9a239b18c8c1f5f30eb94e131cc184 (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 b2838626ddb451fbbffe0de5990d309696b28dfc (commit)
from
41 matches
Mail list logo
