Beginner's questions about building Swift from source etc.


(Jens Persson) #1

Hi all,

First of all, sorry for not being able to formulate these presumably basic
questions in a better/shorter way.

Background: We're working on an app that will benefit greatly from Swift's
ability to generate optimized code from relatively high level abstractions.

I've successfully compiled Swift from sources and observed some significant
improvements in the optimizer (for details see the following forum thread,
especially edit1 and edit2 of this post:
https://forums.developer.apple.com/thread/27204#93327
).

Now I'd like to be able to use Swift built from sources from within Xcode
(or at least have some way of using it with code completion and probably
swiftpm), but I haven't been able to find information on how to do that.

Here's my journey so far:

1. Read the main swift repos readme.

2. Cloned the 9 repositories listed there (for read-only access).

3. Built using:
    swift/utils/build-script -R --no-assertions --no-swift-stdlib-assertions
    (Found out about the no-assert-flags through Twitter. Without them, the
resulting compiler compiled binaries that were very slow.)

3. Compiled my "performance critical" test code like this:
    xcrun /blabla/build/Ninja-Release/swift-macosx-x86_64/bin/swift
-Ounchecked -gnone -whole-module-optimization main.swift
    (My first try was without xcrun, but then it would complain about "no
such module". So I asked Twitter and got the info about using xcrun.)

4. Noted significant improvements in what the optimizer was able to do with
my test code (compared to when compiling it with Xcode 7.2. The
compiled-from-sources-compiler produced 340 times faster code. See details
in the above forum thread.)

5. Feeling happy. Can't wait until this gets into an Xcode GM.

6. Wish I knew more about how to build Swift from sources, so I could make
my workflow more convenient, ie switching between compiling with
Swift-built-from-sources, Xcode and Xcode-beta. Eg:

- Is there a way to use the built-from-sources-version of Swift from within
Xcode (can I build a toolchain or something)?

- How do I build and use the package manager (swiftpm)? It doesn't seem to
get built when I build everything(?) using the build-script as described
above.

- Can I use any of the build-presets for this, and if so will it use the
--no-assertions and --no-swift-stdlib-assertions options?

My goal is to be able to have a convenient way of being able to write and
compile my (performance critical) code using, switching between and
comparing, the three different Swift versions in current
Xcode (GM),
Xcode-beta and
built-from-source.

Are the answers to these (and similar) questions plain to see in some
documentation somewhere or do I have to dig around in various scripts etc
and try to figure things out?

Thanks,
/Jens


(Jordan Rose) #2

Looks like Mish Awadah has an answer on a later thread:

Here’s what I’ve done in the past to build a toolchain using the build script.

function build_osx_package() {

   YEAR=$(date +"%Y")
   MONTH=$(date +"%m")
   DAY=$(date +"%d")
   TOOLCHAIN_VERSION="swift-SNAPSHOT-${YEAR}-${MONTH}-${DAY}-a"
   ARCHIVE_DIR="${TOOLCHAIN_VERSION}-${BUILD_NUMBER}"
   ARCHIVE="${TOOLCHAIN_VERSION}-osx.tar.gz"
   SYM_ARCHIVE="${TOOLCHAIN_VERSION}-osx-symbols.tar.gz"
   BUNDLE_IDENTIFIER="org.swift.${YEAR}${MONTH}${DAY}"
   DISPLAY_NAME="Swift Development Snapshot"
   TOOLCHAIN_NAME="${TOOLCHAIN_VERSION}"

   SWIFT_SOURCE_ROOT="${SRC_DIR}"
   SWIFT_BUILD_ROOT="${SRC_DIR}/build"
   SWIFT_INSTALLABLE_PACKAGE="${SRC_DIR}/${ARCHIVE}"
   SWIFT_INSTALL_DIR="${SRC_DIR}/swift-nightly-install"
   SWIFT_INSTALL_SYMROOT="${SRC_DIR}/swift-nightly-symroot"
   SWIFT_TOOLCHAIN_DIR="/Applications/Xcode.app/Contents/Developer/Toolchains/${TOOLCHAIN_NAME}.xctoolchain"
   SYMBOLS_PACKAGE="${SRC_DIR}/${SYM_ARCHIVE}"

   ./swift/utils/build-script --preset="buildbot_osx_package" install_destdir="${SWIFT_INSTALL_DIR}" installable_package="${SWIFT_INSTALLABLE_PACKAGE}" install_toolchain_dir="${SWIFT_TOOLCHAIN_DIR}" install_symroot="${SWIFT_INSTALL_SYMROOT}" symbols_package="${SYMBOLS_PACKAGE}" darwin_toolchain_bundle_identifier="${BUNDLE_IDENTIFIER}" darwin_toolchain_display_name="${DISPLAY_NAME}" darwin_toolchain_xctoolchain_name="${TOOLCHAIN_NAME}" darwin_toolchain_version="${TOOLCHAIN_VERSION}"
}

I'm not sure if this is the easiest way, but it will give you a toolchain. Hope that helps.

Jordan

P.S. I (still) don't know anything about this myself, but I've CCed Mish for further toolchain questions.

···

On Dec 9, 2015, at 14:22, Jens Persson via swift-dev <swift-dev@swift.org> wrote:

Hi all,

First of all, sorry for not being able to formulate these presumably basic questions in a better/shorter way.

Background: We're working on an app that will benefit greatly from Swift's ability to generate optimized code from relatively high level abstractions.

I've successfully compiled Swift from sources and observed some significant improvements in the optimizer (for details see the following forum thread, especially edit1 and edit2 of this post:
https://forums.developer.apple.com/thread/27204#93327
).

