On Sat, Mar 3, 2012 at 8:59 AM, Yury G. Kudryashov urkud.ur...@gmail.com
wrote:
git://gitorious.org/~urkud1/cmake/urkud-cmake.git, please:
* rename-used-commands;
* remove-unused-members.
Good cleanups. Applied:
https://gitorious.org/~urkud1/cmake/urkud-cmake/commits/remove-unused-members
On 3/4/2012 5:44 PM, Stephen Kelly wrote:
Nice. This is exactly the kind of interface I had in mind for the
usage requirements approach Alex and I were discussing elsewhere
in this thread. We will have to think about how to define transitive
properties of these requirements though.
Is this
On 3/3/2012 5:25 AM, Rolf Eike Beer wrote:
+ else if (*i == DEBUG)
+{
...
+status = true;
Rather than being a conditional version of STATUS I think full stack
information is useful for debugging. Add to the cmake::MessageType
enumeration a DEBUG value and teach cmake::IssueMessage
On Mar 4, 2012, at 3:29 PM, Stephen Kelly wrote:
Stephen Kelly steveire@... writes:
Brad King wrote:
The implementation is not what I had in mind when I said implies
the platform-specific property. This should be its own property
that one can set/get normally with no special
Brad King wrote:
On 3/4/2012 5:29 PM, Stephen Kelly wrote:
I happened to read a little bit about CPack recently
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview
The recommendation is to not use MACOSX_BUNDLE when using cpack, so I
thought maybe that makes it different enough
On 3/5/2012 9:42 AM, Stephen Kelly wrote:
Ok. I have pushed win32_executable-and-macosx_bundle-initializers to stage.
Thanks.
Can I go ahead and merge that to next?
Almost. This hunk misses spaces after the period:
- about creation of the Info.plist file for the application
Brad King wrote:
Fix that and then merge.
Done, thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Clinton Stimpson wrote:
I happened to read a little bit about CPack recently
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview
The recommendation is to not use MACOSX_BUNDLE when using cpack,
I don't see that as a general recommendation for GUI applications on Mac
OS X.
2012/3/5 Stephen Kelly steve...@gmail.com:
Clinton Stimpson wrote:
I happened to read a little bit about CPack recently
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview
The recommendation is to not use MACOSX_BUNDLE when using cpack,
I don't see that as a general
Eric Noulard wrote:
2012/3/5 Stephen Kelly steve...@gmail.com:
Clinton Stimpson wrote:
I happened to read a little bit about CPack recently
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview
The recommendation is to not use MACOSX_BUNDLE when using cpack,
I don't see that
On Sun, Mar 4, 2012 at 5:42 PM, Stephen Kelly steve...@gmail.com wrote:
Stephen Kelly steveire@... writes:
Any idea what would cause that? It must be one of these:
http://open.cdash.org/viewUpdate.php?buildid=2016288
Note that the GenerateExportHeader_MinorFix makes the problem go away,
On 3/3/2012 5:25 AM, Rolf Eike Beer wrote:
+ else if (*i == DEBUG)
+{
...
+status = true;
Rather than being a conditional version of STATUS I think full stack
information is useful for debugging. Add to the cmake::MessageType
enumeration a DEBUG value and teach
On 3/5/2012 10:22 AM, Rolf Eike Beer wrote:
Rather than being a conditional version of STATUS I think full stack
information is useful for debugging. Add to the cmake::MessageType
enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
The output should look like an error or
2012/3/5 Rolf Eike Beer e...@sf-mail.de:
On 3/3/2012 5:25 AM, Rolf Eike Beer wrote:
+ else if (*i == DEBUG)
+ {
...
+ status = true;
Rather than being a conditional version of STATUS I think full stack
information is useful for debugging. Add to the cmake::MessageType
enumeration
2012/3/5 Brad King brad.k...@kitware.com:
On 3/5/2012 10:22 AM, Rolf Eike Beer wrote:
Rather than being a conditional version of STATUS I think full stack
information is useful for debugging. Add to the cmake::MessageType
enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
Brad King wrote:
On Sun, Mar 4, 2012 at 5:18 PM, Stephen Kelly
steve...@gmail.com wrote:
That's a good start. However I do not think the logic plays well
with BUILD_WITH_INSTALL_RPATH as currently written. If that is
set then the build tree should end up with the install-tree rpath
which
On 3/5/2012 10:33 AM, Eric Noulard wrote:
2012/3/5 Brad Kingbrad.k...@kitware.com:
Elsewhere in this thread discussion proposed filters on messages
based on their context. Filters based on the full backtrace
should be possible and would give a lot of control.
You mean something like a regex?
On 3/5/2012 10:47 AM, Stephen Kelly wrote:
e1b4fec8dd73cc675b3a20f2e045c6282c47553a in my gitorious clone contains the
updated state. It behaved as I expected in all combinations I tested.
Much cleaner, thanks. Here are some more comments.
outputRuntime linking_for_install
-
Brad King wrote:
Much cleaner, thanks. Here are some more comments.
Thanks, I'll try to clean up the remaining messiness later when I can give
it my full attention. With the remaining goobers, clearly I'm not giving it
enough at the moment :).
Thanks,
Steve.
--
Powered by
On Monday 05 March 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
The question whether the standard-conforming name is FOO_INCLUDE_DIRS or
Foo_INCLUDE_DIRS, i.e. ExactCase or UPPERCASE, is not decided.
readme.txt is ambiguous in this point, since it uses as example
FindXXX.cmake,
Brad King wrote:
On 3/5/2012 4:26 PM, Stephen Kelly wrote:
I updated the branch again. It is now
635bf50c27aef184bfa1698953dd44361e1fb2f9
Great, thanks. Please merge to 'next' for testing.
Done. Thanks for the review.
Steve.
--
Powered by www.kitware.com
Visit other Kitware
On Friday 02 March 2012, David Cole wrote:
Alex,
Brad and I reviewed the MakingConfigFilesEasier_ConfigureMacro topic,
but have two small additional changes to request before we merge it to
master.
(1) There's a generated comment referencing
ConfigureConfigFile.cmake but there is no such
On 3/5/2012 5:04 PM, Alexander Neundorf wrote:
So instead of:
# @PACKAGE_HELPER_INIT@
# ...
# set_and_check(FOO_INCLUDE_DIR @PACKAGE_HELPER_INCLUDE_INSTALL_DIR@)
# set_and_check(FOO_SYSCONFIG_DIR @PACKAGE_HELPER_SYSCONFIG_INSTALL_DIR@)
you prefer the following ?
Yes.
#
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13016
==
Reported By:chris.haverkate
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13017
==
Reported By:Torsten Rohlfing
Assigned To:
Hi!
I've just found that there are two doxygen configs in cmake source tree:
* cmake/doxygen.config
* cmake/Utilities/Doxygen/* VTK magic
The second one can be enabled by BUILD_DOCUMENTATION but doc_makeall.sh
references some VTK_* variables.
Which one should I use/fix/..?
--
Yury G.
2012/2/20 David Cole david.c...@kitware.com:
The lesson here is:
- ignore dashboard failures for the BundleGenerator test on Mac machines
unless it is happening consistently build after build after build
- also ignore any test failures that contain references to a failed run of
hdiutil
how do in cmake to get visual studio 2008 project file have structure with
some folders below:
project
+ Form Files
+ Generate Files
+ Resource Files
+ Header Files
+ Source Files
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On Saturday 03 March 2012, 02:29:05, Robert Dailey wrote:
Well you're really comparing apples to oranges. C++ nested scoping rules
really have nothing to do with two separate functions sharing scoped
variables. It doesn't even really serve as a good analogy, so I can't be
100% certain what you
Hello,
for whatever it is worth, C-style preprocessor commands
are a non-standard feature. The Fortran standard itself
defines only the INCLUDE statement (or directive).
Perhaps you can solve this in a standard way by moving the
logic to the CMakeLists.txt files rather than relying
on (possibly
Hello,
I am trying to cross-compile a project containing C, C++ and Fortran
source files with mingw64 on a Debian host (Linux) with CMake 2.8.7:
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project ( FOO CXX C Fortran )
include ( FortranCInterface )
FortranCInterface_HEADER
This is for menu items in the Windows Start menu. Is that what you mean?
See the file CMakeCPackOptions.cmake.in in CMake's own source tree
that has code in it like this:
if(CPACK_GENERATOR MATCHES NSIS)
...
SET(CPACK_NSIS_MENU_LINKS
# ... pairs of (filenames or urls, text for menu
On Mon, Mar 5, 2012 at 3:40 AM, Quân Phạm Minh quanpm4...@gmail.com wrote:
how do in cmake to get visual studio 2008 project file have structure with
some folders below:
project
+ Form Files
+ Generate Files
+ Resource Files
+ Header Files
+ Source Files
I'm having the following behaviour, and I can't quite understand the
error message:
..
Built target psi.utility_install
..
make[3]: *** No rule to make target `psi.utility_install', needed by
`CMakeFiles/install_all_eggs'. Stop.
make[2]: *** [CMakeFiles/install_all_eggs.dir/all] Error 2
I'm assuming MSVC_VERSION will be 1700 for MSVC11. Is this correct?
-
Robert Dailey
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
Correct. Partial output from 'git grep MSVC_VERSION' in the CMake source tree:
$ git grep MSVC_VERSION
...
Modules/CMakeVS10FindMake.cmake:SET(MSVC_VERSION 1600)
Modules/CMakeVS11FindMake.cmake:SET(MSVC_VERSION 1700)
Modules/CMakeVS6FindMake.cmake:SET(MSVC_VERSION 1200)
if(${GrammarSource}/test.g IS_NEWER_THAN ${PROJECT_BINARY_DIR}/test.g)
ADD_CUSTOM_TARGET(...)
ADD_CUSTOM_COMMAND(...)
i.e I am totally avoiding the process of rebuilding the test.g file and
copying the generated files to build/parser
*IF* test.g has not been modified.
...and if
2012/3/5 Robert Dailey rcdai...@gmail.com:
The docs aren't updated to reflect this so I just wanted to make sure.
Patch for documentation may be accepted as well :-]
I didn't have time to run through the source code (you Linux people and your
fancy 'git grep' commands :P )
You Windows people
On 05.03.12 14:14:13, Robert Dailey wrote:
The docs aren't updated to reflect this so I just wanted to make sure. I
didn't have time to run through the source code (you Linux people and your
fancy 'git grep' commands :P )
You know git including git grep also works on windows (and no I'm not
On Sun, 4 Mar 2012 22:15:52 +0100
Andreas Pakulat ap...@gmx.de wrote:
No, for those three at least you also don't need link_directories. The
find-modules for all 3 provide the absolute paths to the libraries in
CMake variables which you can use with target_link_libraries directly
and it'll just
I have test and package configurations on my project, I want:
cmake .
make package
to run force injection of the test target prior to building the
package target.
Can it be done? How? :)
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Hello All,
I am trying to attach a custom POST_BUILD command to the ALL_BUILD target.
I've tried adding the following at the bottom of my root CMakeLists.txt
file but the Post Event never shows up in Visual Studio. I have been able
to get it to work for sub projects, just not ALL_BUILD. Has
Hello,
Is there anyway that cmake could figure out the shell (bash,csh,..)
that is being use when cmake is invoked on the command line ?
Thanks
Ajay
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep
On 03/04/2012 11:01 AM, Andreas Guther wrote:
Hello,
thanks for the responses. The problem I have is, that we have more than one
application in the directory. So if I put an CMakeLists.txt in the Src
directory I do not have the choice (only by options). I would prefer a
solution where I
2012/3/6 Ajay Panyala a...@csc.lsu.edu:
Hello,
Is there anyway that cmake could figure out the shell (bash,csh,..)
that is being use when cmake is invoked on the command line ?
May be you can check $ENV{SHELL} ?
Why would you like to do that?
Usually when using CMake one tries to avoid
On 03/05/2012 10:43 AM, Johannes Zarl wrote:
On Saturday 03 March 2012, 02:29:05, Robert Dailey wrote:
Well you're really comparing apples to oranges. C++ nested scoping rules
really have nothing to do with two separate functions sharing scoped
variables. It doesn't even really serve as a good
On 03/05/2012 05:59 PM, Andrea Crotti wrote:
I'm having the following behaviour, and I can't quite understand the
error message:
..
Built target psi.utility_install
..
make[3]: *** No rule to make target `psi.utility_install', needed by
`CMakeFiles/install_all_eggs'. Stop.
make[2]:
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 234216ad5221518f03b830d351eb6e3733964487 (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 1ff8087e897324513bf370b3ce96d67432245dab (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 027084f60efced153ac088acf69ab0e1ff68aba5 (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 7f1b86d666b0d18dae8ea3196e821e57bffdaef7 (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 ec50093be768c9fa9384cc42a4d1f331f0264b39 (commit)
from
52 matches
Mail list logo
