dblaikie added a comment. In https://reviews.llvm.org/D52296#1282587, @probinson wrote:
> In https://reviews.llvm.org/D52296#1282458, @dblaikie wrote: > > > I guess in that case your distributed build system would have a constraint > > that it always ships all the object files back to the primary machine > > (where you'd be running the debugger)? (perhaps it just always runs the > > link locally - even though it distributes the compilations - I guess that's > > probably how things like distcc work, where they only inject themselves > > into the compilation command, not the linking command maybe?) > > > AFAIK this is how distcc, icecc, SN-DBS all work. Compilations are > distributed, the .o files come back, links are local. Thanks! I've never used them, so was just guessing/estimating. > > >> Also, may require some work/more flags to handle the possible file renaming >> (or relative/absolute adjustment) when object files are built on a remote >> system in one location, but then moved back to the local system and placed >> in another location? > > Any distributed build has to make this work, so the paths in the line table > are usable. Not clear what you're thinking might be the problem with the > split-in-.o case. Fair point - same sort of problem, but might need distinct handling (ie: might not work "for free" with existing tools, but need more support), etc, depending on how it's solved? Mostly just wondering whether Clang would need extra flags to support this - to get a sense of the total/overall solution/surface area of the feature, etc. https://reviews.llvm.org/D52296 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
