Builds breaking for Mac about jocl HOT 27 CLOSED

I added c++11 support flags to Xcode and now simpler errors have gone.
I am now getting :

Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.hpp:63:9: error: use of undeclared identifier 'ThrowByName'
        ThrowByName(env, "java/lang/OutOfMemoryError",

and

/Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:312:23: error: no member named 'x' in 'cl_float2'
        values_native.x = (cl_float)localValues[0];

Can you give some reference to how to solve them ?

from jocl.

Finally i managed to generate the jar and dylib. That required some changes in XCode project settings as well. To port them to CMake, i would require some help. I have not worked on CMake before.
Changes are :

JOCL Project chagnes :

1. In xcode :
   Build Settings : Search Paths : Header Search Paths :
   Add "/System/Library/Frameworks/OpenGL.framework/Headers"
   I found that their is flag JNI_INCLUDE_DIRS. Can this be used for it ?
   Would setting this flag during configuration/generation would be right. This would add a step in Readme?

• I found that currently their is "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/JavaVM.framework/Headers" also added to Header-Paths.
  Is that the wrong detected "JNI_INCLUDE_DIRS" ?

  ** We can also add compiler flag "-framework OpenCl".
  However, it does not seem to work for me.

JOCL and JOCLCommon:

1. In Xcode : C++ Language Dialect :

   C++11 => -std=c++11
   C++ standard library => libc++
   How is c++11 is used in windows ?
   I could not find any reference in CMakefiles.

Apart from the project changes, their are some code changes as well.

from jocl.

Thanks for investigating this. Until now, I did not receive similar hints from the contributors of the MacOS binaries, so I'm a bit surprised to see that it seems to be such a hassle to compile it.

But the nullptr might indeed be new. Until now, I usually used NULL, but with C++11, I think that nullptr should be used. According to https://cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD.html , it should be possible to add the required flag in CMake.It would be great if you could confirm that adding

set_property(TARGET JOCLCommon PROPERTY CXX_STANDARD 11)

and

set_property(TARGET JOCL_${JOCL_VERSION}-${JOCL_HOST}-${JOCL_ARCH} PROPERTY CXX_STANDARD 11)

to the JOCLCommon and JOCL makefiles, respectively, resolves this. (I'll have to increase the required CMake version to 3.1 then, but that should be fine)

Regarding the GL headers: I'll have to investigate this a bit further (and am currently wondering why this is not required on other platforms - I'll have to check whether the GL includes come from on Windows, I obviously overlooked something here...)

However, adding

find_package(OpenGL REQUIRED)
link_directories(${OpenGL_LIBRARY_DIRS})
include_directories(${OpenGL_INCLUDE_DIR})

should also solve this, correct?

(The JNI_INCLUDE_DIRS do only refer to JNI itself, and it looks like they are found correctly. The OpenGL include should be covered with the OpenGL_INCLUDE_DIR, which should be found as described above.)

Did the code changes that you mentioned refer to an

#include <OpenGL/gl.h>

that may be missing at https://github.com/gpu/JOCLCommon/blob/master/src/main/native/JOCLCommon.hpp#L42 ?

What I did not yet understand was your comment regarding the compiler flag -framework OpenCl - or was this just an attempt to find the OpenGL headers? (They should be fairly unrelated, though...)

from jocl.

Yay.. the CMake changes you mentioned fixed all the problems.

1. About -framework OpenCL : I was googling around and found we can pass this to clang to tell it to include opencl lib and headers automatically. We can ignore this. It is not needed now.
2. About project changes :
   a) Yes Gl.h is missing.
   b) Undefined macros :

    CL_API_SUFFIX__VERSION_2_0         
     CL_EXT_PREFIX__VERSION_2_0_DEPRECATED
    CL_EXT_SUFFIX__VERSION_2_0_DEPRECATED
    CL_EXT_SUFFIX__VERSION_2_0 

c) Some missing headers in ConversionsCL.hpp
d) Important :
Error :
/Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:312:23: error: no member named 'x' in 'cl_float2' values_native.x = (cl_float)localValues[0];
https://github.com/gpu/JOCLCommon/blob/master/src/main/native/ConversionsCL.cpp#L312

cl_float2 is defined as https://github.com/gpu/JOCLCommon/blob/master/src/main/include/CL/cl_platform.h#L1120

because of https://github.com/gpu/JOCLCommon/blob/master/src/main/include/CL/cl_platform.h#L489 CL_HAS_ANON_STRUCT being 0

I temporarily set it as 1 and it build. What is your suggestion for this ?

Should we consider writing some abstraction for setting x and y ?

from jocl.

Please ignore my comment d) about __CL_HAS_ANON_STRUCT__.
This error went away after the CMakefile changes.

