[+swift-dev, swift-build-dev] Once upon a time I think I had the idea that swiftc should be useful independent of having a Clang install, but we've long since given up on that on Linux and it's not such an interesting configuration on Darwin. I don't have strong objections to merging them, though there might be some trickiness around picking the right profiling libraries (if Swift and Clang are ever out of sync we would ideally prefer Swift's).
The other thing floating around here is something Daniel Dunbar once brought up: usually each compiler wants to own the linker invocation, but then you have a hard time linking object files from multiple compilers using the same linker invocation. (Consider linking with clang vs. clang++, and then needing to add custom arguments for Swift.) It would be nice™ if instead a build system could ask "what additional linker flags do you need before/after your object files?", and put that in as necessary. Jordan > On Dec 17, 2016, at 21:51, Saleem Abdulrasool <compn...@compnerd.org> wrote: > > Hey, > > I was poking at the swift driver today and noticed something in there. Seems > like it directly invokes the linker, yet has a comment about possibly using > clang to avoid duplicating a bunch of logic. > > Im thinking of duplicating some of the driver logic for linking for Windows > and cross-Windows (which becomes much more interesting as I can't see a good > way to handle that via clang atm). Flavoring makes it hard (GNU vs link > style arguments which arent a direct translation) to use clang. > > However, I was wondering if there is a reason to not just re-use clang for > the link on Darwin since there is no flavoring of the linker here AFAIK. > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
