Update README.md #11463

KingOfBrian · 2017-08-14T23:55:11Z

I'm interested in improving the developer on boarding experience, so I took a stab at changing the README.md. I'm not sure if this change is cutting a bit too deep, but I wanted to roll back some of what I've learned about developing in Swift back into the README to help others get involved.

README.md changes:

Bring 'Contributing to Swift' up to the top. I think that information is really helpful to see first.
Move 'building documentation' to the bottom. Most people will just browse the raw files, and first timers may confuse this for actual language documentation.
Move CMake and Ninja install instructions to the bottom. 99% of people will just use a package manager.
Add disk space and time requirements to ensure that expectations are met. First time I built swift, I ran out of disk space 3 times!
Mention "Typical uses of 'build-script'" -- this is a lot more helpful than the wall of switches to new developers.
Present xcode and Ninja build options. I wasn't sure how to express the differences correctly and would love some more specific things to say. Previously only Xcode was presented as an option even though ninja is the recommended build system.
Brief mention of ninja incremental builds
Basic flow for running a test in Xcode
Add a section on build failures that re-emphasizes latest version of xcode. I see 1-2 emails a month on this to swift dev.
Link to DebuggingTheCompiler.rst -- I found this document way too late!

Testing.rst

Move rule on writing long tests into the section on writing tests
Mention that build-script will rebuild all targets, and that lit can be used to run tests directly
Move Cmake rules below lit rules. lit.py testing has been a lot more helpful than using CMake.

…ia package manager

slavapestov · 2017-08-14T23:59:33Z

README.md

 ### System Requirements

 macOS, Ubuntu Linux LTS, and the latest Ubuntu Linux release are the current
 supported host development operating systems.

