[swift-users] REPL failed

Dmitri Gribenko gribozavr at gmail.com
Sun Dec 20 17:24:25 CST 2015

On Sun, Dec 20, 2015 at 12:03 PM, Daniel Dunbar <daniel_dunbar at apple.com> wrote:
> On Dec 10, 2015, at 11:07 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> On Thu, Dec 10, 2015 at 9:59 AM, Daniel Dunbar <daniel_dunbar at apple.com>
> wrote:
> Actually, I am retracting this suggestion in favor of what I think is a
> better one:
> What if we change the build process to build up a "composed package" as part
> of the regular build. We would clear this at the start of each build, and
> then build up the installed compiler + libraries + package manager as each
> project completed its build (basically just using the same install logic
> into a side location).
> This has a number of benefits:
> - At the end of the build, we have a "build/<config>/bin" directory which
> has a functioning compiler.
> - Each project in the chain can use the composed build to work with. So for
> example, the package manager can build with the compiler + xctest as they
> are expected to look in a package. This would reduce some complexity in our
> build process, and be more maintainable.
> - This solution scales better if/when we add more projects.
> - This solution also lets the build easily sub in an "prebuilt package" into
> the build process (it just means pointing at a different composed package).
> Thoughts?
> My concern is that copying files around will significantly increase
> the build time for everyone because of I/O.  Debug builds of Swift are
> quite large (> 700 Mb IIRC).
> My thought here was to use rsync and its options for creating hard links
> where possible. This makes the copying very cheap...

How would you implement it in practice?  CMake does not know how to
use rsync for its 'install' target, IIRC.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-users mailing list