CMake Process

[matusi143]

I just downloaded and attempted to the the latest version running using CMake. However, the make-file references a few things which I believe would need to be in my %PATH but I didn't want to do that as I change versions frequently. I tried to hard code them:

set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)

find_package(Boost) _commented out in favor of the line below_

include_directories("C:/boost_1_54_0")

find OpenCL

find_package(OpenCL REQUIRED) **commented out in favor of the lines below **

include_directories(${OPENCL_INCLUDE_DIR})
link_directories(${OPENCL_LIBRARIES})
link_directories("C:/Users/matth_000/AMD APP SDK/2.9/lib/x86_64")

After these changes cmake appeared to run fine, although I was unsuccessful in getting the program to build in qt5. Perhaps I am missing some steps in the instructions.

If you could please provide more detailed steps for the cmake build process and provide either directions on how to use the find_package function or leave it as a build parameter it would be helpful.

[namikk]

Hi,

the default CMakeLists currently has significant issues with enabling
OpenCL. I did my best to try and make it work, but until someone more
experienced does it right I'm afraid there's nothing I can do. The furthest
I got with setting it up on my machine are a couple of multiple
definitions of OpenCL function and a mysterious file format not recognized
error for OpenCL.dll. You can still use the old CMakeLists_Qt4 & 5 files if
you want to run it without OpenCL.

Best regards, Namik

On Sun, Jun 29, 2014 at 8:09 PM, matusi143 notifications@github.com wrote:

I just downloaded and attempted to the the latest version running using
CMake. However, the make-file references a few things which I believe would
need to be in my %PATH but I didn't want to do that as I change versions
frequently. I tried to hard code them:

set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
#find_package(Boost) commented out in favor of the line below
include_directories("C:/boost_1_54_0")

#find OpenCL
#find_package(OpenCL REQUIRED) **commented out in favor of the lines
below **
include_directories(${OPENCL_INCLUDE_DIR})
link_directories(${OPENCL_LIBRARIES})
link_directories("C:/Users/matth_000/AMD APP SDK/2.9/lib/x86_64")

After these changes cmake appeared to run fine, although I was
unsuccessful in getting the program to build in qt5. Perhaps I am missing
some steps in the instructions.

If you could please provide more detailed steps for the cmake build
process and provide either directions on how to use the find_package
function or leave it as a build parameter it would be helpful.

—
Reply to this email directly or view it on GitHub
#2.

[ptillet]

Hi,

According to the FindOpenCL.cmake, it should work either if:
-> the environment variable OPENCLROOT is set
-> OpenCL is installed in default directories : /usr/, /usr/local/

Personally, I've been using symbolic links to handle OpenCL
including/linking.

Philippe

2014-06-30 0:12 GMT+02:00 Namik Karovic notifications@github.com:

Hi,

the default CMakeLists currently has significant issues with enabling
OpenCL. I did my best to try and make it work, but until someone more
experienced does it right I'm afraid there's nothing I can do. The
furthest
I got with setting it up on my machine are a couple of multiple
definitions of OpenCL function and a mysterious file format not recognized
error for OpenCL.dll. You can still use the old CMakeLists_Qt4 & 5 files
if
you want to run it without OpenCL.

Best regards, Namik

On Sun, Jun 29, 2014 at 8:09 PM, matusi143 notifications@github.com
wrote:

I just downloaded and attempted to the the latest version running using
CMake. However, the make-file references a few things which I believe
would
need to be in my %PATH but I didn't want to do that as I change versions
frequently. I tried to hard code them:

set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
#find_package(Boost) commented out in favor of the line below
include_directories("C:/boost_1_54_0")

#find OpenCL
#find_package(OpenCL REQUIRED) **commented out in favor of the lines
below **
include_directories(${OPENCL_INCLUDE_DIR})
link_directories(${OPENCL_LIBRARIES})
link_directories("C:/Users/matth_000/AMD APP SDK/2.9/lib/x86_64")