Now I'd like to be able to use Swift built from sources from within Xcode (or at least have some way of using it with code completion and probably swiftpm), but I haven't been able to find information on how to do that.

Here's my journey so far:

1. Read the main swift repos readme.

2. Cloned the 9 repositories listed there (for read-only access).

3. Built using:
    swift/utils/build-script -R --no-assertions --no-swift-stdlib-assertions
    (Found out about the no-assert-flags through Twitter. Without them, the resulting compiler compiled binaries that were very slow.)

3. Compiled my "performance critical" test code like this:
    xcrun /blabla/build/Ninja-Release/swift-macosx-x86_64/bin/swift -Ounchecked -gnone -whole-module-optimization main.swift
    (My first try was without xcrun, but then it would complain about "no such module". So I asked Twitter and got the info about using xcrun.)

4. Noted significant improvements in what the optimizer was able to do with my test code (compared to when compiling it with Xcode 7.2. The compiled-from-sources-compiler produced 340 times faster code. See details in the above forum thread.)

5. Feeling happy. Can't wait until this gets into an Xcode GM.

6. Wish I knew more about how to build Swift from sources, so I could make my workflow more convenient, ie switching between compiling with Swift-built-from-sources, Xcode and Xcode-beta. Eg:

- Is there a way to use the built-from-sources-version of Swift from within Xcode (can I build a toolchain or something)?

- How do I build and use the package manager (swiftpm)? It doesn't seem to get built when I build everything(?) using the build-script as described above.

- Can I use any of the build-presets for this, and if so will it use the --no-assertions and --no-swift-stdlib-assertions options?

My goal is to be able to have a convenient way of being able to write and compile my (performance critical) code using, switching between and comparing, the three different Swift versions in current
Xcode (GM),
Xcode-beta and
built-from-source.

Are the answers to these (and similar) questions plain to see in some documentation somewhere or do I have to dig around in various scripts etc and try to figure things out?

Thanks,
/Jens

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Dmitri Gribenko) #3

Just wanted to emphasize that the package presets is the only way you
should be building Swift for any production use (either on Linux or OS X).

