Update to latest dev build and swap to `COOT_KERNEL_SOURCE_DIR` during package load

[coatless]

The version of bandicoot under RcppBandicoot has a shim right now for just OpenCL. Two steps:

1. Register environment variable after package load:

rcppbandicoot/R/rcppbandicoot-package.R

Lines 10 to 18 in 8be42b7

	.onLoad <- function(libname, pkgname) {
	# Set the kernel path for Bandicoot OpenCL kernels
	kernel_path <- system.file("include/bandicoot_bits/opencl/kernels",
	package = "RcppBandicoot")
	if (nzchar(kernel_path)) {
	Sys.setenv(COOT_CL_KERNEL_PATH = kernel_path)
	}
	}

2. Place a check:

rcppbandicoot/inst/include/bandicoot_bits/opencl/kernel_src.hpp

Lines 51 to 101 in 8be42b7

	inline
	std::string
	read_file(const std::string& filename)
	{
	std::string full_filename;
	// Check if COOT_CL_KERNEL_PATH environment variable is set
	const char* kernel_path_env = std::getenv("COOT_CL_KERNEL_PATH");
	if (kernel_path_env != nullptr)
	{
	std::string kernel_path_str(kernel_path_env);
	if (!kernel_path_str.empty())
	{
	// Use the path from the environment variable
	full_filename = kernel_path_str + "/" + filename;
	}
	else
	{
	// Fall back to the original behavior using __FILE__
	const std::string this_file = __FILE__;
	// We need to strip the '_src.hpp' from __FILE__.
	full_filename = this_file.substr(0, this_file.size() - 8) + "s/" + filename;
	}
	}
	else
	{
	// Fall back to the original behavior using __FILE__
	const std::string this_file = __FILE__;
	// We need to strip the '_src.hpp' from __FILE__.
	full_filename = this_file.substr(0, this_file.size() - 8) + "s/" + filename;
	}
	std::ifstream f(full_filename);
	std::string file_contents = "";
	if (!f.is_open())
	{
	COOT_CERR_STREAM << "Failed to open " << full_filename << " (kernel source)!\n";
	throw std::runtime_error("Cannot open required kernel source.");
	}
	// Allocate memory for file contents.
	f.seekg(0, std::ios::end);
	file_contents.reserve(f.tellg());
	f.seekg(0, std::ios::beg);
	file_contents.assign(std::istreambuf_iterator<char>(f),
	std::istreambuf_iterator<char>());
	return file_contents;
	}

This should be address for CUDA by merging in the upstream change by Ryan in response to this feedback.

We'll need to switch over to using COOT_KERNEL_SOURCE_DIR instead of what we currently define adhoc COOT_CL_KERNEL_PATH

[eddelbuettel]

Talking a bit with @rcurtin and working with both bandicoot itself and this package, I think my view that was you do here in .onLoad() may not work as the library paths may all be compile-time driven. One can of course set an environment variable but the only environment variables being read right now appear to be HOME and APPDATA (used for the caching).

[coatless]

Is the thought here to then search for environment variables similar to RcppGSL?

https://github.com/eddelbuettel/rcppgsl/blob/e56acf710866e0b85a36d91eaecc475216d139b0/R/inline.R#L21

We can ship just the headers in inst/ similar to a BH package, e.g. remove the demo in src/ in favor of maybe a test package?

[eddelbuettel]

Well but who picks the env var up? The next compilation via inline flags? In that case we should not need it either as the package location reveals it. Simple case of

> system.file("include/bandicoot", package="RcppBandicoot")   
[1] "/usr/local/lib/R/site-library/RcppBandicoot/include/bandicoot"      
>  

(plus the two more layers to the kernels I was too lazy to type here). Or am I missing / misunderstanding something?

And yes an external 'tester' or example package may be a good idea too. "These days" (or years) I also favour disentangling.
But let's get the baby built first. Just wanted to ensure we both knew the build of the package was not using the env var. (But of that is my general confusion around 'but CUDA does not build for me' which turned out to be an issue now fixed and merged in upstream bandicoot that was after all specific to my combo of hardware (newish) and software (via Ubuntu, maybe not new enough).)

[eddelbuettel]

We can ship just the headers in inst/ similar to a BH package, e.g. remove the demo in src/ in favor of maybe a test package?

That would minimise the risk of CRAN rejection and errors as ... when nothing is actually compiled nothing can go wrong.

The problem, though, is a bit as it is with Armadillo where the use of the wrapper library is prevalent upstream and we do without because we can (LAPACK and BLAS and Fortran generally come from R, OpenMP "mostly" per our other efforts) but that is different here. Still tricky.