Stop force pulling fmt in nvbench.

[vyasr]

Description

This undoes #12064 and resolves #12065.

Checklist

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

[bdice]

LGTM, if CI passes.

[vyasr]

I have yet to be able to reproduce these errors locally. CI shows nvbench still pulling fmt and failing to patch, the two exact things fixed in these commits, which is odd.

[robertmaynard]

I expect that the failure to configure isn't due to nvbench patching but the above errors:

CMake Error at build/_deps/fmt-src/CMakeLists.txt:232 (add_library):
  add_library cannot create ALIAS target "fmt::fmt" because another target
  with the same name already exists.


CMake Error at build/_deps/fmt-src/CMakeLists.txt:272 (add_library):
  add_library cannot create ALIAS target "fmt::fmt-header-only" because
  another target with the same name already exists.

I expect that this is happening due to using local version of rmm that doesn't have the fmt changes. See CPM: using local package rmm@23.04.0 entry.

[bdice]

@robertmaynard I verified the local package is librmm=23.04.00a=cuda11_230213_gc9c83abb_15 from rapidsai-nightly. That's the build produced after merging rapidsai/rmm#1209. I also installed this package locally and was not able to reproduce.

[robertmaynard]

@robertmaynard I verified the local package is librmm=23.04.00a=cuda11_230213_gc9c83abb_15 from rapidsai-nightly. That's the build produced after merging rapidsai/rmm#1209. I also installed this package locally and was not able to reproduce.

Dang. Going to look at reproducing locally to see what is going wrong

[robertmaynard]

Pushed the changes captured by rapidsai/rapids-cmake#373 to this PR to verify it resolves the CI failures

[bdice]

Looks like CI is stuck. C++ builds have been going for 2+ hours and I don't see output.

[davidwendt]

Looks like CI is stuck. C++ builds have been going for 2+ hours and I don't see output.

I've been watching it too. It just seems really slow.
https://github.com/rapidsai/cudf/actions/runs/4175535853/jobs/7230651971

It looks to be about half done [546/949]
Perhaps this change required rebuilding everything? I'm not sure why it would be so slow.

[vyasr]

Yeah it doesn't look stuck, just extremely slow. I suspect that the change to the way that we use fmt is changing the compile commands in a subtle way (probably just the include path to fmt) that is invalidating all previously existing sccache entries, resulting in a recompilation of the whole library with no caching.

[vyasr]

It looks like a recent change to dask broke us, specifically dask/dask#9889. @rapidsai/cudf-dask-codeowners are there any easy solutions here? If not, I can go ahead and imply the dtypes property for cudf's DataFrameGroupBy class tomorrow, but if there's an easier patch I would prefer that given that this PR now contains multiple changes needed to unblock cudf CI.

[galipremsagar]

I can go ahead and imply the dtypes property for cudf's DataFrameGroupBy class tomorrow, but if there's an easier patch I would prefer that given that this PR now contains multiple changes needed to unblock cudf CI.

That's about right, we will need .dtypes property. (I did go into dask code to see if we can change it, but looks like they are fetching .dtypes to know what columns remain after grouping is performed via a public API.)

[bdice]

I am going to propose admin-merging this to unblock libcudf CI, and @galipremsagar's PR will unblock Python CI.

[vyasr]

Thanks for picking up the follow-up @galipremsagar!