If you are trying to port Swift to some platform where existing presets
don't work, feel free to ask us on swift.org mailing lists. If you want to
make a preset for production use from scratch, I strongly recommend reading
existing packaging presets and understanding what each flag does (not just
the description).

What happened in your build is that the standard library was built with
assertions. This is the right thing for development, but wrong for
production. Since production build process will be complex no matter what,
we decided to optimize build-script interface for local development.

Dmitri

···

On Wed, Dec 9, 2015 at 5:54 PM, Jordan Rose via swift-dev < swift-dev@swift.org> wrote:

Looks like Mish Awadah has an answer on a later thread:

   ./swift/utils/build-script --preset="buildbot_osx_package"
install_destdir="${SWIFT_INSTALL_DIR}"
installable_package="${SWIFT_INSTALLABLE_PACKAGE}"
install_toolchain_dir="${SWIFT_TOOLCHAIN_DIR}"
install_symroot="${SWIFT_INSTALL_SYMROOT}"
symbols_package="${SYMBOLS_PACKAGE}"
darwin_toolchain_bundle_identifier="${BUNDLE_IDENTIFIER}"
darwin_toolchain_display_name="${DISPLAY_NAME}"
darwin_toolchain_xctoolchain_name="${TOOLCHAIN_NAME}"
darwin_toolchain_version="${TOOLCHAIN_VERSION}"
}

Thanks, Jordan!

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Adrian Prantl) #4

Hi all,

First of all, sorry for not being able to formulate these presumably basic questions in a better/shorter way.

Background: We're working on an app that will benefit greatly from Swift's ability to generate optimized code from relatively high level abstractions.

I've successfully compiled Swift from sources and observed some significant improvements in the optimizer (for details see the following forum thread, especially edit1 and edit2 of this post:
https://forums.developer.apple.com/thread/27204#93327
).

Now I'd like to be able to use Swift built from sources from within Xcode (or at least have some way of using it with code completion and probably swiftpm), but I haven't been able to find information on how to do that.

Here's my journey so far:

1. Read the main swift repos readme.

2. Cloned the 9 repositories listed there (for read-only access).

3. Built using:
    swift/utils/build-script -R --no-assertions --no-swift-stdlib-assertions
    (Found out about the no-assert-flags through Twitter. Without them, the resulting compiler compiled binaries that were very slow.)

3. Compiled my "performance critical" test code like this:
    xcrun /blabla/build/Ninja-Release/swift-macosx-x86_64/bin/swift -Ounchecked -gnone -whole-module-optimization main.swift

Note that none of the options starting with “-g" have any effect on the generated code and thus won’t affect the performance of the resulting executable.

-- adrian

···

On Dec 9, 2015, at 2:22 PM, Jens Persson via swift-dev <swift-dev@swift.org> wrote:

    (My first try was without xcrun, but then it would complain about "no such module". So I asked Twitter and got the info about using xcrun.)

4. Noted significant improvements in what the optimizer was able to do with my test code (compared to when compiling it with Xcode 7.2. The compiled-from-sources-compiler produced 340 times faster code. See details in the above forum thread.)

5. Feeling happy. Can't wait until this gets into an Xcode GM.

6. Wish I knew more about how to build Swift from sources, so I could make my workflow more convenient, ie switching between compiling with Swift-built-from-sources, Xcode and Xcode-beta. Eg:

- Is there a way to use the built-from-sources-version of Swift from within Xcode (can I build a toolchain or something)?

- How do I build and use the package manager (swiftpm)? It doesn't seem to get built when I build everything(?) using the build-script as described above.

- Can I use any of the build-presets for this, and if so will it use the --no-assertions and --no-swift-stdlib-assertions options?

My goal is to be able to have a convenient way of being able to write and compile my (performance critical) code using, switching between and comparing, the three different Swift versions in current
Xcode (GM),
Xcode-beta and
built-from-source.

