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
27 matches
Mail list logo
