Thanks.
I will have a look for the patch 4.
Marc
On 03/08/15 22:17, Brad King brad.k...@kitware.com wrote:
On 07/31/2015 04:08 AM, CHEVRIER, Marc wrote:
New version of patches.
Thanks.
I applied the first three with minor tweaks and merged to 'next'
for testing:
FindJava: Add support
Hi, Brad!
03.08.2015, 23:26, Brad King brad.k...@kitware.com:
On 08/02/2015 03:31 PM, Konstantin Podsvirov wrote:
https://github.com/google/protobuf/pull/673
[snip]
I try to make find_package(Protobuf [MODULE|CONFIG]) compatible.
Thanks for working on this. Thanks for the FindProtobuf
Attached is a new version of patch 4 tested successfully on Linux (SuSE 11.3),
Windows (7 64bit) and MacOS (10.10.4)
Marc
On 03/08/15 22:17, Brad King brad.k...@kitware.com wrote:
On 07/31/2015 04:08 AM, CHEVRIER, Marc wrote:
New version of patches.
Thanks.
I applied the first three with
On 08/04/2015 04:45 AM, CHEVRIER, Marc wrote:
Attached is a new version of patch 4 tested successfully
on Linux (SuSE 11.3), Windows (7 64bit) and MacOS (10.10.4)
Thanks. This still fails for me on Windows with a VS generator
for two reasons:
1. The java.library.path setting points at the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Great, yes it works.
Thanks,
Justin
On 08/03/2015 03:18 PM, Brad King wrote:
On 08/02/2015 01:35 PM, Justin Borodinsky wrote:
I received a segfault during generation with the attached
list-file. Attached is a patch to master which avoids the null
On 04.08.2015 23:15, Dan Liew wrote:
foolib is defined in this CMakeLists.txt:
https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt
That is the (only) context in which you can extend the definition of the
target with custom commands.
Since when?
As far as
On 04.08.2015 22:46, Dan Liew wrote:
The target name foolib is unknown in this context.
This warning is for project developers. Use -Wno-dev to suppress it
```
This doesn't make sense the target **clearly exists and is in scope**
because the ``simple_test`` executable links against it and
foolib is defined in this CMakeLists.txt:
https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt
That is the (only) context in which you can extend the definition of the
target with custom commands.
Since when? I haven't seen that documented anywhere. IMHO
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15681
==
Reported By:Dan Liew
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15679
==
Reported By:Chris
Assigned To:
Hi,
I'm almost certain this is a bug but I thought I'd ask the mailing lists first.
I'm observing a problem with CMake's add_custom_command() when using
the TARGET version of the signature.
Code demonstrating the issue can be found at [1]
In ``test/CMakeLists.txt`` [2] I try using
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15680
==
Reported By:Anton Makeev
Assigned To:
I haven't seen that documented anywhere. IMHO this
behavior is counter-intuitive, in general I expect the scope of a
target to not depend on the cmake command I am trying to use.
I think it is sensible that the definition of a target is scoped to one
single directory.
Where the
Hi,
Multiple patches attached that improve testing of the get_filename_component
command and also fix a bug where get_filename_component ignores CACHE when
PROGRAM_ARGS is also provided.
Best regards,
James Johnston
0001-get_filename_component-Tests-now-check-for-proper-CA.patch
Description:
For reference I've opened up a bug report
http://www.cmake.org/Bug/view.php?id=15681
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
15 matches
Mail list logo
