[swift-build-dev] SwiftPM platform-specific build folders

[Ricardo N Olivieri]

Thanks Daniel for the heads up.

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:

swift build --configuration debug --build-path .build-ubuntu-1404

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?

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 
"--build-path" option that exists now:

$ swift build --help
OVERVIEW: Build sources into binary products

USAGE: swift build [options]

OPTIONS:
  --build-path            Specify build/cache directory [default: 
./.build]
  --chdir, -C             Change working directory before any other 
operation
  --color                 Specify color mode (auto|always|never) [default: 
auto]
  --configuration, -c     Build with configuration (debug|release) 
[default: debug]
  --enable-prefetching    Enable prefetching in resolver
  --verbose, -v           Increase verbosity of informational output
  -Xcc                    Pass flag through to all C compiler invocations
  -Xlinker                Pass flag through to all linker invocations
  -Xswiftc                Pass flag through to all Swift compiler 
invocations
  --help                  Display available options



Regards,
   Ricardo Olivieri
   Software Engineer
   IBM Swift Engineering at IBM Cloud


From:   Daniel Dunbar <daniel_dunbar at apple.com>
To:     David Hart <david at hartbit.com>, Kyle Fuller <kyle at fuller.li>, 
Gregor Milos <gmilos at apple.com>, Ricardo N Olivieri 
<ricardo.olivieri at us.ibm.com>
Cc:     "swift-build-dev at swift.org" <swift-build-dev at swift.org>
Date:   06/19/2017 05:49 PM
Subject:        Re: [swift-build-dev] SwiftPM platform-specific build 
folders
Sent by:        daniel_dunbar at apple.com



(CC'ing a couple people I know have worked on build packs in the past.)

Thanks David!

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.

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.

We'd love feedback on whether this seems like a reasonable plan.

 - Daniel

On Jun 19, 2017, at 3:19 PM, David Hart via swift-build-dev <
swift-build-dev at swift.org> wrote:

Hello mailing-list,

I’m implementing SR-3583 that builds SwiftPM products into 
platform-specific sub-folders. For example, on macOS, a default build will 
no longer build products into .build/debug but instead in 
.build/macosx-x86_64/debug.

To alleviate this breaking change, several solutions have been planned:

SE-0179: A new swift run tool to allow users to run executable products 
without knowing their exact location.
SR-3583 will create a symlink after each build pointing from the old to 
the new build folder for backwards compatibility.
SR-5259: A new —bin-path option for the swift build command to print the 
build folder for 3rd party tools to use.

Of the above, only SE-0179 is currently fully implemented in master.

What does everybody think about this change and the solutions put into 
place to support it?

Regards,
David.
_______________________________________________
swift-build-dev mailing list
swift-build-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170622/ac129a46/attachment.html>