Fwd: Proposal to allow building .swift file with gn

[Dirk Pranke]

Apologies for the cross-post, but some interesting discussion on how we might start to adopt Swift-based targets ...

-- Dirk

---------- Forwarded message ---------
From: Alfred Zien <zie...@yandex-team.ru>
Date: Wed, May 20, 2020 at 9:59 AM
Subject: Re: Proposal to allow building .swift file with gn
To: Takuto Ikuta <tik...@chromium.org>
Cc: Sylvain Defresne <sdef...@chromium.org>, gn-dev <gn-...@chromium.org>

I've actually prepared some draft implementation for this and was in progress to make some proposal too :)

We've supported swift in our project for about 2-3 years and we have 3 apps currently in app store built with gn, with extensive use of swift (10k+ .swift files, hundreds of modules). Some thoughts on proposal:

1. Although invoking frontend looks promising, as it looks like it will fit well in ninja/gn model, it is not usable in practice, we've abandoned that approach in favour of using swift-driver almost instantly. Disadvantages of using frontend directly:

  - Broken incremental compilation, as every change, even in implementation of private function will trigger recompilation of whole module and all dependant modules.

  - Parsing time grows quadratically, as every frontend invocation has to parse all files (this is fixed by batch mode in driver, that is hard to implement in gn).

  - There are actually 3 different compilation mods, supported in driver: incremental, whole-module and single-threaded whole-module. Although all of them can be achieved by frontend invocation manually, it is not trivial to do. Using driver, on the other hand, almost entirely eliminates the differences, with exception that single-threaded whole-module will output only one .o file per module.

  - Frontend API is considered as unstable and is not recommended for use by swift folks.

  - Frontend has a very hard time working with relative paths

Disadvantages of using swift-driver:

  - swift-driver needs special json file that contains dictionary that maps input files to output (object file, partial module, and some other files).

  - It is harder to explain in gn that tool, depending on mode, can output multiple or only one object files.

In my draft implementation I've created two tools actually, for incremental mode and for single-object mode. First generates output-file-map.json and expects one object file per input and second doesn't generate json and expects one .o file.

More on this here: https://github.com/apple/swift/blob/master/docs/Driver.md (hidden gem for those who trying to understand swift build model)

2. swift can export objc header file with objc-compatible public interface, that is essential feature for compatibility with objc. As it outputs from swift invocation, gn needs to know about that output, so support is needed on gn level.

3. module cache is actually not the desired way to propagate interfaces, it can be done more explicitly with -I flag with path where .swiftmodule is stored. This way it muuch more robust to compilation flakiness.

4. Does swift really needs special target type? As I understand, there is no problem with putting .swift files to source_set. Even thought compilation model is slightly different, in the end it's just old good .o files that can be linked.

-- Alfred

On 20 May 2020, at 16:59, Takuto Ikuta <tik...@chromium.org> wrote:

On Wed, May 20, 2020 at 10:30 PM Sylvain Defresne <sdef...@chromium.org> wrote:

You should now have permission to comment.

Yes, thank you.

 

Context is that Chrome on iOS team does not want to be painted in a corner if required iOS API are only made available in Swift in future version of the SDK, so we want to have the option to build .swift file and link them into an application without having to add support in a hurry.

-- Sylvain

On Wed, May 20, 2020 at 3:14 PM Takuto Ikuta <tik...@chromium.org> wrote:

Hi,

Will you give us comment permission?

Also I'm curious background of this proposal.

On Wed, May 20, 2020 at 9:58 PM Sylvain Defresne <sdef...@chromium.org> wrote:

Based on investigation on how .swift files can be built from command-line (see document), I suggest adding a new type of target to gn and two new tools to add support to build .swift files.

They would be used like this:

swift_module("foo") {   output_name = "Foo"  # Will be reused as the name of the module.   sources = [     "File1.swift",     "File2.swift",   ]   bridge_header = "Foo-Bridging-Header.h" } toolchain("ios_clang") {   tool("swift_compile") {     command = "swift -frontend -c -primary-file {{source}} -o {{output}} ..."     partial_module_output = "..."     outputs = [ "..." ]   }   tool("swift_merge") {     command = "swift -frontend -merge-modules ..."     module_output = "..."   } }

Regards,

-- Sylvain

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to gn-dev+un...@chromium.org.

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to gn-dev+un...@chromium.org.

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to gn-dev+un...@chromium.org.

--
To unsubscribe from this group and stop receiving emails from it, send an email to gn-dev+un...@chromium.org.

[Nico Weber]

Sylvain and I had talked about this a bit in the past. Note that this is hedging for critical (ie now SwiftUI) new APIs being only available only in Swift – and even if that happens I'd expect us to limit use of Swift to the smallest number of places we can get away with, since we try to not add dependencies on new languages for various reasons.

--
You received this message because you are subscribed to the Google Groups "build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to build+un...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/build/CAEoffTBM4nt99g7OkWXWwcuLxZrb%2BTs6n_X9J42_OCWcBXvV1w%40mail.gmail.com.

[Sylvain Defresne]

Yes. My intention with this proposal/discussion/change is to not have Chrome on iOS stuck in a place where an API we need to use is only available in Swift is revealed in the upcoming version of iOS while Swift is not supported by gn. I don't want to have to rush support in a fortnight because it is now critical. I would also expect the use of Swift to be quite limited even in that case (there is no interoperability with C++ so just the pain of using it should limit usage).

-- Sylvain