Fix discovery for trampoline files

[vzhurba01]

Fixes #226

[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.

[leofang]

Thanks, Vlad! 🙏 Let me test it again on both platforms before merging.

[leofang]

Tested on both Windows & Linux, all files (pxd/pyx/cpp/h) are included in the wheel 🎉

Q: I noticed this line as I was wondering how version is bumped with versioneer:

cuda-python/cuda_bindings/cuda/bindings/_version.py

Line 56 in 72acaaf

cfg.versionfile_source = "cuda/_version.py"

Do we need to change it to accommodate for new layout?

[vzhurba01]

Tested on both Windows & Linux, all files (pxd/pyx/cpp/h) are included in the wheel 🎉

Q: I noticed this line as I was wondering how version is bumped with versioneer:

cuda-python/cuda_bindings/cuda/bindings/_version.py

Line 56 in 72acaaf

cfg.versionfile_source = "cuda/_version.py"

Do we need to change it to accommodate for new layout?

Using tags, I'm not sure how that snippet there is used for. I recall we wanted to remove versioneers all together.

[leofang]

I recall we wanted to remove versioneers all together.

Yes! Thanks for reminder, I created #233.

[leofang]

To be clear this is NOT a bug fix (the one-liner change below is), just a really unpleasant workaround for presumably two (2) potentially correlated setuptools bugs. Many engineering hours are wasted only to find this WAR in order to accommodate for both Linux and Windows. Yes, we need both; can't just pick either of them.

What happened is (paraphrasing @vzhurba01's comment from the internal discussion): We need to fix pyproject.toml to find all extension modules starting with cuda (which was missed in the hot fix 12.6.2/11.8.5), so that all modules' Cython sources can be included in the package.

However, once we do this we see a very strange error on both platforms at build time

error: can't copy 'cuda/bindings': doesn't exist or not a regular file

which suggests that setuptools tries to copy this folder as a regular file. This is likely the first bug.

What's happening here is that as part of egg_info source file discovery, it fetches files directly from build_ext. Files found use a mix of Linux and Windows path separators (/ and \\, respectively). One of the paths found is cuda/bindings (which should not have happened in the first place).

To work it around, we rely on MANIFEST.in letting us specify which path/file to exclude, and so we added exclude cuda/bindings when we worked on the layout change #137. Since setuptools' docs clearly stated that

File & directory names in MANIFEST.in should be /-separated; setuptools will automatically convert the slashes to the local platform’s appropriate directory separator.

this should have been a cross-platform WAR.

The next bug that bites us is that egg_info tries to be "smart" by converting all Linux separators to Windows, therefore our exclude only applies to cuda\\bindings and thus failing the Windows build later on. This is the second bug, and the WAR is to rely on this documented little trick (same setuptools page as linked above):

? matches a single regular filename character

[leofang]

@thomasjpfan in case you're still interested in knowing what happened 🙂