Are the answers to these (and similar) questions plain to see in some documentation somewhere or do I have to dig around in various scripts etc and try to figure things out?

Thanks,
/Jens

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Jens Persson) #5

Thanks!
I tried the above to compile with the buildbot_osx_package preset. It kind
of worked, but it failed while performing the tests.
(TEST 'Swift :: Driver/Dependencies/bindings-build-record.swift' FAILED)
So, I got a working swiftc etc but no package or toolchain or anything (at
least as far as I could see).

However, trying out the resulting swiftc shows that it is slow, ie the
buildbot_osx_package preset did not imply --no-assertions
--no-swift-stdlib-assertions.

Since I am interesting in observing the latest improvements in the
optimizer, I wonder if any of the existing presets will build the std lib
without assertions, and produce an installable package (which will give me
toolchain)?

As previously stated, my goal is simply(?) to be able to use / try out
these in parallell:
1. Xcode.app
2. Xcode-beta.app
3. built-from-sources

/Jens

···

On Thu, Dec 10, 2015 at 3:31 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Wed, Dec 9, 2015 at 5:54 PM, Jordan Rose via swift-dev < > swift-dev@swift.org> wrote:

Looks like Mish Awadah has an answer on a later thread:

   ./swift/utils/build-script --preset="buildbot_osx_package"
install_destdir="${SWIFT_INSTALL_DIR}"
installable_package="${SWIFT_INSTALLABLE_PACKAGE}"
install_toolchain_dir="${SWIFT_TOOLCHAIN_DIR}"
install_symroot="${SWIFT_INSTALL_SYMROOT}"
symbols_package="${SYMBOLS_PACKAGE}"
darwin_toolchain_bundle_identifier="${BUNDLE_IDENTIFIER}"
darwin_toolchain_display_name="${DISPLAY_NAME}"
darwin_toolchain_xctoolchain_name="${TOOLCHAIN_NAME}"
darwin_toolchain_version="${TOOLCHAIN_VERSION}"
}

Thanks, Jordan!

Just wanted to emphasize that the package presets is the only way you
should be building Swift for any production use (either on Linux or OS X).

If you are trying to port Swift to some platform where existing presets
don't work, feel free to ask us on swift.org mailing lists. If you want
to make a preset for production use from scratch, I strongly recommend
reading existing packaging presets and understanding what each flag does
(not just the description).

What happened in your build is that the standard library was built with
assertions. This is the right thing for development, but wrong for
production. Since production build process will be complex no matter what,
we decided to optimize build-script interface for local development.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com


(Jordan Rose) #6

*sigh* I'm not sure what's up with this test. Someone already filed an SR about it, SR-31 <https://bugs.swift.org/browse/SR-31>. It should be safe to disable it locally by adding a line like this:

// REQUIRES: disabled

Jordan

···

On Dec 10, 2015, at 7:41 , Jens Persson <jens@bitcycle.com> wrote:

I tried the above to compile with the buildbot_osx_package preset. It kind of worked, but it failed while performing the tests.
(TEST 'Swift :: Driver/Dependencies/bindings-build-record.swift' FAILED)


(Dmitri Gribenko) #7

Jens,

I think you found an issue in our presets. I filed
https://bugs.swift.org/browse/SR-180 Here, we have an incorrect
workaround that causes this issue:

[preset: mixin_lightweight_assertions]
assertions

# FIXME: This should be:
# no-assertions
# swift-assertions
# ... but our tests are expecting assertions to be either on or off everywhere.

I think this hacky patch should get you unblocked (untested!):

···

On Thu, Dec 10, 2015 at 7:41 AM, Jens Persson <jens@bitcycle.com> wrote:

Thanks!
I tried the above to compile with the buildbot_osx_package preset. It kind
of worked, but it failed while performing the tests.
(TEST 'Swift :: Driver/Dependencies/bindings-build-record.swift' FAILED)
So, I got a working swiftc etc but no package or toolchain or anything (at
least as far as I could see).

