Closed diiigle closed 1 month ago
Hi, valid point! I'll check the options and will change how OpenCL is added.
Yes, please. At the moment it does not work correctly at all:
CMake Error at external/miss-opencl/CMakeLists.txt:22 (add_subdirectory):
The source directory
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_hwinfo/hwinfo/work/hwinfo-a1ae945ab784780af5fc166150a6f6612d41e7bf/external/miss-opencl/external/OpenCL
does not contain a CMakeLists.txt file.
-- Configuring incomplete, errors occurred!
You need to run git update --init --recursive
first. However, building on Mac has some issues atm since I do not have access to a Mac...
This OpenCL repo does have another downside (for your users) which you might be not aware of:
fatal: clone of 'https://github.com/throwtheswitch/cexception.git' into submodule path 'C:/Users/myname/repositories/my-looongish-repo-name/ext/hwinfo/external/miss-opencl/external/OpenCL/external/OpenCL-CLHPP/external/CMock/vendor/c_exception' failed
Failed to clone 'vendor/c_exception'. Retry scheduled
Cloning into 'C:/Users/myname/repositories/my-looongish-repo-name/ext/hwinfo/external/miss-opencl/external/OpenCL/external/OpenCL-CLHPP/external/CMock/vendor/c_exception'...
fatal: cannot write keep file 'C:/Users/myname/repositories/my-looongish-repo-name/.git/modules/ext/hwinfo/modules/external/miss-opencl/modules/external/OpenCL/modules/headers-cpp/modules/external/CMock/modules/vendor/c_exception/objects/pack/pack-fd8baa50a07a4317443b1e3b5520f09f92fa84cf.keep': Filename too long
The submodules are nested so deep, that some filenames run out of MAX_PATH=260 on Windows. I can't even clone my own repo any more because of that unless I go to C:\tmp\
or something.
Fruit for thought, if OpenCL isn't a bit of an overkill.
Edit:
git -c submodule."external/miss-opencl".update=none submodule update --init --recursive
seems to be a workaround for now. https://stackoverflow.com/a/52185169
Yes, OpenCL kind of is an overkill, but for now, I found no other way to retrieve GPU Memory information...
I would suggest removing GPU information from the library entirely. If people need information about the GPU, getting it from Vulkan, DirectX, OpenGL, or OpenCL is already really well documented. Those standards [and similar] are really the only places people would need it anyhow.
I'm not trying to be rude, but there really is zero reason to include it. For people who are already using one of these frameworks, adding OpenCL on top of it is unacceptable in most cases especially considering OpenCL is on its way out the door to be replaced with other alternative frameworks.
Edit: Had a quick think. It'd probably be better to make the entire library modular. You already have the library well divided as appropriate, making it modular seems like a very safe next step. In other words, I mean making the motherboard, battery, CPU, etc. dependent on user choice.
Thank you for your thoughts. I think, that modularity would indeed increase the library's usability.
I'll take this task as soon as possible. Coworkers and ideas are welcome!
Continued in #94
Is there any way to make OpenCL (quite a heavy chunk to the otherwise small and lightweight library) fully optional? I see you have a CMake option to not use it, however git submodules still downloads the whole subtree, even if one doesn't want it.
https://cmake.org/cmake/help/latest/module/FetchContent.html comes to mind.