[SR-327] Add --outdir argument to swiftc

[swift-ci]

Previous ID	SR-327
Radar	None
Original Reporter	jpakkane (JIRA User)
Type	New Feature

Additional Detail from JIRA

Votes	1
Component/s	Compiler
Labels	New Feature, Driver
Assignee	@modocache
Priority	Medium

md5: ffc5d47714bb694b2a42adb551584a44

relates to:

• SR-7704 swiftc -emit-module -c, driver documentation and diagnostics
• SR-6079 Incremental compilation should not require an output file map
• SR-6271 Unable to emit assembly from swift compiler to multiple files

Issue Description:

Currently swiftc writes all its output to current working directory. Please consider adding a --outdir argument so you can instruct swiftc to write its output to a different directory.

This makes it easier to integrate swiftc with other build systems. For example on Ninja you need to write all paths relative to the top level Ninja file directory. This leads to the weird situation that you need to manually cd into the output directory and invoke swiftc with paths that are different to what the Ninja file has.

As an example suppose you have a swift project with sources in Sources and you want to build in a directory called build and place the temporary files in a directory called build/tmpdir then you Ninja dependency looks [roughly] like this

executable [depends on] ../Sources/myexe.swift

but the compilation command is this:

cd tmpdir; swiftc -c ../../Sources/myexe.swift; cd ..

Note the extra '..' in the source file. This makes integration work needlessly complicated. With --outdir the command would look like this:

swiftc --outdir=tmpdir -c ../Sources/myexe.swift

[belkadan]

We'd need something like this if we want to have incremental builds without having to write out a whole output file map. I'm not quite sure it's the right name because it's the directory used for intermediate files, not outputs, when swiftc is responsible for producing the output binary as well.

[swift-ci]

Comment by Raphael (JIRA)

Yes, please!

@belkadan The we probably need one parameter for tmps and one for outputs?

[belkadan]

Interesting. I'm not sure there are many temporaries that don't make sense to persist in an incremental build, but I suppose we could support a separate directory for those.

[modocache]

I'm interested in trying my hand at this task, if that's alright. I have a few questions:

1. The task description mentions integrating swiftc with build systems such as Ninja. Is there another tool that integrates well with Ninja by providing something similar to this --outdir option? Does Clang provide something like this? I'd like to copy prior art if you have something in mind.

2. Based on the way --outdir behaves in the task description above, to me it sounds similar to git -C <dir>, ninja -C <dir>, and make -C <dir>. That is, an option that switches to the directory <dir> before the tool does anything else. Is that the feature that's being described here?

[modocache]

Thanks to z (JIRA User), who informed me that there's a clang -working-directory option. My understanding is that something similar should be implemented in Swift. I like the name of that option just fine, so I'll begin working on a swift -working-directory option.

[belkadan]

No, this is completely different from -working-directory. That sets PWD; this is providing a place to put object files and other outputs without an output file map. We actually don't want to change PWD because search paths can be relative.

[belkadan]

The only thing this should affect is calculating the paths of output files.

[modocache]

OK, I think I understand. For my own clarification, though: is it possible that the original task was describing something like -working-directory? Because, as far as I've researched so far, the output file map doesn't effect input source file paths, but the original task description describes passing an input file tmp/myexe.swift as just myexe.swift. But output file maps are only used to specify paths to object files and other build products, not source files, right?

[belkadan]

I don't think so. Note that in the original description ../Sources/myexe.swift is still supposed to be resolved relative to the (shell's) current directory, not the output directory.

[modocache]

Oooh, I see! Yes, thanks, I think I was misreading it.