After these changes cmake appeared to run fine, although I was
unsuccessful in getting the program to build in qt5. Perhaps I am
missing
some steps in the instructions.

If you could please provide more detailed steps for the cmake build
process and provide either directions on how to use the find_package
function or leave it as a build parameter it would be helpful.

—
Reply to this email directly or view it on GitHub
#2.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[matusi143]

Namik, thank you for the update. I will wait for the next version. Do you plan on offering an interim release that will build so people can see the UI and offer feedback on the matrix market interface when that becomes available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I can modify my %PATH to allow OPENCLROOT to work or is that Linux only as well?

[ptillet]

Hi,

I think it has nothing to do with the %PATH. You probably need to set the
environment variable OPENCLROOT. The CMake script will look for.
$ENV{OPENCLROOT}/include/
$ENV{OPENCLROOT}/lib/x86/
$ENV{OPENCLROOT}/lib/x86_64/
With cmake handling the proper delimiters on Windows.

If the environment variable OPENCLROOT is not set, the CMake script uses
ATISTREAMSDKROOT, AMDAPPSDKROOT, INTELOCLSDKROOT. Some may be missing on
newer SDKs. What SDK are you using? Does it set an environment variable for
the path during the installation process?

Philipe

2014-06-30 2:25 GMT+02:00 matusi143 notifications@github.com:

Namik, thank you for the update. I will wait for the next version. Do you
plan on offering an interim release that will build so people can see the
UI and offer feedback on the matrix market interface when that becomes
available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I can
modify my %PATH to allow OPENCLROOT to work or is that Linux only as well?

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[karlrupp]

Philippe is right, this is all set through the environment variables in Windows, as this is the only way to automatically detect an OpenCL SDK. Have a look here: http://superuser.com/questions/502358/easier-way-to-change-environment-variables-in-windows-8
on how to do this. If your SDK uses a different variable name, please let us know so that we can update the OpenCL detection accordingly.

[namikk]

Hi,

I already tried setting OPENCLROOT, but it yielded the same results as any
other attempt.

I get a couple of these: error: multiple definition of
viennacl::linalg::double_float_conversion_program'; And a couple thousands of these: error: Cannot get section contents - auto-import exception; Resulting in this: :-1: error: CMakeFiles\ViennaCL_Benchmark.dir/objects.a(benchmark_solver.cpp.obj): bad reloc address 0x0 in section.data'

I have no idea what causes this.

Namik

On Mon, Jun 30, 2014 at 12:12 PM, PhilippeTillet notifications@github.com
wrote:

Hi,

I think it has nothing to do with the %PATH. You probably need to set the
environment variable OPENCLROOT. The CMake script will look for.
$ENV{OPENCLROOT}/include/
$ENV{OPENCLROOT}/lib/x86/
$ENV{OPENCLROOT}/lib/x86_64/
With cmake handling the proper delimiters on Windows.

If the environment variable OPENCLROOT is not set, the CMake script uses
ATISTREAMSDKROOT, AMDAPPSDKROOT, INTELOCLSDKROOT. Some may be missing on
newer SDKs. What SDK are you using? Does it set an environment variable
for
the path during the installation process?

Philipe

2014-06-30 2:25 GMT+02:00 matusi143 notifications@github.com:

Namik, thank you for the update. I will wait for the next version. Do
you
plan on offering an interim release that will build so people can see
the
UI and offer feedback on the matrix market interface when that becomes
available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I
can
modify my %PATH to allow OPENCLROOT to work or is that Linux only as
well?

—
Reply to this email directly or view it on GitHub
<
https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47486070>

.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[karlrupp]

The problem with double_float_conversion_program is fixed here:
viennacl/viennacl-dev@d47c8ab
(the source string accidentally had external linkage, hence the multiple definitions when you linked the object files together)
The other error might stem from a missing -fPIC flag, yet it seems to be MinGW specific. Can you create a minimal example to reproduce the error?

[namikk]

Quick update,

