Reuse <version_config.h> instead of separate version constants in c_api.h

[mythrocks]

This commit started off trying to fix an error in how version strings are replaced in the C API header. (Bumping the version to 25.08 causes the minor version to be written as "08" instead of "8", producing an invalid octal number.)

The octal problem was already solved as part of RAPIDS CMake, which is used in cuVS to generate a version_configi.h with the corrected version values. This commit removes the old version constants, and switches to using what's provided by infrastructure.

[mythrocks]

That the yaml files needed updating on branch-25.08 came as a surprise. I'd appreciate if someone familiar with them reviewed that change closely.

[cjnolet]

@mythrocks

I think the update_version.sh does change the cmake files, doesn't it? I think the suggest was just to have cmake update the c header, rather than relying on update_versions to do it. Honestly, i could go either way with this, so it doesn't matter a ton to me- so long as we aren't forced to update anything manually.

[mythrocks]

(I'll fix the copyright dates shortly.)

[mythrocks]

I think the update_version.sh does change the cmake files, doesn't it?

Not directly. It seems to update the VERSION file, and then CMake does its bit based on the VERSION.

so long as we aren't forced to update anything manually.

I've gotten an idea of how @KyleFromNVIDIA would prefer this were fixed. I'll try incorporate that change ASAP.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[mythrocks]

It took me a little while to realize that what I'm trying to build here might be available already:

cuvs/cpp/CMakeLists.txt

Line 40 in a0804de

rapids_cmake_write_version_file(include/cuvs/version_config.hpp)

[mythrocks]

I have verified that RAPIDS CMake line mentioned above creates build/include/cuvs/version_config.hpp with constants similar to the ones I introduced in c_api.h:

#define CUVS_VERSION_MAJOR 25
#define CUVS_VERSION_MINOR 8
#define CUVS_VERSION_PATCH 0

This file lands up also being CMake-installed into the final install directory.

But I can't seem to find a way to include the header in c_api.h:

/home/mithunr/workspace/dev/cuvs/3/cpp/include/cuvs/core/c_api.h:19:10: fatal error: cuvs/version_config.hpp: No such file or directory
   19 | #include <cuvs/version_config.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~

I'll seek @KyleFromNVIDIA's guidance on how this needs to be included, for the first build.

[mythrocks]

But I can't seem to find a way to include the header in c_api.h:

I've modified the CMakeLists for libcuvs and its tests to find the header correctly. I think this should address what @KyleFromNVIDIA had in mind.

[mythrocks]

/ok to test b973420

[mythrocks]

@KyleFromNVIDIA, please let me know if this looks acceptable.

[KyleFromNVIDIA]

One quick change plus one small note and then I think we're good.

[KyleFromNVIDIA]

Actually left a few more comments, let me know what you think.

[mythrocks]

/ok to test ed14bb7

[mythrocks]

/ok to test 0a98174

[KyleFromNVIDIA]

/ok to test 0a98174

[mythrocks]

/ok to test af53e0e

[mythrocks]

/ok to test bda2c67

[mythrocks]

@KyleFromNVIDIA: After including the cuvs/version_config.h header in c_api.h, I'm seeing a Java build failure:

c_api.h:19:10: error: 'cuvs/version_config.h' file not found

(This wasn't happening before, because the version header was included only in c_api.cpp, and not subject to jextract.)

I fixed this in my local builds by including cpp/build/include in the include paths. But it appears that the path used in CI builds is a different one.

By my reading, even if we were to use the right one for CI, it would still cause jextract to fail in local dev builds. Note that jextract is being run for the Java builds, and not from running cmake.

At this point, I'm inclined to change things back so that:

1. <version_config.h> is included only in the c_api.cpp.
2. Change the jextract code back to not depending on finding <version_config.h>.

Please let me know if that is agreeable.

[mythrocks]

/ok to test 663013a

[mythrocks]

@jameslamb, @rhdong: I was wondering if either of you might be able to help here.

The problem is as follows:

1. There is a header (<cuvs/version_config.h>) that is generated during the C++ build of libcuvs. This is now required in the Java build.
2. I do know that on my workstation, cuvs/version_config.h is generated in $PROJECT_ROOT/cpp/build/include. I don't know what the location of this file is, in the C++ CI build. It doesn't seem to be in cpp/build/include.
3. I have tried including "${REPODIR}"/cpp/build/include as an include-directory for the Java build. But the build still fails to find the header.
4. Debugging the build, I ran a find for the header in $REPODIR. It isn't found.

May I please know in which directory the C++ build artifacts go? Also, what might be the best way to communicate that to the Java build?

(@KyleFromNVIDIA: This is a last-ditch attempt. If there isn't an easy/good way to resolve this, I'd very much like to include the version-header in the c_api.c file, and be done with it for now. We can do a follow-on PR, in case someone misses the version strings being in the c_api.h. That change was too recent for this to be a problem, I think.)

[KyleFromNVIDIA]

If there isn't an easy/good way to resolve this, I'd very much like to include the version-header in the c_api.c file, and be done with it for now. We can do a follow-on PR, in case someone misses the version strings being in the c_api.h. That change was too recent for this to be a problem, I think.

That's fine with me, if you can't figure out another solution then go ahead and do it.

[mythrocks]

/ok to test fc631e1

[KyleFromNVIDIA]

/merge