adds a program build interface to compile for a specific device

[bashbaug]

Fixes #60.

This complements the existing program build interface to compile for a vector of devices.

[kpet]

Should we add a test?

[bashbaug]

Should we add a test?

I'm pretty sure the answer to this question is almost always "yes" 😃.

I've added a test for the new interface with a single device since it was relatively straightforward. I was looking to add a test for the existing interface that accepts a vector of devices also, but this turned out to be deceptively difficult, so this PR only tests the new interface.

The main issue is that we've defined a special buildErrHandler for the program build and compile interfaces (but not the program link interface, interestingly enough). This error handler gets used instead of the standard errHandler. The buildErrHandler unconditionally queries the program build log for all devices and includes it in a special BuildError exception if an error occurs. Because the build log is queried unconditionally, it requires a lot more to be mocked to test this interface.

Is this functionality useful, or should the build interfaces be handled via the standard errHandler instead? Note that the sample in the C++ bindings header will work even if we do this, since it queries the build log as part of the exception handler, vs. obtaining it from the exception itself:

        cl::Program vectorAddProgram(programStrings);
        try {
            vectorAddProgram.build("-cl-std=CL2.0");
        }
        catch (...) {
            // Print build info for all devices
            cl_int buildErr = CL_SUCCESS;
            auto buildInfo = vectorAddProgram.getBuildInfo<CL_PROGRAM_BUILD_LOG>(&buildErr);
            for (auto &pair : buildInfo) {
                std::cerr << pair.second << std::endl << std::endl;
            }

            return 1;
        }

[kpet]

I'm pretty sure the answer to this question is almost always "yes" smiley.

This was more of a rhetorical question. Seeing an approved PR adding new functionality without a test, I felt compelled :).

I think buildErrHandler and the unconditional gathering of build logs is useful functionality. Most users will want to see the build log after a failure. Having it directly packaged as part of the exception makes sense to me. Otherwise you need to catch build exceptions separately and then query the build log (or have a special case in the exception handler), this means more code for a very common pattern. Besides, performance really isn't a concern here.

Now I understand how that is a bit of a pain for testing. Maybe we could have utility testing functions to mirror what buildErrHandler and the typical calling code do?

[kpet]

@bashbaug To be clear: I'm fine with this PR as is. Improving testing for existing functionality needn't be done under this PR.

[bashbaug]

I think we should merge this PR as-is. I would like to look at a utility testing function that mirrors buildErrHandler, but I don't expect to have a chance to look at this in the near future.

[kpet]

Created #112 so we don't forget to add the utility function. Merging as agreed on the 2020/09/01 teleconference.