It seems that the errors I mentioned appear only in the benchmark_solver.
Disabling it completely removes the errors. I can now run the benchmark
with OpenCL support on my GPU. There is definitely something fishy with
solver benchmark (it causes the Heisenbug as well).

As for what I did to enable OpenCL:
-installed AMD APP SDK 2.9 in a custom folder (C:\AMDAPPSDK);
-removed all traces of OpenCL paths from the environment variables;
-added environment variable OPENCLROOT to this custom folder (C:\AMDAPPSDK);
-used FindOpenCL.cmake with CMake to find OpenCL automatically;

I'll update the CMakeLists file and Readme to better describe the build
process.

Regards, Namik

On Mon, Jun 30, 2014 at 12:31 PM, Namik Karovic namik.karovic@gmail.com
wrote:

Hi,

I already tried setting OPENCLROOT, but it yielded the same results as any
other attempt.

I get a couple of these: error: multiple definition of
viennacl::linalg::double_float_conversion_program'; And a couple thousands of these: error: Cannot get section contents - auto-import exception; Resulting in this: :-1: error: CMakeFiles\ViennaCL_Benchmark.dir/objects.a(benchmark_solver.cpp.obj): bad reloc address 0x0 in section.data'

I have no idea what causes this.

Namik

On Mon, Jun 30, 2014 at 12:12 PM, PhilippeTillet <notifications@github.com

wrote:

Hi,

I think it has nothing to do with the %PATH. You probably need to set the
environment variable OPENCLROOT. The CMake script will look for.
$ENV{OPENCLROOT}/include/
$ENV{OPENCLROOT}/lib/x86/
$ENV{OPENCLROOT}/lib/x86_64/
With cmake handling the proper delimiters on Windows.

If the environment variable OPENCLROOT is not set, the CMake script uses
ATISTREAMSDKROOT, AMDAPPSDKROOT, INTELOCLSDKROOT. Some may be missing on
newer SDKs. What SDK are you using? Does it set an environment variable
for
the path during the installation process?

Philipe

2014-06-30 2:25 GMT+02:00 matusi143 notifications@github.com:

Namik, thank you for the update. I will wait for the next version. Do
you
plan on offering an interim release that will build so people can see
the
UI and offer feedback on the matrix market interface when that becomes
available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I
can
modify my %PATH to allow OPENCLROOT to work or is that Linux only as
well?

—
Reply to this email directly or view it on GitHub
<
https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47486070>

.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[namikk]

Hi,

The problem with double_float_conversion_program is fixed here:
viennacl/viennacl-dev@d47c8ab

viennacl/viennacl-dev@d47c8ab94b4f204573cca6fea1dd23e858e7098c(the
source string accidentally had external linkage, hence the multiple
definitions when you linked the object files together)
The other error might stem from a missing -fPIC flag, yet it seems to be
MinGW specific. Can you create a minimal example to reproduce the error?

This reminded me that I haven't updated my local ViennaCL repo for quite
some time. Now that I got the latest version, the version that work with
OpenCL a moment ago fails to compile with the following errors:

1. ..\viennacl-dev\viennacl\ocl\kernel.hpp:241: error: request for member
   'handle' in 'val', which is of non-class type 'const long int'
   cl_mem temp = val.handle().opencl_handle().get();
2. ..\viennacl-dev\viennacl\ocl\kernel.hpp:241: error: request for member
   'handle' in 'val', which is of non-class type 'const long unsigned int';

These new errors seem oddly familiar, but I don't know what needs to be
done to fix them.

Namik

On Mon, Jun 30, 2014 at 12:42 PM, Namik Karovic namik.karovic@gmail.com
wrote:

Quick update,

It seems that the errors I mentioned appear only in the benchmark_solver.
Disabling it completely removes the errors. I can now run the benchmark
with OpenCL support on my GPU. There is definitely something fishy with
solver benchmark (it causes the Heisenbug as well).

