On 08/21/2015 09:50 AM, Brad King wrote:
UseJava: Add support for javah tool
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4476feac
There is still one failure on the dashboard but I think it is
related to the way the run is configured rather than a problem
with the source. Once I've
On 08/18/2015 02:57 AM, CHEVRIER, Marc wrote:
Unfortunately I don't have access to an HP-UX system.
For reference, we worked out the problem off-list with someone
that has access to HP-UX. The fix is:
HP-UX: Do not use .sl extension for shared libs on Itanium
Thank you.
Unfortunately I don’t have access to an HP-UX system.
From what I remember, HP-UX expect shared libraries with same name pattern as
Linux except that extension is .sl rather than .so.
Marc
On 14/08/15 15:45, Brad King brad.k...@kitware.com wrote:
On 08/07/2015 04:04 AM,
On 08/07/2015 04:04 AM, CHEVRIER, Marc wrote:
New version of patch attached.
Thanks. Applied with a few tweaks:
UseJava: Add support for javah tool
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cae7bef9
However, it fails on some HP-UX machines because Java does not know
how to load the
Hi,
New version of patch attached.
I added a check on java tool to execute test only if java and shared library
built by test have same architecture (32 or 64bit).
Marc
On 05/08/15 17:49, Brad King brad.k...@kitware.com wrote:
On 08/05/2015 03:15 AM, CHEVRIER, Marc wrote:
For point 2.,
Hi,
For point 1. I completely forgot to test with VS generators… I will work on
that ASAP.
For point 2., The best approach is to install 32 and 64bit versions of Java SDK
(Windows versions, not some cygwin or MSYS versions) and ensure JAVA_HOME is
NOT set in the environment nor referenced in
Hi,
Again, a new version for patch 4. I hope I didn’t miss anything this time. :)
To handle VS generators, I am relying on generator-expressions supported by
add_test function.
Marc
On 04/08/15 17:42, Brad King brad.k...@kitware.com wrote:
On 08/04/2015 04:45 AM, CHEVRIER, Marc wrote:
On 08/05/2015 03:15 AM, CHEVRIER, Marc wrote:
For point 2., The best approach is to install 32 and 64bit
versions of Java SDK (Windows versions, not some cygwin or
MSYS versions) and ensure JAVA_HOME is NOT set in the
environment nor referenced in the PATH. In this case, CMake
FindJava.cmake
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
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
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 for idlj and jarsigner tools
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e499264
UseJava: Teach add_jar
OK.
New version of patches. There is now a component per extra tool (for now IdlJ
and JarSigner as suggested by Brad) to ensure future extensibility.
Marc
On 30/07/15 16:49, Brad King brad.k...@kitware.com wrote:
On 07/30/2015 09:55 AM, CHEVRIER, Marc wrote:
here is the correct version.
I just detected a small error introduced in patch 0001, here is the correct
version.
Sorry for the noise...
On 30/07/15 11:32, cmake-developers on behalf of CHEVRIER, Marc
cmake-developers-boun...@cmake.org on behalf of marc.chevr...@sap.com wrote:
New version of patches taking into
On 07/30/2015 09:55 AM, CHEVRIER, Marc wrote:
here is the correct version.
Thanks. The component name Extra sounds too generic and we won't
be able to extend it in the future with other extra parts for the
same reason these tools could not be made part of Development.
Perhaps instead we should
New version of patches taking into account Brad’ remarks.
Marc
On 29/07/15 15:47, Brad King brad.k...@kitware.com wrote:
On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote:
here is an updated list of patches.
Great.
find_package_handle_standard_args(Java
REQUIRED_VARS
Hi,
You are right. @ must be matching at the beginning of the item. But I need .*
in the expression because I use regex matching group to retrieve filename.
Anyway, here is an updated list of patches.
Marc
On 29/07/15 09:25, cmake-developers on behalf of Rolf Eike Beer
Am Dienstag, 28. Juli 2015, 08:15:01 schrieb CHEVRIER, Marc:
Hi,
0002 (UseJava.cmake): Extends add_jar command to support @file syntax for
java sources specification.
You do not need leading or trailing .* in regular expressions. In fact I think
your expression should simply be ^@,
On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote:
here is an updated list of patches.
Great.
find_package_handle_standard_args(Java
REQUIRED_VARS Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE
Java_JAVAC_EXECUTABLE
Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE
+
Thanks for your comments.
To address your first remark, I propose to introduce a new component (‘Extra',
for example) to manage these new tools.
For example: find_package (Java COMPONENTS Development Extra)
I think it is better than removing new variables as required because this
approach will
Hi,
Here are some patches to enhance Java support.
0001 (FindJava.cmake): Defines now two new variables for idlj and jar signer
tools: Java_IDLJ_EXECUTABLE and Java_JARSIGNER_EXECUTABLE
0002 (UseJava.cmake): Extends add_jar command to support @file syntax for java
sources specification.
0003
21 matches
Mail list logo
