2012/2/20 David Cole :
> 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" which fails sporad
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. Kudryasho
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13018
==
Reported By:Stephen Kelly
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13017
==
Reported By:Torsten Rohlfing
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13016
==
Reported By:chris.haverkate
Assigned To:
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.
# @PACKA
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 i
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 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.
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.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/open
On 3/5/2012 4:03 PM, Alexander Neundorf wrote:
Is there a chance that something like
message(VARIABLES var1 var2 ... varN)
which would print the name followed by the value of the given variables
("FOO_LIBRARY=/usr/lib/libfoo.so HAVE_BAR=1 ...")
would be also accepted ?
I need that all the time,
Stephen Kelly wrote:
> 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 :).
I updated the
On Saturday 03 March 2012, Rolf Eike Beer wrote:
> I have a small patch to CMake that looks like this:
>
> diff --git a/Source/cmMessageCommand.cxx b/Source/cmMessageCommand.cxx
> index e1dbf34..ad24368 100644
> --- a/Source/cmMessageCommand.cxx
> +++ b/Source/cmMessageCommand.cxx
> @@ -52,6 +52,1
On Monday 05 March 2012, Brad King wrote:
> 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
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 www.kitware.co
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 &&
> -
On 3/5/2012 10:33 AM, Eric Noulard wrote:
2012/3/5 Brad King:
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?
I had no particular
Brad King wrote:
> On Sun, Mar 4, 2012 at 5:18 PM, Stephen Kelly
> 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 shoul
2012/3/5 Brad King :
> 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 o
2012/3/5 Rolf Eike Beer :
>> 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
>> enume
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 warnin
> 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 cmak
On Sun, Mar 4, 2012 at 5:42 PM, Stephen Kelly wrote:
> Stephen Kelly 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, but
>> doesn't exp
Eric Noulard wrote:
> 2012/3/5 Stephen Kelly :
>> 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'
2012/3/5 Stephen Kelly :
> 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 recommen
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
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
Fo
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 bundle.
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 diff
On Sun, Mar 4, 2012 at 5:18 PM, Stephen Kelly 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 should be empty if SKIP_INSTALL
On Mar 4, 2012, at 3:29 PM, Stephen Kelly wrote:
> Stephen Kelly 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 C+
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 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/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 to WIN32_EXECUTABLE t
On Sat, Mar 3, 2012 at 8:59 AM, Yury G. Kudryashov
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
http://cmake.org/gi
35 matches
Mail list logo