<font size=2 face="sans-serif">Thanks Daniel for the heads up.</font><br><br><font size=2 face="sans-serif">I like the goals that SR-3583 and SR-5259
are targeting. For instance, because the solution described in SR-3583
is not yet available, we have been using the "--build-path" argument
when building inside Docker containers or VMs as a way to avoid overriding
the .build folder on the macOS host:</font><br><br><font size=2 face="sans-serif">swift build --configuration debug --build-path
.build-ubuntu-1404</font><br><br><font size=2 face="sans-serif">If SR-3583 gets implemented, then SR-5259
would be certainly beneficial for our buildpack. As you pointed out, with
SR-5259, the buildpack would be able to determine the build path at runtime
without having to hard code it. In our buildpack we could execute "swift
build --bin-path", which I assume would output something along these
lines: “.build/macosx-x86_64”, “.build/ubuntu-1404”, etc... correct?</font><br><br><font size=2 face="sans-serif">Question... would "swift build
--display-build-path" be a better option than "swift build --bin-path"
to display the path to the build folder? I am thinking this would align
better with the current <br>"--build-path" option that exists now:</font><br><br><font size=2 face="Menlo-Regular">$ swift build --help</font><br><font size=2 face="Menlo-Regular">OVERVIEW: Build sources into binary
products</font><br><br><font size=2 face="Menlo-Regular">USAGE: swift build [options]</font><br><br><font size=2 face="Menlo-Regular">OPTIONS:</font><br><font size=2 face="Menlo-Regular"> --build-path
Specify build/cache directory [default: ./.build]</font><br><font size=2 face="Menlo-Regular"> --chdir, -C
Change working directory before any other operation</font><br><font size=2 face="Menlo-Regular"> --color
Specify color mode (auto|always|never)
[default: auto]</font><br><font size=2 face="Menlo-Regular"> --configuration, -c
Build with configuration (debug|release) [default: debug]</font><br><font size=2 face="Menlo-Regular"> --enable-prefetching
Enable prefetching in resolver</font><br><font size=2 face="Menlo-Regular"> --verbose, -v
Increase verbosity of informational output</font><br><font size=2 face="Menlo-Regular"> -Xcc
Pass flag through to all
C compiler invocations</font><br><font size=2 face="Menlo-Regular"> -Xlinker
Pass flag through to all linker invocations</font><br><font size=2 face="Menlo-Regular"> -Xswiftc
Pass flag through to all Swift compiler
invocations</font><br><font size=2 face="Menlo-Regular"> --help
Display available options</font><br><br><br><font size=2 face="sans-serif"><br>Regards,<br> Ricardo Olivieri<br> Software Engineer<br> IBM Swift Engineering at IBM Cloud</font><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Daniel Dunbar <daniel_dunbar@apple.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">David Hart <david@hartbit.com>,
Kyle Fuller <kyle@fuller.li>, Gregor Milos <gmilos@apple.com>,
Ricardo N Olivieri <ricardo.olivieri@us.ibm.com></font><br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"swift-build-dev@swift.org"
<swift-build-dev@swift.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">06/19/2017 05:49 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [swift-build-dev]
SwiftPM platform-specific build folders</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">daniel_dunbar@apple.com</font><br><hr noshade><br><br><br><font size=3>(CC'ing a couple people I know have worked on build packs
in the past.)</font><br><br><font size=3>Thanks David!</font><br><br><font size=3>For those only on the mailing list, we discussed this
plan on the SwiftPM Slack channel, and I think making this change in the
Swift 4 timeframe is right, even though it may break some things.</font><br><br><font size=3>One of the main goals of the compatibility work is to
make sure that we don't break any of the existing deployment workflows
people have built on top of SwiftPM (for example PaaS buildpacks). We don't
have time for a full "make install" type workflow which buildpacks
could use, but my hope was that SR-5259 would be something existing build
packs could migrate to to avoid having to hard code certain paths.</font><br><br><font size=3>We'd love feedback on whether this seems like a reasonable
plan.</font><br><br><font size=3> - Daniel</font><br><br><font size=3>On Jun 19, 2017, at 3:19 PM, David Hart via swift-build-dev
<</font><a href="mailto:swift-build-dev@swift.org"><font size=3 color=blue><u>swift-build-dev@swift.org</u></font></a><font size=3>>
wrote:</font><br><br><font size=3>Hello mailing-list,</font><br><br><font size=3>I’m implementing </font><a href="https://bugs.swift.org/browse/SR-3583"><font size=3 color=blue><u>SR-3583</u></font></a><font size=3>that builds SwiftPM products into platform-specific sub-folders. For example,
on macOS, a default build will no longer build products into <b>.build/debug</b>but instead in <b>.build/macosx-x86_64/debug</b>.</font><br><br><font size=3>To alleviate this breaking change, several solutions have
been planned:</font><br><ul><li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0179-swift-run-command.md"><font size=3 color=blue><u>SE-0179</u></font></a><font size=3>:
A new <b>swift run</b> tool to allow users to run executable products without
knowing their exact location.</font><li><font size=3>SR-3583 will create a symlink after each build pointing
from the old to the new build folder for backwards compatibility.</font><li><a href="https://bugs.swift.org/browse/SR-5259"><font size=3 color=blue><u>SR-5259</u></font></a><font size=3>:
A new <b>—bin-path</b> option for the <b>swift build</b> command to print
the build folder for 3rd party tools to use.</font></ul><br><font size=3>Of the above, only SE-0179 is currently fully implemented
in master.</font><br><br><font size=3>What does everybody think about this change and the solutions
put into place to support it?</font><br><br><font size=3>Regards,</font><br><font size=3>David.</font><br><font size=3>_______________________________________________<br>swift-build-dev mailing list</font><font size=3 color=blue><u><br></u></font><a href="mailto:swift-build-dev@swift.org"><font size=3 color=blue><u>swift-build-dev@swift.org</u></font></a><font size=3><br></font><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev"><font size=3>https://lists.swift.org/mailman/listinfo/swift-build-dev</font></a><br><br><br><BR>