from jocl.

I have raised pull requests in JOCL and JOCLCommon for that builds the project.

from jocl.

Thanks for the pull requests. I have tested them, and would pull them with minor corrections tomorrow.

EDIT: For reference
gpu/JOCLCommon#1
#2

from jocl.

I just pulled the fixes that you provided, and also updated the CL header files with the latest 2.0 headers from Khronos. Interestingly, the cl_platform.h was unmodified, but others now include the cl_platform.h on Apple. However, this should not affect this issue, so I think it can be closed now.

So thanks again for your contribution!

from jocl.

Would you need the mac binaries with latest changes ?

from jocl.

Sure, the Mac binaries of the last version are not yet available in the current download or Maven Central. If you could provide them, that would be great.

from jocl.

I would be able to give by this weekend.

from jocl.

Unfortunately.. because of header upgrades.. the build is now failing..
Like : undefined cl_queue_properties

As we are now including opencl/cl.h instead of cl.h , these types are not defined in opencl/cl.h..

Errors :

In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:33:
/Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/CLJNIUtils.hpp:174:1: error: unknown type name 'cl_queue_properties'
cl_queue_properties* createQueuePropertiesArray(JNIEnv *env, jobject properties);
^
/Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/CLJNIUtils.hpp:175:1: error: unknown type name 'cl_pipe_properties'; did you mean 'cl_context_properties'?
cl_pipe_properties* createPipePropertiesArray(JNIEnv *env, jobject properties);
^~~~~~~~~~~~~~~~~~
cl_context_properties
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:27:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.hpp:35:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/JOCLCommon.hpp:42:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/include/CL/opencl.h:40:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note: 'cl_context_properties' declared here
typedef intptr_t            cl_context_properties;
                            ^
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:33:
/Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/CLJNIUtils.hpp:176:1: error: unknown type name 'cl_sampler_properties'; did you mean 'cl_context_properties'?
cl_sampler_properties* createSamplerPropertiesArray(JNIEnv *env, jobject properties);
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.cpp:27:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.hpp:35:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/native/JOCLCommon.hpp:42:
In file included from /Users/ashishnegi/gitprojs/JOCLRoot/JOCLCommon/src/main/include/CL/opencl.h:40:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note: 'cl_context_properties' declared here
typedef intptr_t            cl_context_properties;
                            ^
3 errors generated.

Current OpenCl/cl.h

/*******************************************************************************
 * Copyright (c) 2008 - 2012 The Khronos Group Inc.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and/or associated documentation files (the
 * "Materials"), to deal in the Materials without restriction, including
 * without limitation the rights to use, copy, modify, merge, publish,
 * distribute, sublicense, and/or sell copies of the Materials, and to
 * permit persons to whom the Materials are furnished to do so, subject to
 * the following conditions:
 *
 * The above copyright notice and this permission notice shall be included
 * in all copies or substantial portions of the Materials.
 *
 * THE MATERIALS ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
 * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
 * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
 * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 * MATERIALS OR THE USE OR OTHER DEALINGS IN THE MATERIALS.
 ******************************************************************************/

#ifndef __OPENCL_CL_H
#define __OPENCL_CL_H

#ifdef __APPLE__
#include <OpenCL/cl_platform.h>
#else

From googling around the last 2 hours.. i think that it is not possible to get newer version of opencl on Mac OS X.. However, Khronos website says that All of the following headers should be present in a directory CL/ (or OpenCL/ on MacOS X). even for 2.1 headers..
Can you give some suggestions about this ?
Thanks.

from jocl.

(EDIT: Also see the notes at the bottom)

It seems that in this https://github.com/gpu/JOCLCommon/blob/master/src/main/include/CL/opencl.h#L40 it is including the header from the "Frameworks" directory, although it should use the local ones. Sure, locally there is no "OpenCL" directory, so it can not find them. (The headers in the "Frameworks" directory seem to be from OpenCL 1.2, and not 2.0).

I'm not sure about the best and most portable solution for this (I'm afraid there are subtle details regarding the include path search on Mac and this "Frameworks" folder handling...).

A very crude "hack", just to see whether this really is the reason: What happens when you copy the local "/include/CL" folder to create an additional folder "/include/OpenCL" ?

I guess, somehow it has to be told to not use the "Frameworks" headers, but the local ones...

EDIT: In doubt, it worked properly with the previous version, without the Apple-Specific includes. So instead of copying the whole folder, could you try whether it works when using the previous version of the opencl.h:

https://github.com/gpu/JOCLCommon/blob/39183e245a8a3366ef9e6ebb1b602df4d81870af/src/main/include/CL/opencl.h

If this works, I'll just omit the Apple-specific lookup, so that it only works on the files in the local include path.

from jocl.