As for what I did to enable OpenCL:
-installed AMD APP SDK 2.9 in a custom folder (C:\AMDAPPSDK);
-removed all traces of OpenCL paths from the environment variables;
-added environment variable OPENCLROOT to this custom folder
(C:\AMDAPPSDK);
-used FindOpenCL.cmake with CMake to find OpenCL automatically;

I'll update the CMakeLists file and Readme to better describe the build
process.

Regards, Namik

On Mon, Jun 30, 2014 at 12:31 PM, Namik Karovic namik.karovic@gmail.com
wrote:

Hi,

I already tried setting OPENCLROOT, but it yielded the same results as
any other attempt.

I get a couple of these: error: multiple definition of
viennacl::linalg::double_float_conversion_program'; And a couple thousands of these: error: Cannot get section contents - auto-import exception; Resulting in this: :-1: error: CMakeFiles\ViennaCL_Benchmark.dir/objects.a(benchmark_solver.cpp.obj): bad reloc address 0x0 in section.data'

I have no idea what causes this.

Namik

On Mon, Jun 30, 2014 at 12:12 PM, PhilippeTillet <
notifications@github.com> wrote:

Hi,

I think it has nothing to do with the %PATH. You probably need to set
the
environment variable OPENCLROOT. The CMake script will look for.
$ENV{OPENCLROOT}/include/
$ENV{OPENCLROOT}/lib/x86/
$ENV{OPENCLROOT}/lib/x86_64/
With cmake handling the proper delimiters on Windows.

If the environment variable OPENCLROOT is not set, the CMake script uses
ATISTREAMSDKROOT, AMDAPPSDKROOT, INTELOCLSDKROOT. Some may be missing on
newer SDKs. What SDK are you using? Does it set an environment variable
for
the path during the installation process?

Philipe

2014-06-30 2:25 GMT+02:00 matusi143 notifications@github.com:

Namik, thank you for the update. I will wait for the next version. Do
you
plan on offering an interim release that will build so people can see
the
UI and offer feedback on the matrix market interface when that becomes
available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I
can
modify my %PATH to allow OPENCLROOT to work or is that Linux only as
well?

—
Reply to this email directly or view it on GitHub
<
https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47486070>

.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[ptillet]

Hi Namik,

Can you reset before my Sat Jun 28th commit and retry? I pushed some big
changes, which have not yet been tested on windows.

Philippe

2014-06-30 13:30 GMT+02:00 Namik Karovic notifications@github.com:

Hi,

The problem with double_float_conversion_program is fixed here:
viennacl/viennacl-dev@d47c8ab

<
viennacl/viennacl-dev@d47c8ab94b4f204573cca6fea1dd23e858e7098c>(the

source string accidentally had external linkage, hence the multiple
definitions when you linked the object files together)
The other error might stem from a missing -fPIC flag, yet it seems to be
MinGW specific. Can you create a minimal example to reproduce the error?

This reminded me that I haven't updated my local ViennaCL repo for quite
some time. Now that I got the latest version, the version that work with
OpenCL a moment ago fails to compile with the following errors:

1. ..\viennacl-dev\viennacl\ocl\kernel.hpp:241: error: request for member
   'handle' in 'val', which is of non-class type 'const long int'
   cl_mem temp = val.handle().opencl_handle().get();
2. ..\viennacl-dev\viennacl\ocl\kernel.hpp:241: error: request for member
   'handle' in 'val', which is of non-class type 'const long unsigned int';

These new errors seem oddly familiar, but I don't know what needs to be
done to fix them.

Namik

On Mon, Jun 30, 2014 at 12:42 PM, Namik Karovic namik.karovic@gmail.com
wrote:

Quick update,

It seems that the errors I mentioned appear only in the
benchmark_solver.
Disabling it completely removes the errors. I can now run the benchmark
with OpenCL support on my GPU. There is definitely something fishy with
solver benchmark (it causes the Heisenbug as well).

