[FR] - (SetupTools + Flash-Attn(2&3)) is becoming incompatible with Windows

What's the problem this feature will solve?

Issue: Windows CMD has a limit (~8k?) of how long its commands can be before it crashes on final compile linking with a command too long error.

Flash attention is now built in such a way - which I assume build tools is mostly responsible for the architecture and logistics during building, - that the directory structure is just not possible even when doing extremes like C:\x for an install directory.

Also, I'm not sure what the build tools backend does for calls exactly but something it does stops work arounds like hijacking CMD with PowerShell (12x larger command window).

I realize you can VM but that's just not graceful, not for Flash-Attn, other/future projects, nor the people who need/recommend them.
This is half in the context of thinking ahead, that is, future projects/looming code-inflation given AI and etc. etc.., not expecting an instant fix either lol, unless you got one to spare :)

I feel, while the folks over at flash-attn could try some measures to assist, seeing how the build folders just plumet, I don't think they would fix it for very long given the projects growth and how its final link at this time just has a massive amount of text as is.

Describe the solution you'd like

While I'm sure this is a challenging request, some ideas do come to mind, such as cataloging which repos have had this issue, since it's not super common, not yet

(I did read the requests advisory, and while it's not widespread now, it could be a looming tidal wave SOON!(TM). :P)

I don't see - at this time -, a more hands-on implementation being too problematic, where you could do case-by-case solutions while it's just a few repos (but very high notoriety too.). The goal being to avoid 8k character long commands in the short run, if tailored fixes have an efficient fix/method that is of course, while figuring out more streamlined solutions.

Just optimistic thinking out loud though, really.

Alternative Solutions

for the long run maybe somehow doing a PowerShell -- fallback -- (I understand that if one were to migrate something like build tools entirely to PowerShell it would be chaos, thus fallback)

another idea/suggestion, having he output be incrementally cached in a text file (incrementally, as to not trip the crash, by trying not to trip the crash), as either, a fallback, or a command you could pass via ENV-VARs/User-Install-Call? then, when it's in a txt/input file CMD typically has no issue with long commands.

Just some thoughts. Don't matter how a leak gets plugged long as its plugged.

Additional context

saw no one's really making a peep about it, not over here, and quite honestly, I feel it's more a build-tools issue, than a flash-attn issue.

by proxy xformers has it too, since iirc flash-attn module installs are enabled by default on pip; If I'm mistaken, still a pain to build from source getting all the features etc.

Also, given a few months to a year who knows, could be an everyone issues.

Not super high priority, at this time, though, as there are non-graceful and encumbering ways to yet get flash-attn/xformers-w/flash-attn built/installed on windows, it just seems natural to bring it up as a goal/milestone (or ticking issue) to lookout for.

Code of Conduct

• I agree to follow the PSF Code of Conduct

The issue names no files, tests, or entry points. Start by reproducing the Windows command-length failure while building flash-attn or xformers through Setuptools, then trace the build invocation; done should mean a supported way to complete such builds without exceeding CMD's command limit.