Not to be picky, but the issue of case sensitivity ignores the original
question.
If it helps someone think about the issue better, change:
set(FOO_HEADER_FILES foo.h;bar.h;bat.h;Foo.h;Foo.hpp)
to
set(FOO_HEADER_FILES bar.h;bat.h;Foo.h;Foo.hpp)
Thanks,
Steve
On Tue, Jul 21, 2015 at 10:59
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 07/20/2015 03:45 PM, Berteun Damman wrote:
Note that it displays the full path for foo.txt! With later CMake
versions (3.1 and up is my suspicion), it will display:
build$ cmake ..
foo.cc
foo.txt
I tried looking trough the release notes, and I've found that
add_library gained support
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
to be very precise,
OS X is a Case Preserving but NOT Case sensitive be default. OS X can be
made to be case sensitive but no one actually recommends it.
this means that on OS X foo.h and Foo.h resolve to be the same file, where as
on Linux they would be 2 different files. You would have
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 265b9db7c2c865c5aad821bf9a377ea84dfe431e (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 380b8455c61c66bbd610c01aa4761e05700f888e (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, release has been updated
via 0e3cfc134cee5b560a636d72231cfcaeac376b85 (commit)
from
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15658
==
Reported By:Ben Boeckel
Assigned To:
20150721)
+set(CMake_VERSION_PATCH 20150722)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
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
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 462f182d25bad09362888cbd85ced31d7cf78680 (commit)
via
Are you saying the file does not exist in the installed framework, or
that you do not see copying Foo.h in the install output ...? This
seems very unlikely. The header files are supposed to be in the
framework in the build tree, and the built framework in its entirety
is supposed to be recursively
On 07/20/2015 05:10 PM, Allen Byrne wrote:
We use the OBJECT_DEPENDS property as follows;
Environment: Windows 7, Visual Studio 2012, Intel Fortran 15, and CMake 3.1
It looks like OBJECT_DEPENDS is not fully implemented for VS = 10.
I'll look at fixing that.
Meanwhile you can work around the
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 fb393252d7bd48943b13c1824d32bb2d753a902d (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 ccc30aa9cbbb69e6ff0c4baac99b3cfdc7ce19d5 (commit)
via
On 07/20/2015 12:52 AM, Eric Wing wrote:
I would like to dynamically construct a macro or function name to
invoke. I basically have a core CMake system I want users to be able
to extend/plug stuff into without knowing about a lot of the core
CMake implementation. Callback functions would be an
Well the definitely removes the case sensitivity issue. Do you have a compact
example that shows the failure? I took a look in our project and we don't have
any cases like this. I would find it a very odd and subtle bug it this really
were an issue. one of those edge cases that just did not get
A user was confused just now by cmake continuing to output lots and
lots of stuff after
an error. How can we convince cmake to stop immediately upon first error?
The error in this case was
CMake Error at CMakeLists.txt:690 (add_executable):
add_executable cannot create target ImageClotTest
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 f5350a90875848979d56e6843b2e61c5a6b2a725 (commit)
via
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
On 07/18/2015 08:17 AM, Alexandre GOUAILLARD wrote:
dear all,
I'm trying to use cmake as a super build script for another library
build system.
Using add_custom_command and add_custom_target I have managed to
handle most of the steps so far. My libraries and executable are being
built as
I am saying the file does not exist in the either installed framework or in
the framework in the build directory. CMake is not moving the header
files that start with a capital letter into the framework headers
directory. Now I did double check and it *is* moving the .hpp header that
matches
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 efdeee5959385baa82287700b7f57200229a7fc6 (commit)
via
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,
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 5be9e8f54c5a407356af587b28a6a82de527cdda (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 ce401b860457dd1aaab3af16150f1cb8aa2c2c72 (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 ff766a5d58f109450c11ac63a686f8129e33c614 (commit)
via
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.
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 33a9e4b2211a74b3034c80d37b3e5eadecb8da45 (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 ddf60dae50a503c1fd7ea460dc13921e470cdc44 (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 f074efbf369210d7b61ec58ef48f3471b585fd95 (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 0ed780ea8d4036eb90ee39566deaaf0ac22e (commit)
via
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
On 07/21/2015 01:06 PM, Brad King wrote:
It looks like OBJECT_DEPENDS is not fully implemented for VS = 10.
I'll look at fixing that.
It turns out that is because .vcxproj files do not support it.
The ClCompile task is documented here:
https://msdn.microsoft.com/en-us/library/ee862477.aspx
Try putting ${FOO_HEADER_FILES} in the add_library call, too.
I reproduced this by adding a file, with **ANY** name, to the
PUBLIC_HEADER list of the
[CMake/Tests/Framework/CMakeLists.txt](https://github.com/Kitware/CMake/blob/master/Tests/Framework/CMakeLists.txt)
file... but NOT adding it to
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 9cd2ff9b8f18396b9750002a6ab4e5a1050bff60 (commit)
via
Thanks David,
That change appears to have corrected the issue.
Steve
On Tue, Jul 21, 2015 at 4:30 PM, David Cole dlrd...@aol.com wrote:
Try putting ${FOO_HEADER_FILES} in the add_library call, too.
I reproduced this by adding a file, with **ANY** name, to the
PUBLIC_HEADER list of the
Initial test seems to work, Will wait for the Nightly tests to verify that
using custom target works.
Allen
On Tuesday, July 21, 2015 04:17:39 PM Brad King wrote:
On 07/21/2015 01:06 PM, Brad King wrote:
It looks like OBJECT_DEPENDS is not fully implemented for VS = 10.
I'll look at fixing
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;
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;
I've noticed that CMake 3.3.0-rc3 will not install a header file in a Mac
OS X framework if the header file starts with a capital letter (either that
or has the same name as the framework).
For example if I have the following:
set(FOO_HEADER_FILES foo.h;bar.h;bat.h;Foo.h;Foo.hpp)
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
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
Just to follow up my own question. I have found the answer
export Foo_DIR=/my/path/prefix
followed by cmake ... will correctly locate the package
unfortunately,
cmake -DFoo_DIR=/my/path/prefix rest of options
will not.
Is there a reason why the cmake variable is not searched, whereas the env var
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/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
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 6a8c31b7d4352543208efcce12b7a0e966a29b21 (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 f7c7c4ab64039a1b06e775813b9392f7a300acf6 (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 863175742bcf92fa589a92fbae319524e5460771 (commit)
via
On Fri, Jul 17, 2015 at 11:25 AM, Robert Dailey
rcdailey.li...@gmail.com wrote:
Hello,
How would I define a toolchain file for the Visual Studio 2013
generator that also defines the toolset for that generator to be the
November CTP compiler?
I'd rather use a toolchain for this than do -D
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
I've asked this before, but never resolved it...
if I stall package Foo into
CMAKE_INSTALL_PREFIX=/my/path/prefix
and generate
/my/path/prefix/lib/cmake/Foo/FooConfig.cmake
etc
then with
Foo_DIR=/my/path/prefix
Foo_ROOT=/my/path/prefix
find_package(Foo)
does not find package Foo
One needs to
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 ce597a022b32231559c75843f4df6108120c5d57 (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 64aa41b2480384be22881a3bacc8960ec57b0f11 (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 b953d526d10d41b631b82f576eac12d9cdfee6b7 (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 ae64efa1ce9097f27c1dbfb2b6a14ccf512e16b7 (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 e13c18974307ecd0f11e2ecfde64f1aea80c6304 (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 93b393e74c3a7508fe013b423809e7e35f9bc8a0 (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 5b2754d41fcef287ff76c9d909d9bc2f506b4d03 (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 500ce3f11338a7bafeba0e9e623fd04b3802e5d9 (commit)
via
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.
Have you tried setting CMAKE_PREFIX_PATH
(http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_PREFIX_PATH.html)
as a -D option on the initial configure?
On Tue, Jul 21, 2015 at 9:43 AM, Biddiscombe, John A. biddi...@cscs.ch wrote:
Just to follow up my own question. I have found the answer
It can't installiert both foo.h and Foo.h in the mac, better correct your
example.
Am 21.07.2015 5:19 vorm. schrieb Steven Wilson
steven.wesley.wil...@gmail.com:
I've noticed that CMake 3.3.0-rc3 will not install a header file in a Mac
OS X framework if the header file starts with a capital
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
69 matches
Mail list logo