As for what I did to enable OpenCL:
-installed AMD APP SDK 2.9 in a custom folder (C:\AMDAPPSDK);
-removed all traces of OpenCL paths from the environment variables;
-added environment variable OPENCLROOT to this custom folder
(C:\AMDAPPSDK);
-used FindOpenCL.cmake with CMake to find OpenCL automatically;

I'll update the CMakeLists file and Readme to better describe the build
process.

Regards, Namik

On Mon, Jun 30, 2014 at 12:31 PM, Namik Karovic namik.karovic@gmail.com

wrote:

Hi,

I already tried setting OPENCLROOT, but it yielded the same results as
any other attempt.

I get a couple of these: error: multiple definition of
viennacl::linalg::double_float_conversion_program'; And a couple thousands of these: error: Cannot get section contents - auto-import exception; Resulting in this: :-1: error: CMakeFiles\ViennaCL_Benchmark.dir/objects.a(benchmark_solver.cpp.obj): bad reloc address 0x0 in section.data'

I have no idea what causes this.

Namik

On Mon, Jun 30, 2014 at 12:12 PM, PhilippeTillet <
notifications@github.com> wrote:

Hi,

I think it has nothing to do with the %PATH. You probably need to set
the
environment variable OPENCLROOT. The CMake script will look for.
$ENV{OPENCLROOT}/include/
$ENV{OPENCLROOT}/lib/x86/
$ENV{OPENCLROOT}/lib/x86_64/
With cmake handling the proper delimiters on Windows.

If the environment variable OPENCLROOT is not set, the CMake script
uses
ATISTREAMSDKROOT, AMDAPPSDKROOT, INTELOCLSDKROOT. Some may be missing
on
newer SDKs. What SDK are you using? Does it set an environment
variable
for
the path during the installation process?

Philipe

2014-06-30 2:25 GMT+02:00 matusi143 notifications@github.com:

Namik, thank you for the update. I will wait for the next version.
Do
you
plan on offering an interim release that will build so people can
see
the
UI and offer feedback on the matrix market interface when that
becomes
available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how
I
can
modify my %PATH to allow OPENCLROOT to work or is that Linux only as
well?

—
Reply to this email directly or view it on GitHub
<

https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47486070>

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47515324>

.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[matusi143]

Thanks guys. I'll synch things up and test this tonight. Should I be using the dev version of VIennaCL rather than 1.5.2? If so, should I be looking at June 27th image on github?

I'm using the AMD 2.9 SDK installed to its default directory. I will check out my env variables later when I get back to my test computer.

[ptillet]

Hi,

The current dev version works fine under Clang and GCC. You're more than
welcome to test it with VS ; maybe it works, too ! :)
However, Namik's bug may come from another previous commit. git-bisect can
also help finding the origin of the error.

Philippe

2014-06-30 14:09 GMT+02:00 matusi143 notifications@github.com:

Thanks guys. I'll synch things up and test this tonight. Should I be using
the dev version of VIennaCL rather than 1.5.2? If so, should I be looking
at June 27th image on github?

I'm using the AMD 2.9 SDK installed to its default directory. I will check
out my env variables later when I get back to my test computer.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[namikk]

Can you reset before my Sat Jun 28th commit and retry? I pushed some big

changes, which have not yet been tested on windows.

Philippe, thanks for the hint. I made a local temporary ViennaCL branch
from the 2014-06-25 23:36:12 commit. I then manually added Karl's multiple
definitions fix
viennacl/viennacl-dev@d47c8ab.
It works great now. And there's more good news. I just tested full
benchmark_solver, including CG solver (ILU0 preconditioner) via ViennaCL,
compressed_matrix that was causing the Heisenbug. It seems to be gone now.
I'll have to do more testing in order to confirm it though.

Many thanks for the help, Namik

On Mon, Jun 30, 2014 at 2:09 PM, matusi143 notifications@github.com wrote:

Thanks guys. I'll synch things up and test this tonight. Should I be using
the dev version of VIennaCL rather than 1.5.2? If so, should I be looking
at June 27th image on github?

