Support for Swift language and Clang modules for ninja generator.

Support for Swift language and Clang modules for ninja generator.

The main purpose of this patch is to add support for the Swift language.
It also adds support for Clang modules, since Swift language depends
directly on them.
There are also some fixes to support frameworks building for iOS.
However frameworks support for both Mac and iOS is not complete yet.
There is a feature called 'frameworks embedding'(that is copying some
parts of the framework into the app bundle) which is not implemented yet
for neither xcode generator nor ninja. It cannot be implemented as a
plain copy, since it implies codesigning framework for device builds.
I'm going to make another patch for this feature.

BUG=https://code.google.com/p/gyp/issues/detail?id=459

R=dpranke@chromium.org

[Dirk Pranke, 2015-06-09 02:07:26]

dpranke@chromium.org changed reviewers:
+ thakis@chromium.org

[Dirk Pranke, 2015-06-09 02:07:40]

thakis@ is a better reviewer for this than I am.

[Nico, 2015-06-10 01:09:18]

Super cool!

I'm on vacation tomorrow (Wednesday) and Friday. I probably won't have time to
look at this this week, but having support for this in gyp is great :-)

https://codereview.chromium.org/1160773005/diff/1/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/1160773005/diff/1/pylib/gyp/xcode_emulation.p...
pylib/gyp/xcode_emulation.py:490: cflags.append('-Xclang
-fmodule-implementation-of -Xclang ' +
-Xclang flags are considered clang-internal flags and aren't stable. Isn't there
some driver-level flag for this? If not, should there be one? (Does xcode do
this?)

[efimovmichael, 2015-07-22 14:46:04]

efimovmichael@yandex-team.ru changed reviewers:
- dpranke@chromium.org

[efimovmichael, 2015-07-22 14:46:05]

https://codereview.chromium.org/1160773005/diff/1/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/1160773005/diff/1/pylib/gyp/xcode_emulation.p...
pylib/gyp/xcode_emulation.py:490: cflags.append('-Xclang
-fmodule-implementation-of -Xclang ' +
On 2015/06/10 01:09:18, Nico (vacation Wed Jun 10) wrote:
> -Xclang flags are considered clang-internal flags and aren't stable. Isn't
there
> some driver-level flag for this? If not, should there be one? (Does xcode do
> this?)

I tried to copy all flags, which Xcode uses itself(6.3.1 version).
Some of them are probably internal to Xcode's version of clang and don't have
any documentation.
But I tested all flags used in this patch on both versions of clang: Xcode's
version and Chromium version(last one) and everything looks fine.
As for this flag, I found a reference to it's name in some public correspondence
here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140721/111034.html
I think, this flag is an alternative to the -fmodule-name flag from the official
clang documentation. 
Both of them deny importing module within Objective-C sources of this module(and
they probably do something else). As I see it, Apple's clang team were unhappy
with implementation of '-fmodule-name' and added their own. I tried using both
of them, they work on both Xcode's clang and Chromium's clang).
However, these flags produce different errors(when I'm trying to write @import
to my module inside my module), so they actually trigger different logic inside
clang.
In short, we can replace '-fmodule-implementation-of' with '-fmodule-name' but
we'll move away from Xcode's original compilation process.

[efimovmichael, 2015-09-08 09:22:26]

On 2015/07/22 14:46:05, efimovmichael wrote:
> https://codereview.chromium.org/1160773005/diff/1/pylib/gyp/xcode_emulation.py
> File pylib/gyp/xcode_emulation.py (right):
> 
>
https://codereview.chromium.org/1160773005/diff/1/pylib/gyp/xcode_emulation.p...
> pylib/gyp/xcode_emulation.py:490: cflags.append('-Xclang
> -fmodule-implementation-of -Xclang ' +
> On 2015/06/10 01:09:18, Nico (vacation Wed Jun 10) wrote:
> > -Xclang flags are considered clang-internal flags and aren't stable. Isn't
> there
> > some driver-level flag for this? If not, should there be one? (Does xcode do
> > this?)
> 
> I tried to copy all flags, which Xcode uses itself(6.3.1 version).
> Some of them are probably internal to Xcode's version of clang and don't have
> any documentation.
> But I tested all flags used in this patch on both versions of clang: Xcode's
> version and Chromium version(last one) and everything looks fine.
> As for this flag, I found a reference to it's name in some public
correspondence
> here:
>
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140721/111034.html
> I think, this flag is an alternative to the -fmodule-name flag from the
official
> clang documentation. 
> Both of them deny importing module within Objective-C sources of this
module(and
> they probably do something else). As I see it, Apple's clang team were unhappy
> with implementation of '-fmodule-name' and added their own. I tried using both
> of them, they work on both Xcode's clang and Chromium's clang).
> However, these flags produce different errors(when I'm trying to write @import
> to my module inside my module), so they actually trigger different logic
inside
> clang.
> In short, we can replace '-fmodule-implementation-of' with '-fmodule-name' but
> we'll move away from Xcode's original compilation process.

review please