However, trying out the resulting swiftc shows that it is slow, ie the
buildbot_osx_package preset did not imply --no-assertions
--no-swift-stdlib-assertions.

-------------------------------------------------------------------------------------
diff --git a/utils/build-presets.ini b/utils/build-presets.ini
index 6dc6d24..1ab441f 100644
--- a/utils/build-presets.ini
+++ b/utils/build-presets.ini
@@ -462,12 +462,8 @@ swift-runtime-enable-leak-checker=1
# A mixin that enables 'lightweight' assertions that don't slow down the
# compiler significantly.
[preset: mixin_lightweight_assertions]
-assertions
-
-# FIXME: This should be:
-# no-assertions
-# swift-assertions
-# ... but our tests are expecting assertions to be either on or off everywhere.
+no-assertions
+swift-assertions

dash-dash

@@ -592,8 +588,6 @@ build-subdir=buildbot_osx
ios
tvos
watchos
-test
-validation-test

dash-dash
-------------------------------------------------------------------------------------

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Jens Persson) #8

Thanks again,
I pulled the latest Swift repos which included the fix of the failing test
and modified the build preset locally according to Dmitri's advice and the
build completes without problems.

But now I wonder if there is a way to switch between the command line tools
of Xcode, Xcode-beta and the Swift I've just built from sources?

I mean, when I want to switch between the command line tools of Xcode and
Xcode-beta I can simply do:
sudo xcode-select -s /Applications/Xcode[-beta].app

Is there something similar that I can do in order to switch to the command
line tools from the one I built from sources?

These instructions: https://swift.org/download/
just says "add the Swift toolchain to your path" (using export) but I'm
hesitant to do that since I don't know whether that will work when I
already have Xcode and Xcode-beta installed (and thus /usr/bin/swiftc etc)?

/Jens

···

On Thu, Dec 10, 2015 at 6:11 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Thu, Dec 10, 2015 at 7:41 AM, Jens Persson <jens@bitcycle.com> wrote:
> Thanks!
> I tried the above to compile with the buildbot_osx_package preset. It
kind
> of worked, but it failed while performing the tests.
> (TEST 'Swift :: Driver/Dependencies/bindings-build-record.swift' FAILED)
> So, I got a working swiftc etc but no package or toolchain or anything
(at
> least as far as I could see).
>
> However, trying out the resulting swiftc shows that it is slow, ie the
> buildbot_osx_package preset did not imply --no-assertions
> --no-swift-stdlib-assertions.

Jens,

I think you found an issue in our presets. I filed
https://bugs.swift.org/browse/SR-180 Here, we have an incorrect
workaround that causes this issue:

[preset: mixin_lightweight_assertions]
assertions

# FIXME: This should be:
# no-assertions
# swift-assertions
# ... but our tests are expecting assertions to be either on or off
everywhere.

I think this hacky patch should get you unblocked (untested!):

-------------------------------------------------------------------------------------
diff --git a/utils/build-presets.ini b/utils/build-presets.ini
index 6dc6d24..1ab441f 100644
--- a/utils/build-presets.ini
+++ b/utils/build-presets.ini
@@ -462,12 +462,8 @@ swift-runtime-enable-leak-checker=1
# A mixin that enables 'lightweight' assertions that don't slow down the
# compiler significantly.
[preset: mixin_lightweight_assertions]
-assertions
-
-# FIXME: This should be:
-# no-assertions
-# swift-assertions
-# ... but our tests are expecting assertions to be either on or off
everywhere.
+no-assertions
+swift-assertions

dash-dash

@@ -592,8 +588,6 @@ build-subdir=buildbot_osx
ios
tvos
watchos
-test
-validation-test

dash-dash

-------------------------------------------------------------------------------------

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com


(Dmitri Gribenko) #9

Mish Awadah probably knows about setting up a custom toolchain in Xcode.