I'm using the AMD 2.9 SDK installed to its default directory. I will check
out my env variables later when I get back to my test computer.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[matusi143]

Namik,

Much progress, however, I am now encountering the following error in CMake:

Boost version: 1.56.0
CMake Error at CMakeLists.txt:72 (find_package):
By not providing "FindOpenCL.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "OpenCL", but
CMake did not find one.

Could not find a package configuration file provided by "OpenCL" with any
of the following names:

OpenCLConfig.cmake
opencl-config.cmake

Add the installation prefix of "OpenCL" to CMAKE_PREFIX_PATH or set
"OpenCL_DIR" to a directory containing one of the above files. If "OpenCL"
provides a separate development package or SDK, be sure it has been
installed.

I had a ton of qt5 errors but I was able to find those files and get past them by manually entering them. For example:

C:\Qt\5.3\msvc2013_64\lib\cmake\Qt5Quick

Unfortunately, it looks like OpenCLConfig.cmake should be part of the benchmark-gui and perhaps it is not checked into the repository. Any help would be greatly appreciated.

Thanks,
-Matt

[matusi143]

Phillipe,

Thank you, setting my boost_root and OPENCLROOT to the appropriate directories in the environmental variables worked well.

Trying to build the latest version of viennacl in cmake was a long process in manually finding files but ultimately worked pretty well. As the release gets closer, please let me know and I will test the process on Windows 8.1, CMake 3.0 and 2.8.11.2 with VS2013.

Thanks,
-Matt

[karlrupp]

The build errors on Visual Studio with the latest tip of viennacl-dev should be fixed here: viennacl/viennacl-dev@2582f9b
Currently there are still quite a number of warnings emitted, I'll work with Philippe on fixing these asap.

[matusi143]

Karl,

Thank you, the CMake for viennacl-dev as well as the compile with VS2013 now runs well. There are a bunch of warning as you mentioned. Thank you, as always, for the quick turnaround!

-Matt

[matusi143]

Namik,

I am still having trouble using CMake with viennacl-benchmark-gui. I will repost my message from a couple days ago for reference.

Thanks,
-Matt

Boost version: 1.56.0
CMake Error at CMakeLists.txt:72 (find_package):
By not providing "FindOpenCL.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "OpenCL", but
CMake did not find one.

Could not find a package configuration file provided by "OpenCL" with any
of the following names:

OpenCLConfig.cmake
opencl-config.cmake

Add the installation prefix of "OpenCL" to CMAKE_PREFIX_PATH or set
"OpenCL_DIR" to a directory containing one of the above files. If "OpenCL"
provides a separate development package or SDK, be sure it has been
installed.

[namikk]

Matthew,

I guess you didn't notice I updated the Readme file to better describe
building with OpenCL.

First you need to make sure your CMake has the FindOpenCL module. The error
you are seeing is due to CMake not having this module and thus not being
able to automatically find OpenCL. To add it, get the FindOpenCL.cmake file
found in viennacl/viennacl-dev/cmake/ folder and copy it to your CMake's
modules folder - e.g. C:\Program Files (x86)\CMake
2.8\share\cmake-2.8\Modules. Your CMake should now be able to automatically
find OpenCL libs, headers, and dlls.

Also take care that OPENCLROOT variable is set ( I guess you've done this
already) and that OpenCL.dll can be found in your environment path (if it
can't be found, try adding the bin folder of your OpenCL SDK to your system
path).

That's all that needs to be done, as far as I know.

Best regards,
Namik

On Wed, Jul 2, 2014 at 7:03 PM, Matthew Musto notifications@github.com
wrote:

Namik,

I am still having trouble using CMake with viennacl-benchmark-gui. I will
repost my message from a couple days ago for reference.

Thanks,
-Matt

Boost version: 1.56.0
CMake Error at CMakeLists.txt:72 (find_package):
By not providing "FindOpenCL.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "OpenCL", but
CMake did not find one.

Could not find a package configuration file provided by "OpenCL" with any
of the following names:

OpenCLConfig.cmake
opencl-config.cmake