Note that there has been another update that may be related to this one - see #3 (comment)

from jocl.

On Mac OS X 10.11.3 ：
[linkerlin@MBP JOCLCommon]$ make
[ 16%] Building CXX object CMakeFiles/JOCLCommon.dir/src/main/native/Logger.cpp.o
[ 33%] Building CXX object CMakeFiles/JOCLCommon.dir/src/main/native/CLJNIUtils.cpp.o
In file included from /Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:31:
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.hpp:174:1: error: unknown type
name 'cl_queue_properties'
cl_queue_properties* createQueuePropertiesArray(JNIEnv env, jobject properties);
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.hpp:175:1: error: unknown type
name 'cl_pipe_properties'; did you mean 'cl_context_properties'?
cl_pipe_properties createPipePropertiesArray(JNIEnv env, jobject properties);
^~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
'cl_context_properties' declared here
typedef intptr_t cl_context_properties;
^
In file included from /Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:31:
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.hpp:176:1: error: unknown type
name 'cl_sampler_properties'; did you mean 'cl_context_properties'?
cl_sampler_properties createSamplerPropertiesArray(JNIEnv env, jobject properties);
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
'cl_context_properties' declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:213:1: error: unknown type
name 'cl_queue_properties'
cl_queue_properties createQueuePropertiesArray(JNIEnv env, jobject properties)
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:235:5: error: unknown type
name 'cl_queue_properties'
cl_queue_properties *nativeProperties = new cl_queue_properties[javaProperties...
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:235:49: error: unknown
type name 'cl_queue_properties'
cl_queue_properties *nativeProperties = new cl_queue_properties[javaProperties...
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:245:32: error: use of
undeclared identifier 'cl_queue_properties'
nativeProperties[i] = (cl_queue_properties)javaPropertyValues[i];
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:261:1: error: unknown type
name 'cl_pipe_properties'; did you mean 'cl_context_properties'?
cl_pipe_properties createPipePropertiesArray(JNIEnv env, jobject properties)
^~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
'cl_context_properties' declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:283:5: error: unknown type
name 'cl_pipe_properties'; did you mean 'cl_context_properties'?
cl_pipe_properties *nativeProperties = new cl_pipe_properties[javaPropertiesSize + 1];
^~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
'cl_context_properties' declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:283:48: error: unknown
type name 'cl_pipe_properties'; did you mean 'cl_context_properties'?
cl_pipe_properties *nativeProperties = new cl_pipe_properties[javaPropertiesSize + 1];
^~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
'cl_context_properties' declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:293:32: error: unknown
type name 'cl_pipe_properties'; did you mean 'cl_context_properties'?
nativeProperties[i] = (cl_pipe_properties)javaPropertyValues[i];
^~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
'cl_context_properties' declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:309:1: error: unknown type
name 'cl_sampler_properties'; did you mean 'cl_context_properties'?
cl_sampler_properties createSamplerPropertiesArray(JNIEnv env, jobject properties)
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
'cl_context_properties' declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:331:5: error: unknown type
name 'cl_sampler_properties'; did you mean 'cl_context_properties'?
cl_sampler_properties *nativeProperties = new cl_sampler_properties[javaProper...
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
'cl_context_properties' declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:331:51: error: unknown
type name 'cl_sampler_properties'; did you mean 'cl_context_properties'?
cl_sampler_properties *nativeProperties = new cl_sampler_properties[javaProper...
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
'cl_context_properties' declared here
typedef intptr_t cl_context_properties;
^
/Users/linkerlin/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:341:32: error: unknown
type name 'cl_sampler_properties'; did you mean 'cl_context_properties'?
nativeProperties[i] = (cl_sampler_properties)javaPropertyValues[i];
^~~~~~~~~~~~~~~~~~~~~
cl_context_properties
/System/Library/Frameworks/OpenCL.framework/Headers/cl.h:62:29: note:
'cl_context_properties' declared here
typedef intptr_t cl_context_properties;
^
15 errors generated.
make[2]: ** [CMakeFiles/JOCLCommon.dir/src/main/native/CLJNIUtils.cpp.o] Error 1
make[1]: *** [CMakeFiles/JOCLCommon.dir/all] Error 2
make: *** [all] Error 2

from jocl.

It still seems to refer to the System/Library/Frameworks/OpenCL.framework/Headers/ - although it should refer to the local headers from the repository. (It needs the OpenCL 2.0 headers, even if only OpenCL 1.2 is installed in the "Frameworks" directory).

(I'll re-check the headers from the repo, but they should already be the 2.0 headers)

Do you know any way to convince CMake to not look into the Frameworks directory, but only into the local one? (Otherswise, I'll try to dig into this, but it's hard to test on non-MacOS-machines)

from jocl.

@gpu I would be able to look into this day after tomorrow.
I would like to ask one thing though. Even if we compile it with 2.0 headers, at run-time.. does JOCL falls back to the actual run-time opencl version present on the user's system ?

from jocl.

Yes, this is the basic idea. (I recently also wrote a few words about this in the forum: https://forum.byte-welt.net/byte-welt-projekte-projects/jocl/19229-jocl_0_2_0-windows-x86_64-dll-link-opencl-dll.html?langid=2#post132024 )

To summarize it: JOCL does not link against a particular OpenCL implementation, It only offers the OpenCL functions, which are then resolved against the OpenCL implementation at runtime (this is done with the OpenCL ICD (Installable Client Driver)).

So JOCL will/should be compiled with the "newest" OpenCL headers. For example, it must be possible to call an OpenCL 2.0 function via JOCL, even if the current OpenCL installation on the target system (or the system where JOCL is compiled) only supports OpenCL 1.2.

(That's what I tried to accomplish by putting the matching headers into the repo, but obviously, there are some issues with that. On the one hand, because Apple needs directory names like OpenCL/cl.h instead of CL/cl.h, and on the other hand, because it has to be told to not use pre-2.0-headers that it may find in the "Frameworks" directory...)

from jocl.

Tried with following ways :

1. Making a copy of CL directory to OpenCL : normal code starts taking the new files.
2. Omitting the Apple-specific lookup.

New changes are needed also for both ways :

#define CL_EXT_SUFFIX__VERSION_1_2_DEPRECATED   CL_EXTENSION_WEAK_LINK AVAILABLE_MAC_OS_X_VERSION_10_7_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_8

#define CL_EXT_PREFIX__VERSION_1_2_DEPRECATED   CL_EXTENSION_WEAK_LINK 

New pull request with change 2

I did not liked 1 as changes in separate files would not be versioned controlled easily due to duplication.

from jocl.

Also.. running mvn test

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building JOCL 0.2.0-RC01-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-enforcer-plugin:1.2:enforce (enforce-maven) @ jocl ---
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ jocl ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/ashishnegi/gitprojs/JOCLRoot/JOCL/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ jocl ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ jocl ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/ashishnegi/gitprojs/JOCLRoot/JOCL/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ jocl ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ jocl ---
[INFO] Surefire report directory: /Users/ashishnegi/gitprojs/JOCLRoot/JOCL/target/surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.jocl.test.JOCLBasicTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec - in org.jocl.test.JOCLBasicTest
Running org.jocl.test.JOCLMinimalPlatformTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in org.jocl.test.JOCLMinimalPlatformTest

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.243 s
[INFO] Finished at: 2016-04-15T18:03:46+05:30
[INFO] Final Memory: 12M/245M
[INFO] ------------------------------------------------------------------------

I see their are 3 tests.. Why only 2 runs ?

from jocl.

Regarding the test cases: One of them is an abstract test, intended as a base class that is no test for itself, but only contains the boilerplate code (platform setup etc.) for other tests.

from jocl.

According to gpu/JOCLCommon#4 , this should be resolved now. Further investigations of why it did not compile with the original headers may be worthwhile, however: Right now, one has to assume that this will be reopened after the update to OpenCL 2.1 ...

from jocl.

Here are the Mac builds :
JOCL-Mac-Builds.zip

It has four folders : Profiling, Release, Running, Testing.
Release should be what you would like to ship.
Others would be helpful for debugging, if need arises.

from jocl.

Thanks again for your contributions!

I wonder whether the current version also compiles on Linux ( @linkerlin - did you gain any new insights regarding #3 ?). If it worked, it could become version 0.2.0-RC2 ...

from jocl.

So on the one hand, I'd like to include this in the download package and Maven. On the other hand, I'm a bit unsure about the version of the Java part that you tested them with. (It has to work with https://github.com/gpu/JOCL/releases/tag/jocl-0.2.0-RC00 ).

Obviously, now that the transition to GitHub completes, and contributions are popping up here, I'll have to streamline the compilation of the natives, the versioning and the releases a bit. (Something like https://docs.travis-ci.com/user/deployment/releases/ might be a solution here, but I'm still investigating this...)

from jocl.

Java version on my machine :

➜  admin git:(trigger-history) ✗ java -version
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)

Travis ci would be great to have. 👍

from jocl.

The first part of the comment referred to the fact that the native library has to work together with the JAR file that is contained in http://jocl.org/downloads/JOCL-0.2.0-RC-bin.zip (and in the corresponding maven package).

I'll try to read more about Travis CI, and how well it works with the mix of natives (for different platforms) and the JAR that should eventually contain the native libraries. The current build/release process has too many bottlenecks.

from jocl.