_VERSION_MINOR 6)
-set(CMake_VERSION_PATCH 20160830)
+set(CMake_VERSION_PATCH 20160831)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/
On poniedziałek, 29 sierpnia 2016 23:44:30 CEST you wrote:
> On poniedziałek, 29 sierpnia 2016 23:31:59 CEST you wrote:
> > add_custom_command documentation says:
> >
> >
> > The DEPENDS option specifies files on which the command depends. If any
> > dependency is an OUTPUT of another custom
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 f7e7afe9d54fac4527c70e0b8a9c463aae3cc4de (commit)
via
On 08/29/2016 04:57 PM, Alexis Murzeau wrote:
> Since OpenSSL 1.1.0, Windows binaries are libcrypto and libssl instead of
> the old names libeay32 and ssleay32.
Thanks, applied:
FindOpenSSL: Fix detection of OpenSSL 1.1 Win32/64
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed1758f8
On 08/28/2016 01:51 PM, Roger Leigh wrote:
> The macro name might need adjusting
The idea looks fine to me. Typically we name module-provided APIs with
the module name. How about "GNUInstallDirs_get_absolute_install_dir"?
I'm also open to other suggestions.
Thanks,
-Brad
--
Powered by
On 08/30/2016 03:58 AM, Yves Frederix wrote:
> Some time ago, I contributed generator expressions to
> install(DIRECTORY). It turns out, however, that the patch was
> incomplete and that there are problems in case the provided directory
> starts with a generator expression and evaluates to a full
On 08/28/2016 10:00 AM, Sebastian Holtermann wrote:
> Base32 is a better choice IMO because it is single case and does not
> generate disruptive characters like '_', '-' or '/'.
>
> Here are two patches that replace Base64 with Base32.
Thanks. Please revise the Base32 infrastructure to simply
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 9c041eab42520c99c753b9e5be3c52943a834e21 (commit)
via
Karl,
good question. The docs say that you supply OPTIONS to cuda_add_library,
which are in turn handed over to cuda_wrap_srcs. the only chance I see
is digging there. internally, both cuda_add_xxx create regular cmake
targets.
I am not sure why cmake doesn't accept subsequent
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 94b028b48a1d7f1fe753bd4e626f24d4240c7436 (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 fdeb50d6b51a8e189ebdb4da88b464cd981e0ad4 (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 98c49311ea16241edfb240eced28628677cc18cb (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 ef58e97362d10877780aed7b6806dd02ce2f4303 (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 388a40942bbe87206547bd9eb27273f80ef2aa9f (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 e3a4c2e02ceacd302e8bc6a7dc1bc02b29ab2cfc (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 918cb5b1f095cc05a8823fa218a59edf0e536384 (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 40b8e22e55c20d2ecf31fe51ebc22453ec28996f (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 50eca8d02d62159621925b248b6525df2e974892 (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 39c455a26827178bf2b2cc585dc59fad3329b5ee (commit)
via
Peter,
I use CMake 3.5.1 and 3.0.2, and this works the same with both.
Thanks for your suggestions. It does indeed work if I define them
explicitly like that, but the reason why I want to use something like
COMPILE_DEFINITIONS is that we have a large library that has several
targets with
Hi,
Some time ago, I contributed generator expressions to
install(DIRECTORY). It turns out, however, that the patch was
incomplete and that there are problems in case the provided directory
starts with a generator expression and evaluates to a full path. In
attachment you can find a fix for the
21 matches
Mail list logo
