While integrating swiftpm packages to other build systems it is good to have a way to recompile the package if something changes. Currently make and ninja uses .d files for this purpose.
While swiftpm is generating .d files when building, there are a lot of them, so currently we have special python script that os.walks the out dir and “merges” all the depfiles that where found. Moreover, this process is slow enough to take more time than incremental compilation itself.
Can we improve current situation? May be add ability to specify to swift build additional argument where it can put “complete” depfile?
I am way out of my realm of expertise, but I see exactly one .d file per Swift source file (presumably from the compiler, not SwiftPM). I also see precisely one master.swiftdeps file per target. Based on its name and the contents of output-file-map.json, it appears to serve a similar function to a .d file. There is also master.swiftdeps~moduleonly, but I don’t know what the difference is. Maybe one of those will suffice for whatever you are trying to accomplish?
*.swiftdeps files are much more complicated than simple *.d file that other build systems (like make or ninja) can understand. *.swiftdeps file is that enables incremental compilation of a swift module and parsed by swift driver (swiftc or swift build), and includes things like dependencies between files on even symbol level.
That other build system can do is to run specific target (swift build for example) that will produce some output (binary, library, etc). But they need a way to understand that this target needs to be rerun, because of some file where changed, swift compiler updated, something else changed in the environment, etc. Indeed, now that information is stored in *.d file per *.o file, but buildsystem doesn't know anything about intermediate products (especially in spm, where source files located by file globbing).
In swiftc the situation is a little better, because build system already knows all the files needed for compilation, and knows location of .d files, but make and ninja doesn't support multiple depfiles for one target (but supports multiple outputs that are object files), so we need a tool that will merge it into one.
