I'm working on a complex translation layer package, which is here. I'm using the C names as swift source file names to make maintaining easier.
I started getting this error
error: command Compiling Swift Module 'Direct3D12' (305 sources) failed: unable to spawn process 'C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\swiftc.exe' (The filename or extension is too long.)
The error is not for a single swift source file, rather it happens because the total length of all paths in the swift target are too long. The error goes away if a remove enough source files, and it doesn't matter which files.
Is this a known compiler limitation or a bug?
This is happening on Windows. The package would need a decent amount of work to be built on other platforms to test if this is a platform issue.
You’ve most likely hit Windows’ 32k character limit for a given command line. I recommend using response files to pass such long command lines to swiftc.
That does sound like its the problem. Verbose output cuts off mid path before throwing the error.
Thanks for the suggestion. Response files look really interesting, but this is a package; I don't think I can change how swiftc enumerates everything. And I’d like to keep it friendly and accessible so people enjoy using it.
I guess I cant use this naming convention, which is a shame. I’ll have to merge most things into a few overly long swift source files instead.
The compiler supports response files but AFAICT Swift Package Manager doesn't use them yet when passing sources to the compiler (@Aciid can verify). SR-8671 looks likes the bug tracking this.
In the meantime, if you can divide the code up into subcomponents, then you can break the big target up into smaller targets and then create a main module that just does @_exported import of the smaller targets to re-export them. Then the smaller targets will compile separately and you can (hopefully) make them fit under the command line length limit, and a user who imports the top-level module will get all the things defined in the lower ones as if they had imported them directly.
Oh sweet I wasn't aware of @_exported import. I was thinking of doing some internal dependency packages and just hoping everything gets referenced and exported. This should make sure they do. I'll definitely try this first. Thanks!
Welp that didn't work. Because of SR-13996 it's impossible to jump back up to the main package to use the systemLibrary as a dependency on Windows. I'd have to duplicate the system library target over and over with different names; and that's moving outside of a reasonable solution for a public package I think.
I'm locked out of progress until one of SR-8671, SR-13996 are resolved. Any other suggestions are welcome.
Maybe I'll just duplicate the systemLibrary to keep development going. Pull Request #35221 will eliminate the need for the systemLibrary which would allow me to clean it up in the near future anyway.