-For macOS, you need [Xcode 9.0 beta 4](https://developer.apple.com/xcode/downloads/).
+To build for macOS, you always need the latest version of Xcode, currently
+[Xcode 9.0 beta 4](https://developer.apple.com/xcode/downloads/). You will


9.0 beta 5 is now out

Is someone going to keep this up to date? Could also link to developer.apple.com/downloads, although I believe that page is walled off behind an Apple ID login.

I didn't bump the version because I know there's an issue right now with beta 5 and AVFoundation. I think it's better to let this lie live till beta 6 / GM ;0

This is updated once swift is ready to be built with new Xcode, and ci.swift.org has been updated.

I think it'd be good to really make clear that the latest supported is beta 4. I have a lot of issues when I started because Swift wasn't compiling on beta 4 (and this doc said beta 3). I assumed it was all my fault 😬

slavapestov · 2017-08-15T00:01:45Z

Looks good, thanks!

slavapestov · 2017-08-15T00:01:49Z

@swift-ci Please smoke test

ZevEisenberg · 2017-08-15T00:23:39Z

README.md

-development environment. Options for doing things differently are
-discussed below.
+These instructions give the most direct path to a working Swift development
+environment. To build from source you will need 2gb of disk space for the


2gb → 2 GB, 20gb → 20 GB

rintaro · 2017-08-15T00:29:11Z

utils/build-script

@@ -1186,7 +1186,7 @@ Using option presets:
  using the name=value syntax on the command line.


-Any arguments not listed are forwarded directly to Swift's
+Any arguments not listed, or arguments after `--` are forwarded to Swift's


Actually, this is not true.
https://github.com/apple/swift/blob/ade67ca8994dbbb5d4754a06147c787eaa0d11f7/utils/swift_build_support/swift_build_support/migration.py#L33-L34
-- is simply ignored.

Good catch!

Yep. It used to be true, but we changed it once we decided to move build-script-impl into build-script. (That effort itself then ran into issues, but that's another story.)

ZevEisenberg · 2017-08-15T00:34:50Z

README.md


-    utils/build-script -x
+ - Select the ‘swift’ scheme
+ - Pull up the scheme editor (⌘+⇧+<)


The ⌘ symbol, and maybe the ⇧ symbol, won't render on Linux,. Might want to spell this as "Command-Shift-<", or as Command-Shift-, or Command-Shift-Comma. Or do it like Xcode does it: Command-<. There's no great answer here :\

I think I'll leave the formatting for now. Since it's Xcode specific, not formatting on Linux isn't the worst.

Nitpick: technically, this should be written "⇧⌘<" if you're going to use symbols. (Citation: me)

milseman

Looking great!

milseman · 2017-08-15T01:20:53Z

README.md


-**[MacPorts](https://macports.org)**
+    utils/build-script -R --debug-swift


This will also build LLVM, Clang, and the Swift standard library with optimizations and asserts, but no debug symbols. Worth pointing out e.g. utils/build-script -r --debug-swift-stdlib, for people wanting to work on the standard library but want a optimized+asserts compiler.

I think a better recommendation for beginners is utils/build-script -r, as a debug compiler or standard library is very slow, and I would expect many beginners initially to want something fast more than the ability to break in a debugger meaningfully. ^^^ This is complete opinion, feel free to ignore.

Oh, also, I always specify a -j<n> so that my machine remains responsive. Might be worth a mention. Similarly for the ninja and lit sections. Oddly enough, I don't think build-script passes it off the lit correctly...

utils/build-script -r also disables asserts in the compiler, which is not something you want when hacking on the compiler itself.

TBH, I wonder if it would be better to have the longer more verbose names in the getting started guide, e.g.: --release-debuginfo and --release. IMO this will be easier for new contributors to remember since it isn't a random flag. Just my 2 cents.

@slavapestov nope, utils/build-script -r builds with assertions enabled. You have to pass --no-assertions to turn them off.

milseman · 2017-08-15T01:23:24Z

README.md

-A basic command to build Swift with optimizations and run basic tests with
-Ninja:
+    cd ${SWIFT_BUILD_ROOT}
+    ninja swift


This is very compelling for people who want to rapidly iterate on the compiler without having to build the standard library (which takes a while). Worth calling out explicitly.

For anyone wanting to work on the standard library, ninja is usually just fine as that can build overlays in parallel and skips the benchmarks. Speaking of which, not sure if you want to call out the benchmarks targets.

milseman · 2017-08-15T01:25:11Z

README.md

+
+Make sure you are using the latest release of Xcode to build, including Betas.
+If you have changed Xcode versions but still encounter errors that appear to
+be related to the Xcode version, try passing `-- --rebuild` to `build-script`.


Might be worth covering --reconfigure. There's no need for a total recompilation of all C++ (Clang, LLVM, Swift compiler) just for a newer Xcode.

milseman · 2017-08-15T01:26:44Z

docs/Testing.md

-LLVM's lit.py script directly. For example:
+Using `lit.py` directly can provide more control and faster feedback to your
+development cycle. To invoke LLVM's `lit.py` script directly, it must be
+configured to use your local build directory. For example:

 ```
    % ${LLVM_SOURCE_ROOT}/utils/lit/lit.py -sv ${SWIFT_BUILD_ROOT}/test-iphonesimulator-i386/Parse/


This is worth hyperlinking to from the GettingStarted guide, as it's one of the first things I tell new contributors once they're building and running. Otherwise, it's rather buried.

rintaro · 2017-08-15T05:37:00Z

README.md


-Contributions to Swift are welcomed and encouraged! Please see the
-[Contributing to Swift guide](https://swift.org/contributing/).
+See [docs/DebuggingTheCompiler.md](docs/DebuggingTheCompiler.md).


This document is still .rst, not .md

marcelofabri · 2017-08-15T15:56:33Z

README.md

-work with other SDKs, you'll need to create a second build using Ninja.
+### Build Failures
+
+Make sure you are using the latest release of Xcode to build, including Betas.


this might not be true, as discussed in "System Requirements"

marcelofabri · 2017-08-15T15:58:42Z

README.md

-**[Homebrew](https://brew.sh/)**
+The Xcode IDE can be used to edit the Swift source code, but it is not currently
+fully supported as a build environment for SDKs other than macOS. If you need to
+work with other SDKs, you'll need to create a second build using Ninja.


One of the doubts that I had when starting was how I could run the tests with Xcode. Apparently, there's no way. I think that should also be explicitly said here.

You can run the tests by building the check-swift target.

gottesmm · 2017-08-15T17:36:45Z

README.md


-**Via HTTPS**
+    utils/build-script -r -t


For example, here, it would be clearer if you said:

./utils/build-script --release-debuginfo --assertions --test

jrose-apple · 2017-08-15T23:38:37Z

README.md

+
+    sudo port install cmake ninja
+
+Instructions for installing CMake and Ninja directly can be found [here](#build-dependencies)


Nitpick: maybe change "here" to "below"?

jrose-apple

Thanks for taking the time to look through and improve this, Brian!

jrose-apple · 2017-08-15T23:40:19Z

README.md

+These instructions give the most direct path to a working Swiftdevelopment
+environment. To build from source you will need 2gb of disk space for the
+source code and over 20gb of disk space for the build artifacts. The first
+build will take multiple hours, but incremental builds will finish much faster.


I don't think any build takes "multiple hours", even on my old MacBook Air, unless you build an all-debug compiler and a release standard library. "may take more than an hour", perhaps?

Maybe it just feels like hours sometimes. I'm going to run a few builds out of my own curiosity, but downgraded this to a "can".

So I have a Mid-2015 MBP 2.5 GHz i7, and running -x took 3 hours, and just a debug compiler (-R --debug-swift) took 70 minutes. So I think this is pretty accurate. My intent with adding this information was to set expectations, not an official benchmark.

jrose-apple · 2017-08-15T23:40:40Z

README.md

@@ -108,7 +108,7 @@ options such as building a Swift-compatible LLDB, building the Swift Package
 Manager, building for iOS, running tests after builds, and more. It also
 supports presets, which you can define for common combinations of build options.

-To find out more:
+View the inline help to find out more, in particular the section "Typical uses"


Nitpick: Missing a colon.

jrose-apple · 2017-08-15T23:41:19Z

utils/build-script

@@ -1186,7 +1186,7 @@ Using option presets:
  using the name=value syntax on the command line.


-Any arguments not listed are forwarded directly to Swift's
+Any arguments not listed, or arguments after `--` are forwarded to Swift's


Yep. It used to be true, but we changed it once we decided to move build-script-impl into build-script. (That effort itself then ran into issues, but that's another story.)

jrose-apple · 2017-08-15T23:42:57Z

README.md


-    utils/build-script -x
+ - Select the ‘swift’ scheme
+ - Pull up the scheme editor (⌘+⇧+<)


Nitpick: technically, this should be written "⇧⌘<" if you're going to use symbols. (Citation: me)

jrose-apple · 2017-08-15T23:43:02Z

README.md

+auto-create a *lot* of schemes for all of the available targets. A common debug
+flow would involve:
+
+ - Select the ‘swift’ scheme


Nitpick: smart quotes?

jrose-apple · 2017-08-15T23:45:35Z

README.md

+ - Select the ‘Arguments’ tab and click the ‘+’
+ - Add the command line options
+ - Close the scheme editor
+ - Build and run


I'll suggest an alternate workflow: rather than messing with the command line options in the scheme editor, change the scheme to "Wait for executable to be launched", then run the build product in Terminal. Do you think that's better or worse for new people?

I stole this workflow from a recent swift-dev post, and I think including both is a good idea. Thanks!

jrose-apple · 2017-08-15T23:47:36Z

README.md

@@ -21,6 +21,8 @@ features like flow control, data structures, and functions, with high-level
 constructs like objects, protocols, closures, and generics. Swift embraces
 modules, eliminating the need for headers and the code duplication they entail.

+To learn more about the programming language, visit [swift.org](https://swift.org/documentation/)


Missing a period.

…ILD_ROOT means something else in the build script.

KingOfBrian · 2017-08-16T00:48:54Z

Hey folks, thanks for all the feedback! I believe I've addressed everyones comments, but a quick double check would be great. In particular

Added very specific language about Xcode version, and included a link to ci.swift.org.
I'm not sure my descriptions in the Ninja section are great. If you think you have better language for anything feel free to wordsmith!

jrose-apple · 2017-08-16T00:48:40Z

README.md


    utils/build-script -h

 A basic command to build Swift with optimizations and run basic tests with
 Ninja:

-    utils/build-script -r -t
+    utils/build-script --release --test


Ah, IIRC -r is --release-debuginfo, not just --release. (That's -R.) I know you make that distinction below, but for the very first thing people build they probably want the debug info and assertions.

jrose-apple · 2017-08-16T00:51:28Z

README.md

- - Pull up the scheme editor (⌘+⇧+<)
- - Select the ‘Arguments’ tab and click the ‘+’
+ - Select the 'swift' scheme
+ - Pull up the scheme editor (⌘⇧<)


Extra nitpick: Command comes first when spelled out, but last in symbol form.

gottesmm

Some comments related to assertions and some questions.

gottesmm · 2017-08-16T00:55:50Z

README.md


-**Via HTTPS**
+    utils/build-script --release --test


The most basic build-script that people should use for new people IMO is:

./utils/build-script --release-debuginfo --assertions --test

You really want the --assertions.

My thought with this build (Not in the "Development Environment" section), was that it would be a release capable build.

Maybe specify that? It seems like you are suggesting that this is the most basic build that people use.

I strongly recommend building with assertions for both compiler and stdlib. Only disable for benchmarking and perf tuning (or release validation, which is out of scope for most contributors).

gottesmm · 2017-08-16T00:57:09Z

README.md


-    sudo port install cmake ninja
+    utils/build-script --release


Again, I would change this to --release-debuginfo --assertions. In my experience assertions/debug info do not hurt compile time /that/ much and are really useful while developing. The debuginfo is useful since it will improve the ability of the new person to get better diagnostics when failures happen IIRC. But maybe my memory is wrong. The assertions though I would definitely consider adding.

gottesmm · 2017-08-16T00:58:55Z

README.md

-options such as building a Swift-compatible LLDB, building the Swift Package
-Manager, building for iOS, running tests after builds, and more. It also
-supports presets, which you can define for common combinations of build options.
+    utils/build-script --release-debuginfo --debug-swift


Again --assertions.

I would also mention here that --debug-swift does not touch the stdlib. So for a fully debug experience with a release LLVM, you need to do:

./utils/build-script --release-debuginfo --debug-swift --debug-swift-stdlib.

Additionally, as an advanced feature, there is an option that you can use to compile just the typechecker in release. This is useful in reducing compile time if one only wants to debug /post-typechecking/. The option is:

--force-optimized-typechecker.

That being said, I am not 100% sure if this option is appropriate for this guide.

gottesmm · 2017-08-16T01:00:54Z

README.md


-    utils/build-script -h
+    utils/build-script --release --debug-swift-stdlib


You need assertions here. This will compile the stdlib without assertions IIRC.

gottesmm · 2017-08-16T01:01:33Z

README.md

+This command will rebuild the stdlib and skip the `benchmarks` target. This
+is great for developers interested in working on the standard library.
+
+It is always a good idea to do a full build after using `update-checkout`.


Question. Was the notion of a scheme used in update-checkout confusing to you? Do you think it needs to be explained?

People who stay on the master branch don't need to know about schemes.

Sure. That is why I was unsure.

KingOfBrian · 2017-08-16T13:49:02Z

I don't think --assertions is needed @gottesmm. I didn't add --assertions initially because @milseman mentioned that they are enabled by default, and I confirmed this in a few places. If I run:

./swift/utils/build-script --release-debuginfo --debug-swift

The build directory created is Ninja-RelWithDebInfoAssert+swift-DebugAssert, which looks correct. The build-script also confirms this intention:

    # Assertions are enabled by default.
    if args.assertions is None:
        args.assertions = True

That said, I'm new around here and may be missing something!

gottesmm · 2017-08-16T16:21:40Z

If it is on by default, ok. I guess I always pass it in for explicitness.

deyton · 2017-08-16T22:22:33Z

README.md



 ### System Requirements

 macOS, Ubuntu Linux LTS, and the latest Ubuntu Linux release are the current
 supported host development operating systems.

-For macOS, you need [Xcode 9.0 beta 4](https://developer.apple.com/xcode/downloads/).
+<a name="xcode"></a>


Formatting nitpick: I think this would be a bit clearer with a #### macOS header to go balance with #### Linux below. Or maybe remove the Linux header and just rely on the paragraph separation of sections.

milseman

LGTM. Thank you for this effort!

…eful.

KingOfBrian · 2017-08-18T00:47:37Z

Hey @milseman -- I pushed up a few more changes after your approval. It'd be good to get another scan to make sure it still looks good.

gottesmm

Two small suggestions that add clarity.

gottesmm · 2017-08-18T16:14:18Z

README.md

-discussed below.
+These instructions give the most direct path to a working Swift development
+environment. To build from source you will need 2 GB of disk space for the
+source code and over 20 GB of disk space for the build artifacts. The first


The first build => A clean build

gottesmm · 2017-08-18T16:16:07Z

README.md


-#### Install via third-party packaging tool (macOS only)
+This will only build the compiler, and it will not build the standard library.


This makes it sound like you will not build the standard library rather than what will happen (you will build the stdlib but you will suffer through building an optimized stdlib with a debug compiler).

Interesting, given your phrasing above in (), would you just recommend using both --debug-swift --debug-swift-stdlib?

No. It depends on what you are doing. For instance, if you are working on optimization passes, you definitely want a release stdlib. But if you do not care about optimizations, not using a debug stdlib will be significantly faster.

I strongly recommend only using a debug build for the portion that you will be tightly iterating and debugging on. Otherwise even just basic things like testing or building the stdlib itself take way too long.

Ok, this is super helpful! I updated the section to describe these switches as a performance consideration rather than the over-arching guidance I was specifying before.

milseman

Just some clarifications on compiler vs project, and a suggestion to highlight the alternatives over the global debug config

milseman · 2017-08-19T00:13:23Z

README.md


-**Via HTTPS**
+If you are interested in debugging the compiler, run:


This isn't just the compiler, but the whole Swift project: Clang, Swift frontend, LLVM, standard library, runtimes, and all. I would move this section lower.

Straw man: """
When working on a specific area of the project, it helps to build the area you're working on in a debug configuration while building the rest of the project with optimizations. Below are some examples of using debug variants:

utils/build-script --release-debuginfo --debug-swift # Swift frontend built in debug utils/build-script --release-debuginfo --debug-swift-stdlib # Standard library built in debug utils/build-script --release-debuginfo --debug-swift --force-optimized-typechecker # Swift frontend sans type checker built in debug

If you want to build the entire project in debug, which will produce a considerably slower compiler and standard library, you can run:

utils/build-script --debug

"""

Great, I like that direction a lot better @milseman ! I polished up the phrasing a touch and pushed up a change.

milseman · 2017-08-21T20:24:45Z

This looks awesome to me! I think further tweaking can be in a different PR. I want to get all this goodness in front of new contributor's eyes as soon as we can.

milseman · 2017-08-21T20:24:56Z

@swift-ci please smoke test

Brian King added 11 commits August 14, 2017 18:54

Swap the documentation and getting started sections

416db97

Emphasize the latest version of Xcode, and installing cmake / ninja v…

b9cf932

…ia package manager

Set disk space and time expectations

7010e13

Encourage people to view the 'Typical Uses' of build-script

bb96c62

Move advanced usage note about into the build script help.

584640e

Expand options on building Swift

e0d5319

Add a link to debugging the compiler

1ce2948

Move note on writing long tests into the section on writing tests

22fc53c

Emphasize lit testing

797c093

Add a link to swift.org documentation

d078458

Fix a typo, clarify the documentation being built.

0791573

KingOfBrian changed the title ~~Update READM.md~~ Update README.md Aug 14, 2017

slavapestov reviewed Aug 14, 2017

View reviewed changes

ZevEisenberg reviewed Aug 15, 2017

View reviewed changes

rintaro reviewed Aug 15, 2017

View reviewed changes

ZevEisenberg reviewed Aug 15, 2017

View reviewed changes

milseman reviewed Aug 15, 2017

View reviewed changes

rintaro reviewed Aug 15, 2017

View reviewed changes

Remove comment about arguments after

4a4d7d0

marcelofabri reviewed Aug 15, 2017

View reviewed changes

gottesmm reviewed Aug 15, 2017

View reviewed changes

Brian King added 2 commits August 15, 2017 18:58

Format GB

ac467c3

Update the language for the required version of Xcode.

4233ad6

jrose-apple reviewed Aug 15, 2017

View reviewed changes

Brian King added 2 commits August 15, 2017 20:30

Update best practices for building.

21fcf39

Change from SWIFT_BUILD_ROOT to SWIFT_BUILD_DIR in examples. SWIFT_BU…

49bb53a

…ILD_ROOT means something else in the build script.

Brian King added 2 commits August 15, 2017 20:38

Tweak the language about benchmarks.

3865086

Add a '.'

0a350a8

jrose-apple reviewed Aug 16, 2017

View reviewed changes

gottesmm reviewed Aug 16, 2017

View reviewed changes

deyton reviewed Aug 16, 2017

View reviewed changes

Add macOS header

661d9d9

milseman approved these changes Aug 17, 2017

View reviewed changes

Brian King added 4 commits August 17, 2017 20:39

Remove day-to-day language.

28de02e

Remove note on the benchmarks target. Not enough information to be us…

aa1dad4

…eful.

Improve language around presets

a5b85f6

Improve presentation of build-script build options.

ebb0b19

Fix a flag description

f0bb6c4

gottesmm reviewed Aug 18, 2017

View reviewed changes

Brian King added 2 commits August 18, 2017 16:29

Restructure the Building Swift section

115f288

Fix capitalization and grammar

37857af

milseman reviewed Aug 19, 2017

View reviewed changes

Rephrase build-script usage to encourage a debug variant.

bc4a167

gottesmm merged commit 6a6efd9 into swiftlang:master Aug 21, 2017

KingOfBrian deleted the documentation/DeveloperOnboarding branch August 21, 2017 23:36


		[MacPorts](https://macports.org)
		utils/build-script -R --debug-swift


		sudo port install cmake ninja

		Instructions for installing CMake and Ninja directly can be found [here](#build-dependencies)


		utils/build-script -h
		utils/build-script --release --debug-swift-stdlib


		#### Install via third-party packaging tool (macOS only)
		This will only build the compiler, and it will not build the standard library.


		Via HTTPS
		If you are interested in debugging the compiler, run:

Update README.md #11463

Update README.md #11463

Conversation

KingOfBrian commented Aug 14, 2017

README.md changes:

Testing.rst

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shahmishal Aug 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

slavapestov commented Aug 15, 2017

slavapestov commented Aug 15, 2017

Choose a reason for hiding this comment

rintaro Aug 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

milseman left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

milseman Aug 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jrose-apple left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KingOfBrian Aug 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KingOfBrian commented Aug 16, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gottesmm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KingOfBrian commented Aug 16, 2017

gottesmm commented Aug 16, 2017

Choose a reason for hiding this comment

milseman left a comment

Choose a reason for hiding this comment

KingOfBrian commented Aug 18, 2017

gottesmm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shahmishal Aug 15, 2017 •

edited

Loading

rintaro Aug 15, 2017 •

edited

Loading

milseman Aug 15, 2017 •

edited

Loading

KingOfBrian Aug 16, 2017 •

edited

Loading