On 07/21/2015 11:57 AM, Clifford Yapp wrote:
The attached patch seems to work - Brad, should I submit this to the
issue tracker? If it needs any more tweaking let me know.
No issue tracker entry needed. CONTRIBUTING.rst explains that the
mailing list is preferred. I'll take a look at this
On Mon, Jul 20, 2015 at 4:42 PM, Ben Boeckel ben.boec...@kitware.com wrote:
For testing these properties, what would you suggest? They're
intended to report local configure-time absolute paths, which can't be
hard coded... is it enough to check them to make sure they're not
empty or is there
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15658
==
Reported By:Ben Boeckel
Assigned To:
On Tue, Jul 21, 2015 at 10:03:42 -0400, Brad King wrote:
Okay. I've made a note about this issue to make sure it is fixed before 3.4.
Meanwhile I have another comment on genex support in the OUTPUT_DIRECTORY
properties. Currently the properties support both
On Mon, Jul 20, 2015 at 9:36 AM, Brad King brad.k...@kitware.com wrote:
On 07/18/2015 03:45 PM, Clifford Yapp wrote:
Am I correct that cmSystemTools::Message is the gateway through which
all of the console output from CMake exits? If so, perhaps the
simplest thing to do is simply allow
On 07/01/2015 02:17 PM, Stephen Kelly wrote:
Brad King wrote:
We need to provide such capabilities so authors that do maintain
their projects can be confident they've ported away from behavior
that will later become an error.
Makes sense to me.
I see topic end-Policy-lifetime with commit
Clifford Yapp wrote:
With David's patch and the above SOURCE_DIR property, it looks like
the necessary pieces are now present for target + source processing.
That might happen to work for brlcad, but it is not really true.
CMake looks in the source dir for relative files listed in targets,
Brad King wrote:
The lifecycle proposed in commit d5b1839a is way too aggressive. The
end-Policy-lifetime topic looks nothing like the schedule or selection
of policies discussed in the last few messages of this thread.
Yes. The discussion died after my proposal.
I've reverted the branch.
On 07/21/2015 02:50 PM, Stephen Kelly wrote:
Clifford Yapp wrote:
With David's patch and the above SOURCE_DIR property, it looks like
the necessary pieces are now present for target + source processing.
That might happen to work for brlcad, but it is not really true.
The goal here is to
Hi Brad,
I've attached a patch which learns CTest to handle it.
I hope this patch could be merged.
Best Regards
Roman
-Ursprüngliche Nachricht-
Von: Brad King [mailto:brad.k...@kitware.com]
Gesendet: Dienstag, 21. Juli 2015 15:53
An: Roman Wüger
Cc: CMake Developer MailingList;
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15657
==
Reported By:Erik Sjölund
Assigned To:
Hello,
when I run CTest from the command line with the same parameters as on the build
server, then everything is working fine.
If I run the command on the build server then I get a message which says that
the threshold of 1024 bytes are exceeded. The output are debug messages and
not
On 07/18/2015 02:03 PM, Stephen Kelly wrote:
I find the title interesting but I didn't attempt to read the email.
Please make a proposal instead of just dumping a tree of text
For reference, the text is from the issue tracker entry:
No way to exclude a component install() from a full
On 07/21/2015 04:12 AM, Roman Wüger wrote:
Is there a way to get the full output without modifying every
CMake Script of about ~ 35 projects?
CTest always truncates the output of passing tests unless the
test output contains the literal text CTEST_FULL_OUTPUT.
This was done long ago to limit
On 07/17/2015 02:34 PM, Robert Goulet wrote:
I'm going to be away for a few weeks, is it ok if the master branch
stays in that state for a while?
Okay. I've made a note about this issue to make sure it is fixed before 3.4.
Meanwhile I have another comment on genex support in the
On 07/19/2015 03:07 PM, Ralf Habacker wrote:
The check is performed with CheckFunctionExists.c, which converts the
function name into a prototype of the form 'char BZ2_bzCompressInit()',
while in real it is
int BZ2_bzCompressInit ( bz_stream *strm,
int
Am 21.07.2015 um 15:46 schrieb Brad King:
Rather than (or in addition to) changing to _BZ2_decompress, please look
at changing the check to use CheckSymbolExists. It allows the actual
header to be included so we can test using the library the way the
project will. That is likely more robust.
On 07/21/2015 10:32 AM, Ralf Habacker wrote:
Changed to use CheckSymbolExists, see append patch.
Thanks. We'll also need to set CMAKE_REQUIRED_INCLUDES to ensure
the correct bzlib.h header can be found when it is not in a system
default location.
Thanks,
-Brad
--
Powered by www.kitware.com
18 matches
Mail list logo