Add the installation prefix of "OpenCL" to CMAKE_PREFIX_PATH or set
"OpenCL_DIR" to a directory containing one of the above files. If "OpenCL"
provides a separate development package or SDK, be sure it has been
installed.

—

Reply to this email directly or view it on GitHub
#2 (comment)
.

[karlrupp]

Thanks for looking into this, Namik. I think we can also use the same approach here as for viennacl-dev and just hold the FindOpenCL.cmake separately. I'll play with this (hopefully) tomorrow.

[matusi143]

Namik,

Thank you. I had not checked the readme file again. Moving that file allowed CMake to complete. I'm still running into some warning with CMake and ultimately the build in VS2013 didn't work perfectly but I want to spend some time with it first before bothering any of you guys with it.

Thanks again!
-Matt

[matusi143]

Namik,

I mentioned I was still having issues building on VS2013 and I have been unable to easily solve it. Here is the error I am getting.

👎 error: D8021 : invalid numeric argument '/Wno-unused-local-typedefs'

Output:
07:35:33: Starting: "C:\Qt\Tools\QtCreator\bin\jom.exe"
C:\Qt\Tools\QtCreator\bin\jom.exe -f Makefile.Debug
C:\Qt\5.3\msvc2013_64\bin\uic.exe ..\viennacl-benchmark-gui-master\src\ui\mainwindow.ui -o ui_mainwindow.h
cl -c -nologo -Zm200 -Zc:wchar_t -FS -Wno-unused-local-typedefs -Wno-unused-parameter -Zi -MDd -GR -W3 -w34100 -w34189 -EHsc /Fddebug\ViennaCL_Benchmark.pdb -DUNICODE -DWIN32 -DWIN64 -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 -DQT_OPENGL_ES_2_ANGLE -I"..\viennacl-dev-master" -I"..\boost_dev\boost_root" -I"..\Qt\5.3\msvc2013_64\include" -I"..\Qt\5.3\msvc2013_64\include\QtWidgets" -I"..\Qt\5.3\msvc2013_64\include\QtGui" -I"..\Qt\5.3\msvc2013_64\include\QtANGLE" -I"..\Qt\5.3\msvc2013_64\include\QtCore" -I"debug" -I"." -I"." -I"..\Qt\5.3\msvc2013_64\mkspecs\win32-msvc2013" -Fodebug\ @C:\Users\MATTH_~1\AppData\Local\Temp\main.obj.10192.188.jom
cl : Command line error D8021 : invalid numeric argument '/Wno-unused-local-typedefs'
cl -c -nologo -Zm200 -Zc:wchar_t -FS -Wno-unused-local-typedefs -Wno-unused-parameter -Zi -MDd -GR -W3 -w34100 -w34189 -EHsc /Fddebug\ViennaCL_Benchmark.pdb -DUNICODE -DWIN32 -DWIN64 -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 -DQT_OPENGL_ES_2_ANGLE -I"..\viennacl-dev-master" -I"..\boost_dev\boost_root" -I"..\Qt\5.3\msvc2013_64\include" -I"..\Qt\5.3\msvc2013_64\include\QtWidgets" -I"..\Qt\5.3\msvc2013_64\include\QtGui" -I"..\Qt\5.3\msvc2013_64\include\QtANGLE" -I"..\Qt\5.3\msvc2013_64\include\QtCore" -I"debug" -I"." -I"." -I"..\Qt\5.3\msvc2013_64\mkspecs\win32-msvc2013" -Fodebug\ @C:\Users\MATTH_~1\AppData\Local\Temp\menulistwidget.obj.10192.188.jom
cl -c -nologo -Zm200 -Zc:wchar_t -FS -Wno-unused-local-typedefs -Wno-unused-parameter -Zi -MDd -GR -W3 -w34100 -w34189 -EHsc /Fddebug\ViennaCL_Benchmark.pdb -DUNICODE -DWIN32 -DWIN64 -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 -DQT_OPENGL_ES_2_ANGLE -I"..\viennacl-dev-master" -I"..\boost_dev\boost_root" -I"..\Qt\5.3\msvc2013_64\include" -I"..\Qt\5.3\msvc2013_64\include\QtWidgets" -I"..\Qt\5.3\msvc2013_64\include\QtGui" -I"..\Qt\5.3\msvc2013_64\include\QtANGLE" -I"..\Qt\5.3\msvc2013_64\include\QtCore" -I"debug" -I"." -I"." -I"..\Qt\5.3\msvc2013_64\mkspecs\win32-msvc2013" -Fodebug\ @C:\Users\MATTH_~1\AppData\Local\Temp\qcustomplot.obj.10192.203.jom
cl : Command line error D8021 : invalid numeric argument '/Wno-unused-local-typedefs'
jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Debug\Makefile.Debug [debug\menulistwidget.obj] Error 2
cl : Command line error D8021 : invalid numeric argument '/Wno-unused-local-typedefs'
jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Debug\Makefile.Debug [debug\qcustomplot.obj] Error 2
jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Debug\Makefile.Debug [debug\main.obj] Error 2
jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Debug\Makefile [debug] Error 2
07:35:34: The process "C:\Qt\Tools\QtCreator\bin\jom.exe" exited with code 2.
Error while building/deploying project ViennaCL_Benchmark (kit: Desktop Qt 5.3.0 MSVC2013 64bit)
When executing step 'Make'
07:35:34: Elapsed time: 00:06.