Dmitri

···

On Thu, Dec 10, 2015 at 9:44 PM, Jens Persson <jens@bitcycle.com> wrote:

Thanks again,
I pulled the latest Swift repos which included the fix of the failing test
and modified the build preset locally according to Dmitri's advice and the
build completes without problems.

But now I wonder if there is a way to switch between the command line tools
of Xcode, Xcode-beta and the Swift I've just built from sources?

I mean, when I want to switch between the command line tools of Xcode and
Xcode-beta I can simply do:
sudo xcode-select -s /Applications/Xcode[-beta].app

Is there something similar that I can do in order to switch to the command
line tools from the one I built from sources?

These instructions: https://swift.org/download/
just says "add the Swift toolchain to your path" (using export) but I'm
hesitant to do that since I don't know whether that will work when I already
have Xcode and Xcode-beta installed (and thus /usr/bin/swiftc etc)?

/Jens

On Thu, Dec 10, 2015 at 6:11 PM, Dmitri Gribenko <gribozavr@gmail.com> > wrote:

On Thu, Dec 10, 2015 at 7:41 AM, Jens Persson <jens@bitcycle.com> wrote:
> Thanks!
> I tried the above to compile with the buildbot_osx_package preset. It
> kind
> of worked, but it failed while performing the tests.
> (TEST 'Swift :: Driver/Dependencies/bindings-build-record.swift' FAILED)
> So, I got a working swiftc etc but no package or toolchain or anything
> (at
> least as far as I could see).
>
> However, trying out the resulting swiftc shows that it is slow, ie the
> buildbot_osx_package preset did not imply --no-assertions
> --no-swift-stdlib-assertions.

Jens,

I think you found an issue in our presets. I filed
https://bugs.swift.org/browse/SR-180 Here, we have an incorrect
workaround that causes this issue:

[preset: mixin_lightweight_assertions]
assertions

# FIXME: This should be:
# no-assertions
# swift-assertions
# ... but our tests are expecting assertions to be either on or off
everywhere.

I think this hacky patch should get you unblocked (untested!):

-------------------------------------------------------------------------------------
diff --git a/utils/build-presets.ini b/utils/build-presets.ini
index 6dc6d24..1ab441f 100644
--- a/utils/build-presets.ini
+++ b/utils/build-presets.ini
@@ -462,12 +462,8 @@ swift-runtime-enable-leak-checker=1
# A mixin that enables 'lightweight' assertions that don't slow down the
# compiler significantly.
[preset: mixin_lightweight_assertions]
-assertions
-
-# FIXME: This should be:
-# no-assertions
-# swift-assertions
-# ... but our tests are expecting assertions to be either on or off
everywhere.
+no-assertions
+swift-assertions

dash-dash

@@ -592,8 +588,6 @@ build-subdir=buildbot_osx
ios
tvos
watchos
-test
-validation-test

dash-dash

-------------------------------------------------------------------------------------

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Jens Persson) #10

