...when interpreting. Otherwise, the script may depend on library X, which
depends on library Y, where library Y is a standard Swift library, located
in lib/swift/$PLATFORM/.
Finishes rdar://problem/23588774
Implementing this for the general case either requires duplicating the
existing environment, or modifying TaskQueue to support "extra environment"
settings. Since we don't actually have any use cases for this yet, I'm
leaving it unimplemented for now.
Rest of rdar://problem/23588774
That's DYLD_LIBRARY_PATH on OS X and LD_LIBRARY_PATH on Linux for -L,
and DYLD_FRAMEWORK_PATH on OS X for -F.
Note that this commit doesn't actually include the setenv calls yet, so an
end-to-end test is coming in the next commit.
Part of rdar://problem/23588774
This is groundwork for setting [DY]LD_LIBRARY_PATH ahead of time when
invoking the interpreter, which is rdar://problem/23588774. The next
commit will set up the appropriate variable and use -driver-print-jobs
to test it; the following commit will apply the environment variable
when running a job.
This makes it easier to make interpreter modes behave differently from
compilation modes. Obviously that's a trade-off, since the two modes also
share plenty, but given how few of the existing CompileJobAction checks had
to be modified for the new InterpretJobAction, I think this is the right
way to go.
Groundwork for setting [DY]LD_LIBRARY_PATH ahead of time when invoking the
interpreter, which is rdar://problem/23588774.
This reverts commit 58cfa27eb5.
We require at least clang-3.6 for C++14 build support but
Ubuntu 14.04's clang-3.6 package does not lay down the symlink
/usr/bin/clang++ -> /usr/bin/clang++-3.6. We will require a
clang++ alternatives entry or symlink when building for these
systems (see README.md).
In most Linux distributions, installing a clang package other than the
default unversioned one will not install a symlink from /usr/bin/clang++
-> /usr/bin/clang++-N-M, which can break builds with a not so great
diagnostic (a separate problem).
"ld" and "clang++" are hard-coded in the link job actions, so provide a
frontend flag, -linker-path, as a customization point for these.
rdar://problem/23537079
Deploying to older OSs requires linking in a compatibility library called
"arclite", but this library isn't open source and won't be distributed with
our open source downloads. Fall back to the version in Xcode.
The next step is to remove the local symlink used in builds, but I wanted to
handle that separately.
rdar://problem/23421436
For now, just error out at the end of the build if something was modified,
forcing a rebuild. The incremental logic should get that rebuild right.
We could automatically restart the rebuild, but that could lead to infinite
compilation if the user continues to edit an important file.
DerivedArgList has a pointer to the InputArgList it came from, so we can't
just std::move it around. Put most of the driver back the way it was, with
small changes to clarify ownership.
Swift SVN r31811
inside a swift ast section in an object file so it can be passed to the
linker. The driver automatically wraps merged swiftmodules iff the target
is ELF.
rdar://problem/22407666
Swift SVN r31641
The "Tool" abstraction wasn't buying us enough to deserve the added
complexity. Now a ToolChain turns Actions into Jobs, and every helper
tool is searched for relative to Swift first. Much simpler.
Swift SVN r31563
Previously we treated this the same as the inputs to the linker, but this
was problematic for a few reasons:
- Backend jobs don't produce
- .o inputs never produce .swiftmodule files (obviously).
So now we:
- explicitly track what can produce a swiftmodule
- don't run module merging if there's nothing to merge
- allow linking without a swiftmodule even under -g
Which gets us closer to being able to run the entire test suite with -g.
rdar://problem/22332569
Swift SVN r31376
This way they can be used from other projects, like LLDB. The downside
is we now have to make sure the header is included consistently in all
the places we care about, but I think in practice that won't be a problem,
especially not with tests.
rdar://problem/22240127
Swift SVN r31173
Normally we don't get here because the build record will be out of date,
but if we don't actually rebuild all the files we'll crash on the /next/
build.
Swift SVN r30889
Dependents of modified files are no longer rebuilt by default, only if it turns
out that file's interface has changed. There is a flag
-driver-always-rebuild-dependents to override this, but we expect it to only be
used for testing. (Most of the existing dependency tests pick up this option;
the two new tests have "interface-hash" in the name.)
This is the second half of ChrisW's work on interface hashing.
rdar://problem/15352929
Swift SVN r30478
Compute the hash of all interface tokens when parsing; write the
interface hash to the swiftdeps file, or if the -dump-interface-hash
option is passed to the frontend. This hash will be used in incremental
mode to determine whether a file's interface has changed, and therefore
whether dependent files need to be rebuilt in response to the change.
Committed on ChrisW's behalf while he gets his setup unborked.
rdar://problem/15352929
Swift SVN r30477
If file A extends a common type (say, Dictionary), but only adds new members,
other files using Dictionary don't need to be recompiled if they definitively
don't use those members. That should be working now.
Swift SVN r30286
- (depends|provides)-top-level for top-level names.
- (depends|provides)-nominal for access into nominal types.
- (depends|provides)-dynamic-lookup for @objc members available on AnyObject.
- depends-external for cross-module file-based dependencies.
No functionality change.
Swift SVN r30283
The parsing code should really be more forgiving anyway, but there's no reason
to even try to read the swiftdeps files if we're rebuilding everything anyway.
Swift SVN r30281