Commenting out:

#Disable unused warnings that come from Boost and QCustomPlot
#CONFIG += warn_off
#QMAKE_CXXFLAGS += -Wno-unused-local-typedefs
#QMAKE_CXXFLAGS += -Wno-unused-parameter

Did not make any difference. It appears you were trying to suppress that warning anyway. Any help would be greatly appreciated.

Thanks,
-Matt

[namikk]

Hi Matthew,

I really can't say what is causing these errors. My guess is something's
not compatible with msvc compiler. I'm using mingw and have never seen
errors like these. I'm gonna try and build with msvc to see what's wrong.
Will update if I make any progress.

Regards, Namik

[karlrupp]

Hey Matthey,
did you use a plain CMake build? If so, try to wipe the build folder and rerun CMake. Sometimes these settings don't get wiped out of the cache correctly. I can see that the respective add_definitions()-clause is commented out for both CMake and QMake, so should not cause a problem.

[matusi143]

CMake is running well now. Still a few nits with the output still inserting gcc specific compiler flags. How best do you want me report those issues? Or rather, should I just submit a fix in the git repository for review and possible acceptance?

[karlrupp]

@matusi143 : I just promoted you to collaborator, so feel free to commit 'trivial' fixes directly. For changes which you're not confident about (maybe os-specific, compiler-specific, etc.), please commit them to a new branch and issue a pull request so that we can first check them. Thanks a lot for your contributions :-)

[matusi143]

@karlrupp : Thank you :-) I will be sure to be careful and likely submit even trivial changes to a new branch until I confident in the process.

[karlrupp]

@matusi143 : Haha, we are not working in a strict law&order style, so don't be overly hesitant. ;-)

[ptillet]

@matusi143 https://github.com/matusi143 : Yes, don't be too conservative.
I personally usually only test compilation and the tests relevant to what I
changed. This is not perfect as we saw recently, as blas3_prod-test-opencl
can work but nmf-test-opencl can fail! Running the whole test suite after
each commit is impractical, though, so I find it better to check the Dash
every morning and investigate the errors...

2014-07-08 13:45 GMT+02:00 Karl Rupp notifications@github.com:

@matusi143 https://github.com/matusi143 : Haha, we are not working in a
strict law&order style, so don't be overly hesitant. ;-)

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[karlrupp]

@PhilippeTillet : We also have email notifications via the dashboard. I'll add you to that some time in the future, for now it's still a bit fragile so I don't want to throw too many false positives at you ;-)