Just to clarify (not sure if it's needed): Note that I can run Xcode with
my custom toolchain, eg:
xcrun launch-with-toolchain ./swift-SNAPSHOT-2015-12-11-a.xctoolchain

What I want to know is the part about switching between the command line
tools, not only between my Xcode and Xcode-beta (which I can do using
xcode-select) but also between those and my custom built Swift.

/Jens

···

On Fri, Dec 11, 2015 at 6:47 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

Mish Awadah probably knows about setting up a custom toolchain in Xcode.

Dmitri

On Thu, Dec 10, 2015 at 9:44 PM, Jens Persson <jens@bitcycle.com> wrote:
> Thanks again,
> I pulled the latest Swift repos which included the fix of the failing
test
> and modified the build preset locally according to Dmitri's advice and
the
> build completes without problems.
>
> But now I wonder if there is a way to switch between the command line
tools
> of Xcode, Xcode-beta and the Swift I've just built from sources?
>
> I mean, when I want to switch between the command line tools of Xcode and
> Xcode-beta I can simply do:
> sudo xcode-select -s /Applications/Xcode[-beta].app
>
> Is there something similar that I can do in order to switch to the
command
> line tools from the one I built from sources?
>
> These instructions: https://swift.org/download/
> just says "add the Swift toolchain to your path" (using export) but I'm
> hesitant to do that since I don't know whether that will work when I
already
> have Xcode and Xcode-beta installed (and thus /usr/bin/swiftc etc)?
>
> /Jens
>
>
> On Thu, Dec 10, 2015 at 6:11 PM, Dmitri Gribenko <gribozavr@gmail.com> > > wrote:
>>
>> On Thu, Dec 10, 2015 at 7:41 AM, Jens Persson <jens@bitcycle.com> > wrote:
>> > Thanks!
>> > I tried the above to compile with the buildbot_osx_package preset. It
>> > kind
>> > of worked, but it failed while performing the tests.
>> > (TEST 'Swift :: Driver/Dependencies/bindings-build-record.swift'
FAILED)
>> > So, I got a working swiftc etc but no package or toolchain or anything
>> > (at
>> > least as far as I could see).
>> >
>> > However, trying out the resulting swiftc shows that it is slow, ie the
>> > buildbot_osx_package preset did not imply --no-assertions
>> > --no-swift-stdlib-assertions.
>>
>> Jens,
>>
>> I think you found an issue in our presets. I filed
>> https://bugs.swift.org/browse/SR-180 Here, we have an incorrect
>> workaround that causes this issue:
>>
>> [preset: mixin_lightweight_assertions]
>> assertions
>>
>> # FIXME: This should be:
>> # no-assertions
>> # swift-assertions
>> # ... but our tests are expecting assertions to be either on or off
>> everywhere.
>>
>> I think this hacky patch should get you unblocked (untested!):
>>
>>
>>
-------------------------------------------------------------------------------------
>> diff --git a/utils/build-presets.ini b/utils/build-presets.ini
>> index 6dc6d24..1ab441f 100644
>> --- a/utils/build-presets.ini
>> +++ b/utils/build-presets.ini
>> @@ -462,12 +462,8 @@ swift-runtime-enable-leak-checker=1
>> # A mixin that enables 'lightweight' assertions that don't slow down
the
>> # compiler significantly.
>> [preset: mixin_lightweight_assertions]
>> -assertions
>> -
>> -# FIXME: This should be:
>> -# no-assertions
>> -# swift-assertions
>> -# ... but our tests are expecting assertions to be either on or off
>> everywhere.
>> +no-assertions
>> +swift-assertions
>>
>> dash-dash
>>
>> @@ -592,8 +588,6 @@ build-subdir=buildbot_osx
>> ios
>> tvos
>> watchos
>> -test
>> -validation-test
>>
>> dash-dash
>>
>>
-------------------------------------------------------------------------------------
>>
>> Dmitri
>>
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
>
>
>
>
> --
> bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
> http://www.bitcycle.com/
> Phone: +46-73-753 24 62
> E-mail: jens@bitcycle.com
>

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com


(Jordan Rose) #11

Ah! No, launch-with-toolchain's all that's supported. But it's an interesting direction to go. It'd be an Xcode feature more than a Swift feature, though, so bugs.swift.org isn't an appropriate place for the request.

Glad everything's working manually now.

Jordan

···

On Dec 10, 2015, at 22:09 , Jens Persson <jens@bitcycle.com> wrote:

Just to clarify (not sure if it's needed): Note that I can run Xcode with my custom toolchain, eg:
xcrun launch-with-toolchain ./swift-SNAPSHOT-2015-12-11-a.xctoolchain

What I want to know is the part about switching between the command line tools, not only between my Xcode and Xcode-beta (which I can do using xcode-select) but also between those and my custom built Swift.

/Jens

On Fri, Dec 11, 2015 at 6:47 AM, Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> wrote:
Mish Awadah probably knows about setting up a custom toolchain in Xcode.

Dmitri

On Thu, Dec 10, 2015 at 9:44 PM, Jens Persson <jens@bitcycle.com <mailto:jens@bitcycle.com>> wrote:
> Thanks again,
> I pulled the latest Swift repos which included the fix of the failing test
> and modified the build preset locally according to Dmitri's advice and the
> build completes without problems.
>
> But now I wonder if there is a way to switch between the command line tools
> of Xcode, Xcode-beta and the Swift I've just built from sources?
>
> I mean, when I want to switch between the command line tools of Xcode and
> Xcode-beta I can simply do:
> sudo xcode-select -s /Applications/Xcode[-beta].app
>
> Is there something similar that I can do in order to switch to the command
> line tools from the one I built from sources?
>
> These instructions: https://swift.org/download/
> just says "add the Swift toolchain to your path" (using export) but I'm
> hesitant to do that since I don't know whether that will work when I already
> have Xcode and Xcode-beta installed (and thus /usr/bin/swiftc etc)?
>
> /Jens
>
>
> On Thu, Dec 10, 2015 at 6:11 PM, Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> > > wrote:
>>
>> On Thu, Dec 10, 2015 at 7:41 AM, Jens Persson <jens@bitcycle.com <mailto:jens@bitcycle.com>> wrote:
>> > Thanks!
>> > I tried the above to compile with the buildbot_osx_package preset. It
>> > kind
>> > of worked, but it failed while performing the tests.
>> > (TEST 'Swift :: Driver/Dependencies/bindings-build-record.swift' FAILED)
>> > So, I got a working swiftc etc but no package or toolchain or anything
>> > (at
>> > least as far as I could see).
>> >
>> > However, trying out the resulting swiftc shows that it is slow, ie the
>> > buildbot_osx_package preset did not imply --no-assertions
>> > --no-swift-stdlib-assertions.
>>
>> Jens,
>>
>> I think you found an issue in our presets. I filed
>> https://bugs.swift.org/browse/SR-180 Here, we have an incorrect
>> workaround that causes this issue:
>>
>> [preset: mixin_lightweight_assertions]
>> assertions
>>
>> # FIXME: This should be:
>> # no-assertions
>> # swift-assertions
>> # ... but our tests are expecting assertions to be either on or off
>> everywhere.
>>
>> I think this hacky patch should get you unblocked (untested!):
>>
>>
>> -------------------------------------------------------------------------------------
>> diff --git a/utils/build-presets.ini b/utils/build-presets.ini
>> index 6dc6d24..1ab441f 100644
>> --- a/utils/build-presets.ini
>> +++ b/utils/build-presets.ini
>> @@ -462,12 +462,8 @@ swift-runtime-enable-leak-checker=1
>> # A mixin that enables 'lightweight' assertions that don't slow down the
>> # compiler significantly.
>> [preset: mixin_lightweight_assertions]
>> -assertions
>> -
>> -# FIXME: This should be:
>> -# no-assertions
>> -# swift-assertions
>> -# ... but our tests are expecting assertions to be either on or off
>> everywhere.
>> +no-assertions
>> +swift-assertions
>>
>> dash-dash
>>
>> @@ -592,8 +588,6 @@ build-subdir=buildbot_osx
>> ios
>> tvos
>> watchos
>> -test
>> -validation-test
>>
>> dash-dash
>>
>> -------------------------------------------------------------------------------------
>>
>> Dmitri
>>
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>>*/
>
>
>
>
> --
> bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
> http://www.bitcycle.com/
> Phone: +46-73-753 24 62
> E-mail: jens@bitcycle.com <mailto:jens@bitcycle.com>
>

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>>*/

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com <mailto:jens@bitcycle.com>