build wheels without build isolation

[jameslamb]

Description

Contributes to rapidsai/build-planning#108

Contributes to rapidsai/build-planning#111

Proposes building libcuspatial wheels with --no-build-isolation, to improve the rate of sccache cache hits and therefore reduce CI times.

Also proposes printing sccache stats to CI logs after wheel and conda builds.

Notes for Reviewers

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

How I tested this

Ran a first build with these changes to populate the cache, then ran again... saw a 100% cache hit rate and the actual wheel-building part of a wheel-build-libcuspatial job take only 37 seconds.

Successfully built libcuspatial-cu11
Compile requests                     28
Compile requests executed            28
Cache hits                           28
Cache hits (c [gcc])                  2
Cache hits (c++ [gcc])                2
Cache hits (cuda [nvcc])             24

(build link)

[bdice]

Changes look good to me. Just to verify, nothing is needed for cuproj since it doesn't have C++ wheels, right?

[vyasr]

This looks great! Thanks for iterating a few times James, I think we've come up with a clean end state that we can port everywhere now.

[vyasr]

And yes that's right Bradley, no C++ cuproj. It's built as part of libcuspatial.

[jameslamb]

Added sccache stats printing for conda builds as well based on rapidsai/build-planning#111 and offline conversation with @vyasr .

example build with these: https://github.com/rapidsai/cuspatial/actions/runs/11465788119/job/31906443973?pr=1473

Why not build.sh?

Here, I'm proposing that these be put in ci/build_{cpp,python}.sh, wrapped around any conda mambabuild invocations that will end up compiling anything (so, for example, I included them in build_python.sh because cuspatial and cuproj both have some Cython extensions).

I think this is preferable to build.sh, because the build_{cpp,python}.sh scripts are unambiguously for CI, and can unconditionally invoke sccache. build.sh is invoked in CI, but it's also intended for local use, and I didn't want to assume the presence of sccache for all local builds are introduce the complexity of having to check for its use.

There are also some projects, like cuvs, that have their own handling of printing sccache stats and creating build summary reports based on them in build.sh, and I didn't want to interfere with that.

example:

https://github.com/rapidsai/cuvs/blob/e7f1085b71c340b9600f5f38f7f0059a5c7aa806/build.sh#L364-L366

https://github.com/rapidsai/cuvs/blob/e7f1085b71c340b9600f5f38f7f0059a5c7aa806/build.sh#L408-L424

[jameslamb]

Thanks for the reviews everyone! This looks good to me (double-checked that we're seeing sccache stats we expect and in all the expected places), so I'm going to merge it.

[jameslamb]

/merge